Come ottimizzare il PageSpeed Insights del proprio sito

Come ottimizzare il PageSpeed Insights del proprio sito

Il nuovo strumento per misurare le prestazioni del proprio sito in termini di velocità è stato cambiato da Google da qualche tempo. Uno strumento sulla bocca di chiunque che pero’, al tempo stesso, è fonte di orrore e di terrore: molte notifiche non sono chiare e non si capisce bene come si ottimizzi. Chiunque abbia provato a verificare un URL di un portale qualsiasi, del resto, dovrebbe avere chiare due cose:

  • è una metrica ostica da ottimizzare, molto più di quanto non lo fosse in passato;
  • i risultati che produce, in molti casi, non sembrano neanche affidabili (nel senso che potrebbero cambiare sensibilmente tra due o più misurazioni successive).

I due punti precedenti farebbero rabbrividire e scoraggiare qualsiasi SEO o webmaster, in effetti, e ne farebbero evitare l’uso e l’adozione a qualsiasi livello. Del resto io stesso tendo più che altro ad affidarmi a GTMetrix, che avrà anche dei limiti ma che sembra decisamente più credibile soprattutto misurando la velocità in momenti diversi. Se non cambi nulla tra una misura e l’altra, in effetti, l’esito della valutazione (0=pessimo, sito lento, 100=ottimo, sito velocissimo) non dovrebbe, in teoria, cambiare. Eppure a volte cambia: ce ne faremo una ragione?

Le recensioni dei migliori servizi

🏆 Migliori Hosting Italiani
4.8 / 5 ( 13 voti ) Siteground
5 / 5 ( 10 voti ) Hosting economici, la nostra lista
4.6 / 5 ( 9 voti ) Hosting più veloci: quali sono e dove trovarli
4.5 / 5 ( 8 voti ) Keliweb
5 / 5 ( 5 voti ) Tophost (condiviso)
4.4 / 5 ( 5 voti )

Nonostante tutto ha senso lavorare su PSI, perchè a quanto pare influenza anche il ranking SEO della pagina e posso portare almeno un esempio virtuoso in tal senso: un sito che ho portato a 95/100 (da che era 60/100), ed ha aumentato il traffico da Google in modo abbastanza evidente. Ecco la prova, per quello che vale ed ammesso che sia dipeso da questo (considerate che ho ottimizzato il sito per il PSI con vari test, il tutto a partire da fine ottobre, quindi come date dovremmo esserci): il traffico, per quanto sia pochino di suo, è quasi triplicato in termini di click.

Cos’è il PageSpeed Insights

Si tratta della metrica di Google per misurare le prestazioni di un sito, in termini di un mix di fattori che misurano come l’utente veda, percepisca e riesca ad usare il vostro sito. Nello specifico, il PSI (PageSpeed Insights) di Google si basa su cinque aspetti:

  • Performance
  • Accessibility
  • SEO
  • Best Practices
  • Progressive Web App

che poi sono supercazzole belle e buone perchè, almeno secondo me, non rendono l’idea di una metrica che, tanto per cominciare, non misura solo la velocità del sito (che è un fattore tecnico comunque relativo e soggettivo), ma anche la “percezione” del sito da parte dell’utente.

“Percezione” …?!

Per percezione si intende che un sito carichi all’istante (o meno) nella sua interezza: se carica subito senza passaggi intermedi lunghi o evidenti, è un punto in positivo. Diversamente se carica a pezzetti, da’ l’idea di un qualcosa di disordinato o carica in parte bloccando l’interattività dell’utente, è un punteggio in negativo per il sito.

La percezione, in effetti, risiede proprio nell’idea che se un sito (avendo una connessione internet decente) carica in pochi millisecondi è cool, diversamente (con varie sfumature) non lo è. A livello di waterfall, come vedremo, più è breve e rapido il grafico meglio è – anche se questo ovviamente non tiene conto della qualità grafica della pagina, ma solo delle prestazioni nude e crude e della presenza di “colli di bottiglia” che rallentano.

In realtà il PSI, andando a vedere nello specifico, si basa su 6 parametri che andrebbero ottimizzati uno per uno, e che spesso si influenzano tra di loro. E li vedremo tutti di seguito.

Punteggio Google PageSpeed Insights 100/100 con WordPress: è possibile? In genere no, non lo è: inutile illudersi troppo. Realisticamente, seguendo questa guida, e perdendo un po’ di tempo sul sito, sarà possibile arrivare al massimo a 95/100. La metrica è difficile da ottimizzare, in genere, perchè cambia da sito a sito,e perchè  le variazioni da 0 a 60 sono relativamente facili da ottenere, e sono sempre più difficili nei settori successivi da 60 a salire.

Visualizzazione dei primi contenuti: i waterfall

Ecco la percezione di cui vi parlavo poco fa: il waterfall, mediante dei rettangolini colorati diversamente per ogni singolo file richiamato nella pagina, misura quanto tempo ci mette l’utente a vedere i primi contenuti, o se preferite la “durata della pagina bianca” quando provate ad aprire il sito. Si misura facilmente mediante appositi waterfall, i diagrammi a cascata che potete vedere sia con strumenti come Pingdoom Speed Tools che mediante Google Chrome, sezione Sviluppatori.

Ecco un esempio di diagramma waterfall: potete vedere come venga caricato prima l’URL della pagina, e poi le singole componenti (JS, immagini, CSS, …), eventualmente in parallelo. Questo grafico per essere efficente deve essere, da requisiti di efficenza:

  • più breve possibile (cioè veloce);
  • più basso possibile (cioè con poche chiamate HTTPS).

Per migliorare questo aspetto dovrete insomma economizzare le risorse del sito, della serie: meno roba ci caricate e meno chiamate HTTPS fate, meglio è. Che sembra una cosa brutale, ma è proprio così, alla fine dei conti.

Ridurre le chiamate CSS e JS via WordPress

Una cosa a prova di principianti da fare subito è: individuate eventuali chiamate 404 nel waterfall, sono molto lesive in termini di PSI ed è facile, in genere, eliminarle. Per scaricare i file CSS o JS indesiderati da WordPress potete ricorrere ai plugin qui elencati oppure, da bravi coder, utilizzare le seguenti chiamate (riporto un template) nel file functions.php o in un plugin:

//scarica file CSS non necessari
function project_dequeue_unnecessary_styles() {
    wp_dequeue_style( 'bootstrap-map' );
        wp_deregister_style( 'bootstrap-map' );
}
add_action( 'wp_print_styles', 'project_dequeue_unnecessary_styles' );

//scarica file JS non necessari
function project_dequeue_unnecessary_scripts() {
    wp_dequeue_script( 'modernizr-js' );
        wp_deregister_script( 'modernizr-js' );
    wp_dequeue_script( 'project-js' );
        wp_deregister_script( 'project-js' );
}
add_action( 'wp_print_scripts', 'project_dequeue_unnecessary_scripts' );

Ovviamente dovete passare come unico parametro la stringa del nome dell’handle, che andrà tracciata dal codice del theme caso per caso. Potete applicare anche logiche selettive sull’unload di script e file CSS, nel senso di far caricare i file CSS e JS solo dove e quando servono, usando condizioni come ad esempio is_page(), is_category() e via dicendo.

Quelli bravi riescono, in effetti, a ridurre le chiamate senza intaccare più di tanto la grafica e le funzionalità del sito, tenendo conto che spesso il margine di azione è minimo, a volte talmente tanto da rendere più conveniente di cambiare grafica e ristrutturare da zero il sito.

Nota per geek: per migliorare le chiamate HTTPS non basta passare ad HTTP/2, anche se sulla carta (parallelizzando) dovrebbe essere così. Questo per due ragioni: i tool per la velocità non sempre lo considerano, e non tutti i browser lo supportano, ad oggi. Toglietevi dalla testa che si possano usare soluzioni pre-confezionate per il problema della lentezza lato PSI perchè non è affatto così, purtroppo.

Vediamo ora i singoli parametri e come ottimizzarli, uno per uno.

Indice velocità

Questo indice è facile da capire, e fmisura in secondi quanto tempo impiega la pagina a finire il caricamento, quindi la durata dall’inizio alla fine del waterfall.

Si migliora in vari modi: sia seguendo i suggerimenti indicati che usando hosting di qualità, abilitando la cache, configurando per bene il file HTACCESS

Tempo per interattività

Indica il tempo che passa da quando l’utente inizia a vedere il sito a quando effettivamente riesce ad interagire con lo stesso.

Chiariamo:

  1. 10:00:00 – apro pippo.it
  2. 10:00:01 – inizio a vedere la pagina pippo.it, ma manca il CSS
  3. 10:00:02 – inizio a vedere la pagina pippo.it, ma manca il JS – vorrei cliccare sul menu, ma non posso
  4. 10:00:04 – caricamento…
  5. 10:00:02 – finalmente posso interagire col menu – tempo per interattività = 10 secondi

Per ridurlo, o provare a farlo, si possono seguire i consigli indicati alle voci Elimina le risorse di blocco della visualizzazione e successive.

Visualizzazione primi contenuti utili

Misura il tempo necessario al sito perchè vi faccia vedere qualcosa, e corrisponde con l’area bianca in cui non si vede ancora nulla (ammesso che possiate misurarlo con CloudFlare) + l’area in cui sono presenti contenuti parziali + i contenuti utili sono visibili.

Anche qui si ottimizza in vari modi, ma l’idea è sempre quella di ridurre il carico di lavoro necessario allo stretto, strettissimo necessario.

Prima inattività CPU

Parametro che tiene conto di due cose: il tempo di interazione che abbiamo visto prima (che dipende dal peso di JS nel suo insieme, essenzialmente), ed il fatto che il sito effettivamente risponda, quindi si considera anche il tempo che impiega a “reagire” alle vostre interazioni. Pensate a certi form che, ad esempio, vi fanno selezionare la città e ci impiegano un po’ ad attivare il trigger con le province: ecco, quello è un classico esempio di inattività CPU troppo alta, da migliorare.

Si migliora ottimizzando il database e ricorrendo a librerie JS efficenti di ultima generazione, in genere.

Ritardo prima interazione potenziale max

Misura quanto tempo trascorra tra la prima interazione ed il resto: non è una metrica vitale per il PageSpeed Insights, tant’è che sembra ufficialmente non pesare affatto nel punteggio da 0 a 100. In teoria dovrebbe rimanere attorno ai 50ms (secondo loro), pero’ è chiaro che si tratta di una stima solo orientativa. Non è essenziale, almeno nell’ottica applicata che è già complessa di suo, fissarsi troppo su questo parametro.

Nota per markettari: su molti blog scrivono che il PSI è trascurabile, il che può essere vero – ma solo nella misura in cui non sia un fattore competitivo rispetto ad altri concorrenti. Se ad esempio i vostri competitor hanno ottimizzato pagine web posizionate prima della vostra su Google, può avere senso cercare di superarli.

I vari punti non sono equivalenti tra di loro e pesano in modo diverso sulla valutazione del punteggio; il peso delle singole componenti sul punteggio, dal più importante al meno rilevante, è il seguente:

  1. time to interactive
  2. speed index
  3. first contentful paint
  4. first cpu idle
  5. first meaningful paint
  6. estimated input latency

PageSpeed Insights non è semplicemente “la velocità del sito”

Ripartiamo un po’ dall’inizio, a questo punto, e cerchiamo di capire meglio quali strumenti ci siano offerti per ottimizzare il PSI (PageSpeed Insights) e farlo rendere al meglio, anche in considerazione del fatto che è ormai integrato nella Search Console e, di fatto, sembrerebbe essere stato eletto a fattore di posizionamento vero e proprio. Questa metrica, a mio avviso, viene interpretata in modo un po’ troppo acritico: c’è chi la osanna in modo incondizionato – e questo avviene soprattutto tra i SEO high-level che non si occupano di operativo, o che magari delegano il compito di ottimizzare ai propri collaboratori. Di contro, c’è anche chi la osteggia proprio per un mix di frustrazione (non è una metrica chiara, nè tantomeno troppo coerente) e di mancata comprensione dei suoi dettagli.

La cosa da capire sul PageSpeed Insights, prima di procedere oltre, è che non si tratta di una metrica come quella offerta da altri tools: non è semplicemente un indicatore della velocità di caricamento del sito. Quindi non è nemmeno vero quello che abbiamo scritto, semplificando, all’inizio:

0=pessimo, sito lento, 100=ottimo, sito velocissimo

perchè il tutto passa per una serie di complicati parametri che si occupano della percezione da parte dell’utente, o meglio: il PSI sembra essere una media tra 4 fattori che simulano la reazione ed il comportamento dell’utente medio qualora sia messo davanti al nostro sito. Proviamo quindi ad immaginare come questo punteggio venga calcolato ricorrendo ad un esempio facile: è direttamente l’utente a dare un voto della propria User eXperience, in cui darà 0 se il sito non funziona, darà 100 se tutto va a meraviglia e (nota bene!) se trova subito quello che stava cercando, se ogni pezzo del sito è dove si aspettava che fosse, se riesce a trovare subito quello che voleva e via dicendo.

PageSpeed Insights è espresso da un mix di fattori:

  • velocità del sito (intesa come TTFB, per intenderci);
  • tempo minimo di interazione (cioè quanto passa tra l’apertura del sito e la possibilità per l’utente di interagire con lo stesso);
  • tempo minimo di caricamento (cioè quando l’utente inizia a vedere la pagina, anche solo parzialmente, e quanto dura questa fase intermedia)
  • altri fattori di UX e percezione

Passiamo alla fase successiva, perchè ci sono cose importanti da inquadrare, a questo punto.

100/100 si ottiene con un file statico di testo, oppure HTML senza CSS nè JS

Per spiegare ancora meglio la mia ottica di ottimizzazione (che è la mia, beninteso, nel senso che potrebbe non coincidere con quella di altri colleghi) partirei da un’osservazione che ho fatto un po’ per caso, ovvero provare a misurare il PSI dell’URL licenza.html presente in qualsiasi sito in WordPress. In pratica, quando misura di PSI un file HTML statico?

Ecco la risposta:

https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Ftrovalost.it%2Flicenza.html

in questo caso il punteggio sarà 100/100. Quindi, di fatto, analizzando il contenuto del file in questione, si nota che:

  • il CSS, che è presente, è stato incluso con il tag <style> senza fogli di stile esterni;
  • non è presente alcun file JS;
  • non è presente alcuna immagine o video;
  • per il resto è presente solo HTML.

In pratica le pagine minimal, ad un primo sguardo, sono quelle tendenzialmente favorite per un buon PSI. Questo sembra suggerire, facendo un po’ di reverse engineering, che l’algoritmo del PSI si basi sul numero di chiamate HTTPS e su un fattore non solo di leggerezza della pagina (che è un fatto tecnico) ma anche sull’aspetto amichevole della pagina stessa (che per il file della licenza è facile da individuare: font chiaro, nessun fronzolo, nessun tempo morto di caricamento: in fondo volevo solo leggere la licenza di WordPress).

Ovviamente, pero’, bisogna fare i conti con la realtà: non tutti i siti si possono effettivamente rendere minimal come si vorrebbe.

Sito statico o dinamico è la stessa cosa, per il PSI

Fulminato da questa intuizione mi sono fatto trasportare dall’associazione di idee: ho pensato subito che basti staticizzare un sito in WordPress, ad esempio, per riuscire a migliorare il punteggio. Non è così, e la cosa mi ha spiazzato per diversi giorni: una copia di un sito (quindi senza database nè PHP, solo HTML + CSS + JS) realizzata con WP2Static, almeno nei casi che ho analizzato, non cambiava nulla. Il risultato in termini di PSI era uguale: nè migliore, nè peggiore.

Quindi, per quanto l’hosting influenzi una parte del discorso (e soprattutto in termini di TTFB, per quello che ho capito), quello che devi ottimizzare per migliorare il tuo PSI passa per l’ottimizzazione del markup HTML a vari livelli. Avere un CMS o meno, ottimizzare il database, usare file statici o dinamici è spesso ininfluente lato PSI, per quanto possa sembrare strano da credere. Ovviamente poi dipende anche dal theme, ma in genere è così.

A meno che, ovviamente, non abbiate un hosting condiviso da 10 € all’anno, che sicuramente non è l’ideale per fare discorsi di ottimizzazione PSI ad alti livelli — alternative suggerite: vedi qui.

Ridurre le chiamate HTTPS

Googledice che per migliorare il PSI, in molti casi, devi effettuare interventi esoterici del tipo:

  • Elimina le risorse di blocco della visualizzazione
  • Assicurati che il testo rimanga visibile durante il caricamento dei caratteri web
  • Pubblica immagini in formati più recenti
  • Rimuovi il CSS inutilizzato
  • Riduci il tempo di esecuzione di JavaScript
  • Evita di usare un DOM di dimensioni eccessive
  • Riduci al minimo il lavoro del thread principale
  • Pubblica le risorse statiche con criteri della cache efficaci
  • Riduci al minimo la profondità delle richieste fondamentali

La maggiorparte dei SEO e dei webmaster più esperti non sa precisamente che cosa significhi (e non li biasimo per quello: ci ho messo settimane a capire cosa si intende per “DOM di dimensioni eccessive”, ad esempio), visto che sono tutte caratteristiche da skill medio-alti e da sviluppatore “like a pro”.

La cosa migliore, pertanto, mi sembra analizzare questi punti uno per uno, perchè altrimenti difficilmente se ne esce. Sommando i vari contributi ed avendo cura che il sito funzioni comunque — visto che andremo a scaricare i vari “pezzi” non necessari lato HTML/JS/CSS e prenderemo un po’ di provvedimenti.

Il tutto a partire da un semplice presupposto: anche se riducete il numero di plugin, installate la cache e ricorrete ad un dedicato da 60€ / mese, non è detto che basti a migliorare il PSI. Per migliorarlo dovreste essere disposti a:

  • cambiare grafica al sito
  • analizzare il codice HTML /CSS/JS pagina per pagina
  • rimuovere le immagini non essenziali dal sito
  • cambiare alcune feature inessenziali del sito
  • eliminare servizi aggiuntivi o di automazione che potrebbero rallentare il server

Se già sapete che questa cosa comporta troppa fatica o la giudicate inapplicabile, pazienza: ci divertiremo noialtri :-)

Elimina le risorse di blocco della visualizzazione

Problema: ci sono troppe chiamate HTTP(S) a file CSS e JS, che tendono ad essere bloccanti per il caricamento, risultando nel fatto che ad esempio la grafica inizialmente carica a metà.

Soluzione: una possibilità può essere quella di applicare l’attributo async o defer agli script JS, e se possibile applicare un rel=”preload” ai link per l’importazione di CSS esterno (in questo caso va inserito un tag <noscript> con un <link> all’interno, vedi qui). Se volete semplificare brutalmente, potete anche includere direttamente nella pagina tutti i file CSS e JS, ammesso che non siano troppi.

Diversamente, tocca ingegnarsi un minimo a cercare la soluzione migliore:

  • rel=”preload” da solo non basta, perchè è essenziale che ci sia l’alternativa <noscript>
  • async e defer sono invece quasi equivalenti per i JS, la differenza risiede nelle tempistiche di caricamento e, all’atto pratico, tocca sperimentare quale soluzione sia migliorativa in termini di PSI e faccia funzionare lo stesso il sito (in particolare gli oggetti delicati sono i menu, il caricamento delle immagini e tutta la parte interattiva). Questo plugin qui, in genere, aiuta a risolvere e gestire il problema.
  • Continuate a leggere, perchè non finisce qui: il blocco può essere infatti anche determinato da script e CSS giganteschi, non minificati o non utili

Assicurati che il testo rimanga visibile durante il caricamento dei caratteri web

In questo caso c’è un problema di caricamento di font esterni, che andrebbe affrontato in modo piuttosto tecnico e che trovo francamente troppo complesso: nella pratica io faccio due cose, o scarico i font in locale, o li metto su una CDN oppure, ancora, uso un plugin come Autoptimize per togliere di mezzo i Google Fonts, qualora siano loro la causa del problema.

Pubblica immagini in formati più recenti

Qui arriviamo ad un punto decisamente controverso, per quanto molti blog ne parlino (secondo me senza aver troppo centrato il punto): Google PSI richiederebbe un “formato più recente” per le immagini, non è troppo chiaro a cosa si riferisca e sembra che sia da preferire il formato webp. Che non mi sento di utilizzare, francamente, visto che è scarsamente supportato dai browser — almeno ad oggi.

Con le immagini esportate da GIMP e post-prodotte da WP, per esempio, sembra che le immagini siano un problema per qualsiasi sito: ecco perchè, nel dubbio, togliere di mezzo le immagini di troppo è un primo modo per ridursi il carico di lavoro, e lavorare su formati moderni (qualsiasi cosa significhi, a questo punto) dovrebbe essere ideale per risolvere e migliorare questa metrica.

Ho anche fatto qualcosina di interessante utilizzando una CDN per le immagini come quella di KeyCDN (quella gratuita di Jetpack, invece, non sembra produrre alcun risultato utile).

Rimuovi il CSS inutilizzato

problema: Google rileva del CSS che non viene applicato nella pagina

Soluzione: trovare un theme che usi in modo realmente razionale il CSS è quasi impossibile. Dovreste riprendere in mano il theme, darlo in pasto ad un developer e farlo ottimizzare in modo che carichi solo lo stretto necessario su ogni pagina — insomma, non potete farlo :-)

Una soluzione più umana può essere quella di sfruttare un plugin come Clearfy, Assets Manager o Assets CleanUp (il mio preferito, quest’ultimo). Questi plugin fanno un qualcosa a cui nessuno sembrava aver pensato, della serie: togliere di mezzo dall’origine il CSS ed il JS inutilizzato, evitando proprio di caricarlo dove non serve. Ci sono plugin come Contact Form 7, ad esempio, che schiaffano il proprio JS e CSS che invece, per logica, andrebbe solo nelle pagine del modulo contatti: con Assets CleanUp potrete decidere, pagina per pagina, cosa caricare e cosa no. La versione free è più che sufficente per portare a 90–95 il vostro punteggio con (una volta capito come funziona) circa un paio d’ore di lavoro, in cui pero’ conviene lavorare sempre su una copia in staging e poi esportare il risultato via plugin. Assets CleanUp fa anche lavoro di compressione e minificazione con conseguente riduzione delle chiamate, ma ha l’unica pecca che, ovviamente, va usato con perizia: se non caricate JS o CSS necessari, il sito sarà graficamente degradato.

Nota ironico-sarcastica: se sfondate il CSS ed il JS di una pagina su cui state ottimizzando in quest’ottica, il PSI, al momento attuale, non se ne accorgerà e restituirà punteggi altissimi. Quindi, in questo senso, non è una questione di grafica, con buona pace dei grafici in ascolto :-)

Riduci il tempo di esecuzione di JavaScript

Problema: il JS è troppo corposo, lungo da valutare o impegnativo da caricare.

Soluzione: drastica, togliere di mezzo il JS con un uso ragionato di Assets CleanUp. Meno drastica, intervenire sul codice del sito e cercare di individuare perchè perda così tanto tempo e se sia davvero necessario che lo perda.

Evita di usare un DOM di dimensioni eccessive

Il DOM (Document Object Model) è il blocco gerarchico che viene generato da HTML, JS e CSS mediante il CMS (siti dinamici alla WP) oppure a mano (se il sito è statico).

Se è troppo grosso, in genere, si può pensare di minificarlo (HTML minify), ma questo non sempre è sufficente allo scopo. Allora che si fa? Facile: si usano theme minimal che evitano elegantemente il problema, e che Google sembra amare particolarmente. Se un theme spettacolare graficamente avesse un DOM troppo grosso, in genere, è praticamente impossibile ridurne le dimensioni senza modificare il theme stesso o ricorrere a soluzioni esterne (del tipo: comprimere tutte le pagine mediante una cache statica esterna, tipo quella di CloudFlare).

Riduci al minimo il lavoro del thread principale

Problema: CSS e JS occupano un carico di lavoro che per il browser medio è impegnativo da caricare. Quindi dovrete:

  • ripulire il codice CSS dell’inutile, comprimerlo e ridurre le chiamate HTTPS (minify);
  • ripulire il codice JS dell’inutile, comprimerlo e ridurre le chiamate HTTPS (minify);
  • caricare nel sito solo quello che serve; se non basta, dovrete cambiare theme e passare ad uno più veloce e semplice da gestire.

Pubblica le risorse statiche con criteri della cache efficaci

In questo caso il problema è relativamente più semplice da risolvere: non c’è cache nel sito, quindi abilitatela (basta quasi sempre un semplicissimo plugin come Cache Enabler), poi se possibile — e se ricevete questa notifica — attivate una cache via reverse proxy, quindi quella di Jetpack oppure quella offerta da vostro hosting (Plesk di VHosting la consente, ad esempio).

Riduci al minimo la profondità delle richieste fondamentali

Il senso è simile a quello di due punti fa: non usate DOM di dimensioni colossali perchè, in genere, i browser e GoogleBot potrebbero fare fatica a scansionarli o leggerli, con ripercussioni negative anche in ambito di indicizzazione.

Plugin utili per migliorare il PageSpeed Insights

Per avvicinarsi a punteggio 100/100 su WordPress, quindi, eccovi un bel set di plugin da utilizzare. Fate attenzione che molti non sono compatibili tra di loro e potrebbero, se non state attenti, sfasciarvi il sito.

Suggerimenti utili e snelli sono, almeno in teoria, e riassumendo:

  • usare theme leggeri e funzionali;
  • ridurre all’osso il numero di plugin (da 15 in poi il sito rallenta, in genere);
  • ottimizzare tutte le immagini via CDN, ad esempio con KeyCDN;
  • Cache Enabler
  • Assets CleanUp
  • Autoptimize (alternativo al precedente, NON usarli assieme)
  • Async Javascript
  • Regalo finale: qui trovate una configurazione HTACCESS quasi universale, ottimizzata per la velocità ed utile, per la cronaca, e valida per quasi tutti gli hosting. Da usare in modo critico, ovviamente…

Plugin inutili per migliorare il PageSpeed Insights

In genere le soluzioni preimpostate non vanno mai bene, meno che mai in questo caso: a poco serve installare plugin di cache avanzatissimi, se poi avete problemi con un DOM troppo corposo, se il theme non lavora bene su mobile e se il reverse proxy non sapete nemmeno cosa sia. A poco serve anche disinstallare plugin e sperare nel miracolo, perchè questo aiuta al limite a migliorare il TTFB, come suggerito prima. A nulla serve minificare a caso o usare plugin all in one o bundle vari, perchè la cosa migliore secondo me è usare plugin modulari facendo attenzione ad eventuali conflitti.

0 voti


Informazioni sull'autore

Salvatore Capolupo

Consulente SEO, ingegnere informatico e fondatore di Trovalost.it, Pagare.online, Lipercubo.it e tanti altri. Di solito passo inosservato e non ne approfitto.