Dalla creazione di Internet, le dimensioni medie dei file sono aumentate costantemente. Quello che è iniziato come kilobyte è progredito in megabyte (sì, plurale), ei nostri file stanno solo crescendo ancora.
Mentre questo fenomeno non è sconcertante a prima vista, l'impatto che ha sulle prestazioni e sulla manutenibilità è terribile. Aggiungi dispositivi obsoleti, limiti di larghezza di banda o basse velocità in generale ... e abbiamo un problema molto più grande.
Per fortuna, abbiamo il controllo non solo delle dimensioni dei nostri file, ma anche del modo in cui le nostre pagine sono visualizzate nel browser. Questo tipo di controllo offre agli sviluppatori web come noi la possibilità di aiutare a risolvere questo problema e ottimizzare il nostro codice per migliorare le prestazioni nel processo.
Comprendo completamente una mancanza di interesse quando la maggior parte delle connessioni Internet negli Stati Uniti sono abbastanza veloci in questi giorni. Voglio dire, se tutto funziona bene già perché preoccuparsi?
Le prestazioni e l'ottimizzazione sono più di quanto velocemente possiamo scaricare contenuti. Ci sono anche alcuni vantaggi SEO e UX da avere prendendo tempo per guardare il nostro codice. Per non parlare, la riduzione delle dimensioni dei file grazie all'ottimizzazione del nostro codice per prestazioni migliori ha il vantaggio aggiuntivo di ridurre i costi della larghezza di banda come host e riduce l'utilizzo della larghezza di banda (si pensi ai limiti dei dati ISP / cellulari) anche a livello di utente.
Il codice modulare in genere aggiunge ingigantire sotto forma di più opzioni. Qui, vogliamo pensare modulare in termini di combinazione di quanti più pezzi comuni del nostro codice possibile. Se possiamo combinare due classi CSS in una sola e usare meno codice per fornire lo stesso risultato, dovremmo.
La modularità non è importante quando si tratta di HTML e CSS di base, ma quando si entra nel mondo più complesso di JavaScript, avere troppi ingrandimenti può farti male, soprattutto sui dispositivi mobili.
Le richieste di dipendenza sono di gran lunga il fattore principale nel rallentare la maggior parte delle velocità di caricamento della pagina. Ogni richiesta aggiuntiva aggiunge ingigantimento e un altro livello di complessità al processo di analisi e download. Spesso è facile dimenticare che anche le immagini di chiamata dal tuo foglio di stile contano, quindi assicurati di limitarle e utilizzare metodi di ottimizzazione alternativi come sprite o SVG quando possibile.
Mentre siamo sull'argomento delle dipendenze esterne, se il tuo sito web è abbastanza grande da richiedere alcune dozzine di richieste al minimo ... Potrebbe essere il momento di prendere in considerazione l'utilizzo di una CDN. L'utilizzo di un CDN per distribuire il contenuto non ridurrà le dimensioni e / o i tempi di caricamento dei file tanto quanto rimuovendo le richieste HTTP aggiuntive tutte insieme, ma è probabile che rimuova almeno le connessioni server lente dall'equazione.
Ci dovrebbe essere una differenza molto marcata quando si confrontano le basi del codice di sviluppo e di livello di produzione. Prendendo questo passo da solo a volte può vedere la più grande diminuzione delle dimensioni dei file su tutta la linea.
Oggi è tipico vedere gli sviluppatori fare riferimento al loro ambiente di "produzione" o "sviluppo", specialmente su progetti su larga scala. Ma è utile anche nella parte più piccola delle cose. La più grande differenza tra i due ambienti può essere vista con la compressione dell'immagine e la minimizzazione / compressione del codice. Alla fine, vogliamo che il nostro ambiente di produzione sia il più snello e veloce possibile mentre il nostro ambiente di sviluppo dovrebbe essere lo stesso, meno l'ottimizzazione della compressione dell'immagine / codice.
Usare gli strumenti integrati come la compressione "Salva per web" di Photoshop può essere un buon punto di partenza per le immagini. C'è una pletora di conoscenza da essere esplorato altrove anche con conversazioni su formati di immagine, algoritmi di compressione, controllo qualità e best practice.
Per il codice, il miglior utilizzo della compressione di solito dipende dalla lingua con cui stai lavorando. È anche altamente discutibile se la compressione del codice aiuti o ferisca altre persone nel tentativo di capire il codice, ma questa è una conversazione per un'altra volta. Quando si tratta di semplici HTML e CSS, utilizzo servizi come Htmlcompressor di Google e il Compressore YUI per CSS.
A volte il vero codice che stiamo scrivendo è il collegamento più lento della catena. CSS inefficiente o JavaScript gonfio possono danneggiare i tempi di caricamento più di quanto tu possa pensare. Questo Mozilla post va in grande dettaglio sull'importanza di scrivere selettori CSS snelli e spiegare come i browser li rendono. In breve, scrivere il percorso esatto lungo una catena di selettori è molto meno efficiente rispetto al semplice utilizzo del più piccolo selettore in modo univoco identificabile. Entrambi indirizzano lo stile allo stesso elemento, quest'ultimo semplicemente fa il lavoro molto, molto più velocemente.
JavaScript può essere anche peggio di CSS scritto male, e in molti casi è facilmente trascurato. Quante volte hai copiato e incollato una libreria JS esterna nel tuo progetto senza veramente approfondire la fonte stessa? Typekit è un meraviglioso esempio di questo, poiché quando i loro server lo bloccano può portare una pagina web usando i loro caratteri sulle ginocchia e causare altri 30 secondi o anche minuti di tempo di caricamento extra.
Fortunatamente, tali eventi si verificano raramente, ma è comunque buona pratica chiamare JavaScript, se possibile, come nel caso di Google Analytics. Ciò consente al browser di analizzare i file head (CSS, richieste HTTP, ecc.) E visualizzare il markup, prima che JavaScript inizi a rallentare.
In linea con il nostro obiettivo di scrivere selettori CSS più snelli e ridurre al minimo l'efficienza, scrivere HTML efficiente dovrebbe essere una priorità.
I ripristini CSS spesso prendono di mira tutti gli elementi comuni e impongono uno stile di "reimpostazione" su di essi. Quindi, anche se non stai prendendo di mira quel div extra, è probabile che ancora rallenti le cose dovendo avere il padding e il reset del margine al minimo. In genere, un div extra o due non farà davvero male a nessuno. Solo quando inizi a finire con dozzine di loro le cose si fanno pazze. Con l'introduzione di più elementi nelle specifiche HTML5, abbiamo anche molta più flessibilità in quest'area.
Google ha reso prioritaria la creazione di una connessione Internet in forma collettiva. Al fine di occupare posizioni di rilievo nei risultati di ricerca, le pagine devono ora prestare attenzione critica a molti attributi diversi su come vengono visualizzati. Chiamare troppe risorse esterne, avere immagini assurdamente grandi, o anche avere JavaScript scritto male può far cadere un sito in classifica.
Fortunatamente, questo è tutto con buone intenzioni in quanto le loro esigenze per una buona classifica di ricerca sono basate su buone pratiche di sviluppo. Google offre anche a guida molto approfondita per ottimizzare diversi aspetti del tuo sito per una migliore SEO - cosa che accade anche per promuovere pratiche di sviluppo fantastiche allo stesso tempo.
Quando ottimizziamo il nostro codice, non dobbiamo solo pensare alle dimensioni dei file, ma anche considerare come verrà letto; sia dai browser che da altri umani. Dovrebbe anche essere preso in considerazione l'uso di dispositivi mobili, con molti fornitori di servizi che applicano limiti di dati molto limitanti in questi giorni.
Quindi, mentre potrebbe richiedere più tempo per eseguire tutta questa ottimizzazione, è certamente un utile sforzo poiché non solo offre migliori prestazioni nel browser e sui dispositivi mobili, ma ha anche la possibilità di promuovere migliori pratiche di sviluppo e persino di ottenere un contenuto più elevato su motori di ricerca come Google.
La prossima volta che ti prepari a lanciare, lancia le tue immagini in un motore di compressione ... Potresti essere sorpreso di quanti megabyte si possano sbarazzare!
Immagine in evidenza, immagine di velocità modulare via Shutterstock.