SHARE

Prima che tu legga una sola altra parola, ho necessità di mostrarti il risultato di ciò che sto per regalarti.

Questi due video che vedi qui sotto sono il prima ed il dopo dell’ottimizzazione del blog marcosalvo.it

Ottimizzazione NON eseguita con il semplice ausilio di comuni plugin come W3 Total cache o simili, infatti c’è molto ma molto di più 🙂

Prima dell’ottimizzazione delle performance

Dopo l’ottimizzazione delle performance

Sei ancora incredulo?

Preparati perché oggi per te è un gran giorno, stai per leggere uno dei casi studio più belli che tu abbia mai visto su un blog di marketing e SEO e che ho il piacere di ospitare grazie allo splendido lavoro svolto da Salvatore Fresta, fondatore di SpeedyWordress.it e COO di SqueezeMind, un amico con cui ho il piacere di collaborare.

In questo caso studio, ti farò vedere come Salvatore è riuscito ad ottenere un tempo di caricamento prossimo al secondo per il mio sito ed  in particolare ti farò vedere

  1. quali tool sono stati utilizzati per effettuare l’analisi delle performance
  2. come sono stati interpretati i dati e quali sono stati i passi che hanno consentito al mio sito di risparmiare ben 17 secondi di tempo!

ma prima di iniziare è bene che tu sappia quanto segue:

Era l’ormai lontano 2010 quando Google in un post su uno dei suoi blog segnala di aver introdotto un nuovo fattore di ranking all’interno dei suoi algoritmi.

Inutile descrivere lo scetticismo riguardo ad ogni singolo fattore di ranking, ma questo aveva qualcosa in più rispetto agli altri.

In quel periodo il loro focus era sulla velocità, infatti è li che soprono con un metodo scientifico, che i siti più veloci, sembravano essere quelli che venivano visitati con più entusiasmo dagli internauti.

Pensa che Google, in uno dei suoi, ha provato a mettere 30 risultati in SERP invece che 10 con un conseguente aumento di caricamento della pagina di 900 milli secondi.

Sai cosa è successo? un calo del 25% nelle ricerche e quindi anche nelle entrate.

Già perché se il sito rallenta anche le vendite ne risentono.

Guarda questo screen molto esaustivo dove puoi evincere quale sia il rapporto di miglioramento tra velocità del sito e vendite.

Beh non ti  sarà difficile crederlo vero?

Eppure ancora oggi, ti assicuro, che in molti non danno il corretto peso alla velocità del proprio sito e questo, in certi casi, è un errore gravissimo.

Dal 2010 ad oggi sono passati 8 anni ed il web ha fatto il suo corso, evolvendosi in una maniera spaventosa, ma dove siamo arrivati?

Che impatto ha avuto questo fattore di ranking nelle ricerche?

Ma sopratutto come faccio a far diventare il mio sito veloce?

Ok, Oggi, come consuetudine vuole 🙂 ho una grandissima sorpresa per te! una super chicca.

La buona notizia:

Affronteremo questo argomento con un esperto di sicurezza informatica e di performance.

La brutta notizia:

Probabilmente non riuscirai a leggere questo post tutto dun fiato, come ti capita su altri blog, anzi, qui ti mancherà il respiro ad ogni singola parola che leggerai.  

Ma a questo ci sei abituato vero? heheheheh

Adesso però è arrivato il momento di donarti ciò che meriti.

Procediamo? Via!

E’ opportuno precisare che per ottenere questo tipo di risultato Salvatore si è focalizzato sulla branca delle performance che si occupa dell’ottimizzazione del percorso di rendering critico, ovvero quella sequenza di passi ed elaborazioni necessarie per poter consentire al browser di visualizzare il contenuto di una pagina web.

MARCO:
Puoi spiegarci in parole semplici? 🙂

SALVATORE:
Certo Marco, cercherò di essere il più esaustivo possibile. 🙂
Devi sapere che una volta fatta la richiesta di una URL, il browser ne riceve il suo contenuto HTML e ne inizia la lettura.

Durante questa lettura è possibile che incontri risorse critiche come CSSJavascript che, se non ottimizzati ad hoc, incidono molto negativamente sul tempo di visualizzazione della pagina.

Si tratta spesso anche di decine di secondi.

Ottimizzare il percorso di rendering critico significa ottimizzare il lavoro del browser fornendogli inizialmente le sole risorse veramente necessarie per visualizzare il contenuto della pagina e rimandare a posteriori il caricamento di quelle che non lo sono.

Purtroppo non è possibile effettuare con parsimonia questo tipo di ottimizzazione con i plugin tradizionali come W3 Total Cache, WP-Rocket, ecc…

Questi plugin sono stati progettati per applicare i suggerimenti dei tool più blasonati, come PageSpeed Insight e YSlow

  • ottimizzazione di immagini
  • compressione della pagina
  • minificazione di CSS e Javascript

Tutti consigli – non sempre al passo con i tempi – che mirano a rendere il sito più leggero e quindi a velocizzare il tempo di download.

Ma ovviamente, soluzioni del genere non possono essere adottate con successo in ogni occasione, perchè come vedrai di seguito serve molto ma molto di più per eseguire un lavoro professionale.

È una naturale conseguenza!

Otterrai un tempo di caricamento più veloce se riesci a scaricare prima le risorse ma il grado di performance che otterrai  è tuttavia molto limitato e talvolta deludente.

In un presente dove la maggior parte della navigazione avviene da dispositivi mobile, che dispongono di risorse nettamente inferiori rispetto ai PC tradizionali, se il lavoro del browser non viene snellito ti ritroverai ad avere un sito lentissimo anche se il navigatore possiede una connessione velocissima.

Voglio dividere l’ottimizzazione che ho fatto, in 3 step fondamentali:

  1. Analisi
  2. Ottimizzazione risorse critiche
  3. Ottimizzazione del TTFB / browser caching

Adesso per ognuna di queste ti faccio una dettagliatissima descrizione che mi hai chiesto per i tuoi utenti così ti lascio contento.

Marco:
Così mi piaci! 🙂

Salvatore:
Proseguiamo:

Ottimizzazione Parte 1:
Analisi delle performance

La prima cosa che faccio quando inizio la fase di analisi è aprire la DevTool di Google Chrome, cliccare sul tab Network, collegarmi sul sito che intendo analizzare e prestare attenzione al valore di DOMContentLoaded in blu in basso.

Questa metrica mi fa capire se il browser sta effettuando delle elaborazioni che richiedono un tempo “anormale” per visualizzare il contenuto della pagina.

Diciamo che un tempo di DOMContentLoaded superiore al secondo e mezzo è quasi sempre un sintomo di sovraccarico.
(Nel caso del tuo sito, prima dell’ottimizzazione, era superiore ai 4 secondi.)

In contemporanea faccio partire un’analisi con webpagetest.org e la mia attenzione si concentra sulle metriche evidenziate nella seguente immagine:

Spiego meglio:

Load time:

E’ il tempo totale di caricamento di tutte le risorse presenti sulla pagina, a prescindere dal fatto che incidano o meno con componenti visive; sostanzialmente coincide con il tempo di fine caricamento della “rotellina” del browser o della “progress bar”.

First Byte:

detto anche Time To First Byte (TTFB) indica il tempo trascorso dalla richiesta HTTP del browser alla ricezione del primo byte della pagina; è un valore utilizzato per misurare la reattività di un web server e l’impatto dell’elaborazione di un sito web dinamico.

Start render:

è il tempo in cui il browser finalmente inizia a stampare qualcosa di visibile; prima di questo momento la pagina è totalmente vuota.

RUM First Paint:

E’ il tempo in cui il browser inizia il processo di visualizzazione dei dati, siano anche essi invisibili.

Visually Complete:

Il tempo necessario per visualizzare tutti i contenuti visibili della pagina.

Vuoi sapere cosa ho trovato sul tuo sito? 🙂

  1. Un alto valore di First Byte, che normalmente dovrebbe essere compreso da 100 e 300 millisecondi, quando invece qui è di addirittura 1 secondo;
  2. Un tempo di load time molto elevato, il che mi fa pensare subito che vengono caricate risorse che fanno capo anche a siti esterni e non necessarie immediatamente all’utente
    (es. widget Facebook, Twitter, Instagram, ecc..) 
  3. Un tempo di inizio rendering sproporzionato che incide negativamente sulla UX e sulla percezione di velocità del sito stesso

Da mobile la situazione peggiora!

Per fare un’analisi utilizzo il tool Lighthouse, ormai integrato in DevTool cliccando sul tab Audit.

In particolare noto una Critical Request Chains di 17 elementi.

Ovvero le famose risorse critiche, senza le cui elaborazioni il browser non visualizzerebbe nulla.

Noto che alcune di queste sono minifcate con il plugin W3 Total Cache, il quale applica anche altre ottimizzazioni come il lazy loading delle immagini.

Ciò a testimonianza che nonostante il plugin di cache, il percorso di rendering rimane sporco in quanto sono sicuro del fatto che il browser non necessita di 17 risorse per caricare un sito dall’aspetto e funzionalità come quelle del tuo sito.

 

Quindi?

Disattivo il plugin e la Critical Request Chains aumenta a 34 elementi.

Dal report di webpagetest.org noto inoltre come da desktop sono ben 69 le risorse critiche.

È possibile notarlo scendendo su Request Details, così da  osservare tutte le risorse contrassegnate dal colore verde, le risorse caricate prima dell’inizio del processo di rendering.

Una volta individuate le risorse critiche, inizio a fare una cernita per capire quali sono quelle vere e quali no e da qui inizia la seconda parte

Ottimizzazione Parte 2: Ottimizzazione delle risorse critiche

Inizio con i CSS.

Posso seguire diverse strade:

  1. Estrapolare il solo CSS usato dalla pagina, se piccolo caricarlo inline affinché sia già subito disponibile con il download della pagina stessa, eliminando tutti i restanti CSS.
    Soluzione molto efficiente ma che poco si presta ad aggiornamenti del sito;
  2. Estrapolare il solo CSS necessario per caricare i contenuti immediatamente visibili (above the fold) e caricare i restanti CSS in un tempo successivo;
    Anche questa è una soluzione efficiente ma avrei dovuto seguire e “scrivere” una politica diversa per quelle pagine che hanno strutture grafiche differenti, e non è il caso in siti che ne hanno parecchie;
  3. Individuare tra i CSS presenti quelli che contengono le regole di almeno il 95% del sito e caricare i restanti successivamente; questa è la tecnica che ho deciso di applicare in questo contesto.

BINGO!

Il CSS in questo caso è quello nativo del tema WordPress Newsmag.

Adesso viene il bello 🙂

Grazie ad un mio tool, di cui presto rilascerò il download su SpeedyWordpress.it, ho modificato in runtime la pagina elaborata da WordPress affinché questo CSS sia inserito in alto sul codice HTML in modo tale che il browser lo scarichi subito  e grazie ad una tecnica di performance ne ho forzato il download e l’elaborazione dei restanti CSS solo dopo che il browser ha finito di scaricare tutte le altre risorse della pagina (evento load).

Subito dopo ho fatto un test ed ho noto subito un primo miglioramento dovuto al fatto che il browser non si trovava più a scaricare CSS inutili così da elaborare il prima possibile solo il CSS necessario.

Primo obiettivo raggiunto.

Adesso non rimaneva che passare al Javascript, la risorsa critica più complessa da trattare.

Come prima cosa ho fatto uno stamp dell’ordine in cui i vari script si trovano all’interno della pagina che stavo ottimizzando, per identificarne sia gli script esterni, visibili già sul report:

  1. Inline script.
  2. Inline script.
  3. https://marcosalvo.it/wp-includes/js/jquery/jquery.js?ver=1.12.4
  4. https://marcosalvo.it/wp-includes/js/jquery/jquery-migrate.min.js?ver=1.4.1
  5. https://platform.twitter.com/widgets.js?ver=4.9.1
  6. https://marcosalvo.it/wp-content/plugins/ig-shortcodes/inc/js/shortcodes.js?ver=4.9.1
  7. Inline script. ID: facebooxpixel
  8. Inline script.
  9. Inline script. ID: googleanalytics
  10. //www.marcosalvo.it/cookiechoices.js
  11. Inline script. ID: cookiechoises
  12. Inline script. ID: facebookwidget
  13. Inline script.
  14. //widget.spreaker.com/widgets.js
  15. Inline script.
  16. https://marcosalvo.it/wp-content/plugins/contact-form-7/includes/js/scripts.js?ver=4.9.2
  17. Inline script.
  18. https://marcosalvo.it/wp-content/plugins/custom-twitter-feeds/js/ctf-scripts.js?ver=1.2.7
  19. https://marcosalvo.it/wp-content/plugins/table-of-contents-plus/front.min.js?ver=1509
  20. https://marcosalvo.it/wp-content/plugins/widget-styler//assets/front.js?ver=4.9.1
  21. https://marcosalvo.it/wp-content/themes/Newsmag/js/tagdiv_theme.js?ver=3.1
  22. Inline script.
  23. https://marcosalvo.it/wp-content/plugins/thrive-visual-editor/thrive-dashboard/js/dist/frontend.min.js?ver=2.0.17
  24. https://marcosalvo.it/wp-content/plugins/strong-testimonials/public/js/lib/actual/jquery.actual.min.js?ver=1.0.16
  25. https://marcosalvo.it/wp-includes/js/imagesloaded.min.js?ver=3.2.0
  26. https://marcosalvo.it/wp-includes/js/underscore.min.js?ver=1.8.3
  27. https://marcosalvo.it/wp-content/plugins/strong-testimonials/public/js/lib/verge/verge.min.js?ver=1.10.2
  28. Inline script.
  29. https://marcosalvo.it/wp-content/plugins/strong-testimonials/public/js/lib/strongslider/jquery.strongslider.min.js?ver=2.28.4
  30. Inline script.
  31. https://marcosalvo.it/wp-content/plugins/strong-testimonials/public/js/controller.min.js?ver=2.28.4
  32. https://marcosalvo.it/wp-includes/js/wp-embed.min.js?ver=4.9.1
  33. Inline script.

Nella home page vi erano 33 script e fortunatamente in nessuno di questi era presente la direttiva document.write.

Con il tool, in pratica, ho spostato tutti i file Javascript in fondo al codice HTML, prima della chiusura del tag <body>.

In questo modo ho evitato che il blocco dello script del normale parsing HTML del browser.

Ciononostante non ho risolto completamente il problema in quanto il codice deve comunque essere eseguito e questo comportava del tempo.

Come fare per risolvere?

Ho caricato tutti gli script Javascript all’evento load del browser.

Se funziona e non vi sono effetti sulle pagine del sito, sta a significare che nessun codice Javascript è necessario prima del rendering della pagina e quindi può essere caricato a posteriori, con un grande risparmio di tempo.

Noto però alcuni errori Javascript nella console di Google Chrome ed individuo quelli che purtroppo sono dei codici che il tema WordPress richiede vengano eseguiti obbligatoriamente prima dell’evento load e sono 3 script:

jQuery, uno script inline e tagdiv_theme.js (per quest’ultimo posso anche applicare l’attributo defer).

Beh meglio di niente mi sono detto, in fondo, su 33 script sono solo 3 quelli che non posso sovra-ottimizzare senza andare a modificare il codice, va bene così.

In casi in cui si richiede una consulenza estrema, è normale che lo sviluppatore vada a rivedere alcune strutture.

Non è questo il caso.

Torniamo a noi 😉

Subito dopo ho fatto un test notando che il tempo di rendering della pagina è diminuito notevolmente, siamo intorno ai 2.3 secondi.

Il tempo di loading completo è rimasto abbastanza alto e noto che il problema risiede nel widget di Facebook che scarica una miriade di immagini.

Questo widget è nella sidebar e non è visibile in prima impressione, decido dunque di caricarlo solo quando l’utente inizia a scrollare la pagina.

BAM! Il tempo di caricamento generale scende repentinamente.

Secondo obiettivo raggiunto!

Ma non è tutto 🙂

Infatti è proprio a questo punto  che il browser scarica tutte le immagini della pagina, comprese quelle che non sono immediatamente visibili.

Tempo di elaborazione perso e download di dati inutili se l’utente decide di non scrollare la pagina e visualizzarle.

Applico dunque la tecnica del lazy loading, facendo scaricare al browser le immagini se e solo se l’utente si trova nelle loro vicinanze.

A questo punto il tempo di caricamento è sceso a 1.8 secondi.

Con le ottimizzazioni cui sopra la Critical Request Chain per il mobile è passata da 34 risorse a 3 e per il desktop da 69 a 8!

WOOOOOW! 🙂

Ottimizzazione Parte 3:
TTFB e politiche di browser caching

Per ridurre il tempo di First Byte ho applicato una cache HTML lato server con WP Super Cache, evitando così che WordPress elabori in continuazione il codice della pagina e risparmiando centinaia di query SQL.

L’ideale sarebbe stata una cache direttamente a livello di web server ma non essendo il sito ospitato presso un server dedicato, questa opzione non è stata possibile applicarla.

Nonostante il tempo si sia ridotto, continuava ad essere superiore ai 300 ms per i file statici.

A questo punto ho applicato una CDN (Content Delivery Network) affinché questi fossero stati serviti da server geograficamente più vicini al richiedente.

Nel frattempo ho compresso il codice della pagina HTML con gzip, minificato CSS e Javascript ed ottimizzato il peso delle immagini JPEG e PNG risparmiando ulteriori 700 millisecondi.

Grazie a tutte queste ottimizzazioni
il  tempo di rendering della home page, ma in generale delle pagine del sito di marcosalvo.it, è sceso a 1 secondo,
il tempo di load a 1.1 secondi
il tempo di Visually Complete ad 1.9 secondi.

Vedi test Webpagetest.org

È possibile ottimizzare ancora?

Certo! Non c’è limite all’ottimizzazione, tutto dipende dal core business del sito, dal livello di consulenza richiesto e dalle politiche di aggiornamento del sito stesso.

Altre ottimizzazioni che è possibile effettuare sul sito di marcosalvo.it comprendono la conversione in webp delle immagini nonché una politica di caching per le visite successive alla prima mediante delle Progressive Web Application realizzate su misura, che consentono di ottenere tempi di caricamento estremi.

Chiudo citando una delle frasi che racchiude tutto il significato di performance lato web:

Remember the principles. Make things smaller, move them closer, cache them longer and load them more intelligently. Focus on the end objective and don’t get too caught up in the rules.

A proposito Marco, Per gli amanti di Gtmetrix ti lascio le estrapolazioni:
Ecco il prima ed il dopo

 

Marco:
Salvatore, credo tu abbia detto e dato veramente tanto, ecco perché questo post è in perfetta linea con il mio piano editoriale 🙂

Ma adesso la palla la passo a chi sta leggendo questo articolo lasciando a lui 2 scelte 🙂

Scelta 1:
Se c’è qualcosa di poco chiaro, non esitare a scrivere un commento, Salvatore sarà felice di risponderti 🙂

Scelta 2:
Se hai bisogno di un servizio che possa portare le performance del tuo sito web alle stelle,

non esitare a contattarmi a questo numero: +39 3925179956

Qualsiasi sia la tua scelta, a questo punto non puoi per nessun motivo non condividere questo post sul tuo social preferito.

 

6 COMMENTS

  1. No vabbè altri livelli! Una bomba di articolo, grandi. Salvatore parli di una tecnica di performance per forzare il caricamento dei restanti CSS..che tecnica sarebbe?

    Dici inoltre “Ho caricato tutti gli script Javascript all’evento load del browser.” ti sei avvalso di qualche plugin x forzare il caricamento dei ha nel footer o hai modificato il core del template?

      • Ciao Davide,
        no nessun push HTTP2. Il push lo faccio solo in alcuni casi e solo se sono sicuro che la risorsa venga utilizzata. Ad esempio puoi utilizzare il push per un webfont ospitato su un sito esterno, cosicché quando il parsing del CSS viene finito e si passa al print, il browser non dovrà attendere di scaricare il font prima di fare il rendering del testo, evitando l’effetto “blank text”.

        Per altri casi ti conviene usare il prefetch così è il browser ad avere la parola finale e decidere se scaricare o meno la risorsa che sei TU a definire critica. In questo caso essendo il CSS inserito molto in alto sul codice, non serve il PUSH: il parser HTML si accorge subito del CSS esterno e ne avvia il download, la differenza è proprio questione di microsecondi.

        A presto!

    • Ciao Francesco,
      per quanto riguarda questo caso ho deciso di far caricare il solo CSS Newsmag/style.css, avendo l’accortezza di inserirlo in alto sul codice HTML, mentre tutti i restanti CSS presenti all’interno della pagina li carico su scroll. Essendo che la maggior parte delle regole utilizzate sul sito stanno in quel CSS, il browser farà solo un leggero reflow al caricamento degli altri, poca CPU e quindi va bene.

      La prima tecnica, la più efficiente ma più corposa (che non ho applicato), consiste nell’utilizzare il solo CSS effettivamente utilizzato dalla pagina. Per fare ciò occorre estrapolarlo pagina dopo pagina, ecco un video che ti fa vedere come fare: https://www.youtube.com/watch?v=Lh1yXjysV7o

      Per tutte le ottimizzazioni fatte, compreso gli script Javascript, ho utilizzato una libreria PHP che ho scritto appositamente per applicare politiche di performance di questo tipo e che rilascerò presto anche sottoforma di plugin WordPress, quindi nessuna modifica al core del template.

      Naturalmente per consulenze molto profonde può essere richiesta qualche modifica al template, special modo se progettato male. Ad esempio 3 script non li ho potuti ottimizzare a causa del template, però la sfida stava appunto nel non modificare nessuna riga di codice.

      A presto!

  2. Marco, certo che con sto blog ci dai dentro di brutto! Leggo i tuoi post e rimango di stucco. Sei un vulcano in piena complimenti per tutto quello che fai e ovviamente complimento al tuo amico Salvatore che è riuscito a far caricare il tuo sito così velocemente. Ti seguo!

LEAVE A REPLY