La sfida delle prestazioni front-end: vincitore e risultati

Qualche settimana fa, abbiamo chiesto ai nostri lettori e alla community di utilizzare tutto il possibile per far funzionare i loro siti Web e progetti in modo incredibilmente veloce. Oggi siamo entusiasti di mostrare i risultati di questa sfida e di annunciare il vincitore che riceverà davvero fantastici premi!

Quali premi, chiedi? Il vincitore vince un volo di andata e ritorno per Londra, l'alloggio completo in un hotel di lusso, un biglietto per la SmashingConf London 2018 e, ultimo ma non meno importante, un seminario Smashing a sua scelta.

Sfida? Quale sfida?

Bene, il compito non era così semplice come sembrava. Ai concorrenti è stato chiesto di migliorare le prestazioni di un sito Web mantenendo identico l'aspetto visivo finale prima e dopo. Il caricamento dei caratteri poteva differire e i reflow erano accettabili purché ridotti al minimo.

Nella scelta del fortunato vincitore, abbiamo esaminato i risultati presentati da Lighthouse e WebPageTest, nonché la complessità dei siti Web su cui i nostri partecipanti avevano lavorato, ovviamente. La prima pittura significativa e il tempo per l'interazione sono state le metriche più critiche.

Ma abbastanza fatti concreti per ora. Sappiamo che sei già curioso e non vogliamo tenerti più con il fiato sospeso. Ed eccolo qui, il progetto vincitore.

E il vincitore è…

Leonardo Losoviz

Le tecniche di ottimizzazione presentate nella presentazione di Leonardo sono tutte fai da te, progettate e implementate da zero. Ha aggiunto tutte le ottimizzazioni a PoP, un framework open source per creare siti Web, e ha utilizzato Agenda Urbana per testare i miglioramenti delle prestazioni su un progetto reale.

Abbiamo ritenuto che questa presentazione fosse davvero entrata nello spirito della sfida non solo migliorando le prestazioni di un singolo sito Web, ma tentando di apportare miglioramenti a un framework utilizzato su numerosi siti Web. Il fatto che PoP sia supportato da WordPress significava che Leonardo si trovava in una situazione simile a molte persone incapaci di fare alcune delle cose disponibili per un framework JavaScript. Come ha notato:

PoP è costruito su WordPress. Ciò significa che molte tecniche di ottimizzazione innovative disponibili per i framework Javascript, come la suddivisione del codice tramite Webpack o Service Workers tramite sw-precache, sono fuori portata (almeno senza una grande soluzione alternativa). Pertanto, tutte le tecniche di ottimizzazione descritte di seguito sono tutte fai da te, progettate e implementate da zero.

Se sei interessato a scavare in tutti i dettagli essenziali della sua presentazione, sentiti libero di farlo. Ci siamo divertiti tutti a leggere i dettagli delle ottimizzazioni di Leonardo e lo abbiamo ritenuto un degno vincitore a causa dell'enorme quantità di lavoro che era stata dedicata a questa voce.

Tutti gli invii

Siamo rimasti molto soddisfatti della qualità delle proposte che abbiamo ricevuto e, onestamente, non è stato facile scegliere un vincitore. Grazie a tutti gli altri che hanno inviato: continuate così!

Jorgen Verweij

Jorgen Verweij ha presentato una versione ottimizzata del suo sito web aziendale Perplex Internetmarketing BV. Insieme a un team composto da un UX'er, uno sviluppatore front-end e back-end e un amministratore di sistema, ha iniziato l'attività prestazionale.

Il risultato è un'eccellente implementazione con eccellenti risultati di prestazioni su tutta la linea: SpeedIndex molto al di sotto dell'obiettivo prefissato di 1250, un tempo di caricamento inferiore a 1 secondo, avvio del rendering in mezzo secondo, un PageSpeedscore di ¹⁰⁰ ⁄ ₁₀₀ e un audit Lighthouse quasi perfetto . Rispetto alla vecchia situazione, il tempo di caricamento è quasi otto volte più rapido. Complimenti! Puoi leggere maggiori dettagli sul processo in questo articolo completo che Jorgen ha messo insieme.

Marco Hengstenberg

Marco Hengstenberg ha presentato una versione ottimizzata del sito web dell'agenzia turistica Land in Sicht . Per migliorare le prestazioni, Marco ha utilizzato molti piccoli trucchi e tecniche ingegnosi. Il precaricamento del foglio di stile principale e il caricamento critico dei caratteri con precaricamento nei browser di supporto sono solo due di questi. Ha anche ristrutturato l'HTML per renderlo il più piatto, semantico e accessibile possibile e ha ridotto la quantità di dati inizialmente trasferiti alla prima visita da quasi 3 MB a 1,3 MB sul desktop (e a causa dell'utilizzo di immagini reattive per l'immagine dell'eroe, è anche inferiore a quello su schermi stretti).

Per semplificare ulteriormente il sito, Marco ha rimosso Bootstrap, jQuery e Modernizr, ha impostato un processo di compilazione con Grunt e ha introdotto un ServiceWorker che rende il sito disponibile anche offline. Ne è valsa la pena: il risultato è un TTL drammatico che è sceso da 32 secondi a 2 secondi e una riduzione di quasi il 50% delle richieste HTTP e dei byte trasferiti (vedi anche il rapporto Lighthouse, ZIP 251KB). Il precarico e il rapido rendering iniziale aiutano entrambi sul tempo di caricamento percepito. Ottimo lavoro!

Gabriele Mariani

Il sito web del San Diego Christian College è stato quello a cui Gabriel Mariani ha applicato le sue capacità di performance. Ha suddiviso il processo di ottimizzazione in quattro fasi. Innanzitutto, ha ritagliato tutte le immagini alla dimensione massima in cui erano effettivamente necessarie e ne ha create versioni su scala mobile. Ha quindi eseguito il lazy load di tutte le immagini. Il secondo passaggio si è concentrato su JavaScript e sulla rimozione di tutti gli script inline forniti dal sito WordPress e dal suo tema e plug-in di terze parti. Quindi ha accodato quanti più script possibile in modo che Autoptimize potesse raccoglierli e minimizzarli/combinarli in un unico file.

Gabriel ha anche ridotto il numero di caratteri utilizzati e impostato i caratteri di Google in modo che vengano caricati in modo async in modo che il percorso critico CSS venga caricato per primo. Ultimo ma non meno importante, ha affrontato alcune altre piccole cianfrusaglie come la personalizzazione dei plugin di WordPress, quindi si basano su ajax anziché su PHP. Ciò gli ha permesso di abilitare la memorizzazione nella cache della pagina e, infine, di abilitare una CDN per il sito. Il passaggio a HTTP/2 e HTTPS è stato il passaggio finale. Vedere WebPageTest per i risultati completi. Carino!

Alexander Zarges

Alexander Zarges ha sviluppato Cloud Player, un'applicazione Web a pagina singola basata su Angular 4 che ti consente di cercare e riprodurre app YouTube e SoundCloud. La versione aggiornata utilizza il compilatore di anticipo angolare Angular per ottenere un tempo di inizializzazione di circa 2,9 secondi (rispetto a 5,2 secondi quando si utilizza il compilatore just-in-time). Se vuoi approfondire il codice, controlla il repository GitHub allegato.

Bradly Taunt

Bradley Taunt ha colto la nostra sfida come un'occasione per sperimentare con il suo sito personale. Come base per la sua impresa di ottimizzazione, ha utilizzato la sua homepage e un articolo ricco di immagini. Per ridurre i tempi di caricamento a 4,2 secondi per l'articolo, Bradley imposta automaticamente i caratteri del sistema operativo dell'utente anziché utilizzare i caratteri Web, tra le altre cose.

Per una spinta in più, la versione ottimizzata integra anche CSS critici, offre immagini reattive e utilizza la cache CDN. Puoi dare uno sguardo più dettagliato dietro le quinte, nel post sul blog che Bradley ha scritto su come ha affrontato la sfida.

Giovanni Beale

John Beales si è sfidato a dare a 4RoadService.com un aumento delle prestazioni. Quando ha iniziato c'erano già alcune ottimizzazioni in atto. Le immagini statiche sono state eseguite tramite ImageOptim, ad esempio, CSS e JS sono stati minimizzati, stavano eseguendo una CDN tramite CloudFlare e il sito utilizzava già un caricatore in stile app a pagina singola, quindi i nuovi contenuti vengono sempre recuperati da XHR e la pagina viene mai completamente ridisegnato.

Per questa sfida, John ha attivato l'ottimizzazione dell'immagine e la compressione WebP in Cloudflare. Il sito aggiornato ora utilizza HTTP/2 Server Push per inviare i principali file CSS e JS con il pageload iniziale e si affida a Guetzli per la compressione JPEG. Per ottimizzare la memorizzazione nella cache, ha aggiornato gli URL di tutte le risorse statiche in modo che l'URL cambiasse ogni volta che la risorsa cambia, quindi ha impostato tutte le risorse statiche in cache per un anno. Per una migliore memorizzazione nella cache delle immagini, John ha anche aggiornato gli URL delle immagini ridimensionate dinamicamente in modo che CloudFlare consideri file di immagine statici.

Il risultato: la prima vernice significativa è scesa da 2.220 ms a 1.290 ms e la prima interattiva da 5.480 ms a 3.040 ms. Puoi visualizzare i risultati completi di Lightbox e WebPage Test qui.

Shaun O'Connell

La voce di Shaun O'Connel è stata il lavoro che ha svolto su kiwi.ruby.nz. L'obiettivo era trasformare il sito web della conferenza in una PWA in modo che i partecipanti alla conferenza potessero cercare tutte le informazioni relative all'evento offline. Alcune delle cose che ha fatto: sostituzione di un tipico iframe di Google Maps con Google Static Maps, auto-hosting dei sottoinsiemi di caratteri, spostamento dei CSS in linea per mantenere la prima richiesta al di sotto dei 14 KB, rimozione delle dipendenze, aggiunta di Service Worker pre-cache e aggiunta di Turbolink per uno snappy transizioni di pagina. In questo modo, il tempo di rendering iniziale è sceso da 3,9 secondi a 0,3 secondi.

Per maggiori dettagli controlla i WebPageTests.

Ruslan Julbarissow

Ruslan Julbarissow ha presentato il suo sito web personale zerofy.de. Dal momento che ha terminato il suo lavoro di ottimizzazione poco prima della pubblicazione del concorso, sfortunatamente non ci sono risultati dettagliati prima, ma Ruslan ha scritto un buon resoconto di come le sue modifiche abbiano portato a una dimensione della pagina di 1,6 KB e un TTFB di 197 ms. Oltre a memorizzare nella cache, minimizzare, modificare GZIP e jQuery, carica i caratteri in seguito per evitare il blocco del rendering e, sostituendo FontAwesome con un set IcoMoon personalizzato di 10 icone, è riuscito a risparmiare altri 130 KB.

Per aumentare il punteggio dell'indice di velocità e ottenere l'esperienza più veloce possibile, ha anche creato un file PHP separato che contiene tutti gli stili CSS che interessano la vista above-the-fold. Un bel dettaglio: il minuscolo script Barba.js gli permette di creare transizioni di pagina senza dover ricaricare l'intero sito.

Grazie a tutti per aver partecipato

Uff! Questa è stata davvero una bella sfida! Per quelli di voi che amano una sfida così bella e un solletico cerebrale di tanto in tanto, restate sintonizzati per la prossima sfida. Ne troveremo un altro in men che non si dica, questo è certo!