I 10 malintesi sulle prestazioni Web

In WP Rocket, la nostra missione è educare gli utenti sull'importanza delle prestazioni web rendendole il più semplici e accessibili possibile. È una bella sfida: le prestazioni web non sono un argomento facile, e l'ottimizzazione di un sito web per migliorare le prestazioni è ancora meno facile da spiegare e capire. Inoltre, trovare informazioni attendibili è difficile: l'argomento è complesso e talvolta soggettivo.

Questo articolo evidenzia alcuni concetti fuorvianti su ciò che conta quando si identificano le azioni chiave di ottimizzazione delle prestazioni per velocizzare un sito web. Continua a leggere e troverai un elenco delle idee sbagliate più comuni che abbiamo riscontrato. Spiegheremo perché non sono corretti e condivideremo come affrontiamo le sfide delle prestazioni web con il nostro plug-in.

Quali sono le idee sbagliate più comuni sulle prestazioni Web?

Scopriamo le idee sbagliate che consideriamo più rilevanti riguardo all'ottimizzazione delle prestazioni web.

1. Ritarda JavaScript

L'ottimizzazione dei file JavaScript è una delle ottimizzazioni delle prestazioni web più impegnative. È anche uno dei più efficaci per migliorare le prestazioni e le metriche chiave come Core Web Vitals. In altre parole, non puoi evitare di ottimizzare JavaScript se vuoi un sito web veloce. Un modo efficace per procedere è ritardare i file JS che non devono essere eseguiti immediatamente. Di conseguenza, la pagina verrà caricata più velocemente e il browser eseguirà JavaScript solo quando richiesto dall'interazione dell'utente.

L'idea sbagliata è che tutti i file JS dovrebbero essere ritardati. La verità è che questo spesso danneggerà l'esperienza dell'utente e potrebbe persino compromettere la funzionalità del sito. I JS critici non dovrebbero mai essere ritardati, come quelli relativi alle risorse above the fold (ad es. Menu) e agli script di tracciamento (ad es. Google Analytics). Queste risorse devono essere disponibili nelle prime fasi del caricamento della pagina per garantire un'esperienza utente fluida.

Ora è facile capire perché sapere quali file JS dovrebbero essere esclusi dal ritardo e come farlo è fondamentale.

Ad esempio, WP Rocket ti consente di gestire facilmente la funzione di esecuzione Delay JS. L'opzione semplifica il ritardo di JS, un'attività di ottimizzazione chiave. Inoltre, WP Rocket ti consente di escludere i file JavaScript sia manualmente che grazie all'esclusione con un clic rilasciata con la nostra ultima versione principale, WP Rocket 3.13.

Abbiamo chiesto ad Adam Silverstein, Developer Relations Engineer presso Google , la loro opinione sul ritardare sempre JavaScript e il suo impatto sulle prestazioni. Conferma il nostro punto di vista e aggiunge: “In genere, per i siti con rendering su server come lo sono di solito i siti WordPress, la maggior parte di JavaScript può essere rinviata a meno che non sia richiesto all'inizio del ciclo della pagina per qualche motivo. Un esempio sono gli script di analisi in cui si desidera acquisire i dati il ​​prima possibile: in questo caso l'attributo async è più appropriato. Un rischio potenziale con il differimento degli script è che se altri script o script incorporati dipendono dallo script differito (e non sono anch'essi differiti), la dipendenza può interrompersi”.

Quindi, è il momento di esaminare l'idea sbagliata sul rinvio di JavaScript.

2. Rinviare JavaScript

Qui, l'idea sbagliata è che tutti i JS possano essere rinviati.

La verità è che il rinvio di JavaScript è fondamentale fintanto che rispetta le dipendenze. In altre parole, non è consigliabile rinviare JS senza considerare le dipendenze.

Ad esempio, uno script in linea che utilizza la libreria jQuery avrà bisogno di jquery.js per essere eseguito prima che possa essere eseguito senza arresti anomali. Se jquery.js viene posticipato, lo script inline non troverà jQuery dichiarato e genererà un errore della console jQuery non è definito, impedendo l'esecuzione del codice, interrompendo la funzionalità correlata e potenzialmente interrompendo il layout e il funzionamento complessivo della pagina anche.

Adam Silverstein menziona una nuova proposta di script API per WordPress che sta per essere rilasciata. Aiuterà la strategia di differimento definendo tattiche di caricamento e prevenendo problemi di dipendenza.

Adam spiega: " Nell'approccio proposto per il core, stiamo gestendo automaticamente i casi di rinvio con l'approccio di base alla strategia di script, incluso il controllo che anche gli script dipendenti sono differibili e la gestione dell'esecuzione ritardata degli script in linea che dipendono da uno script differito".

Quando si tratta di rinviare JavaScript, WP Rocket ha molte esclusioni automatiche per prevenire i conflitti. Ad esempio, quando Avada è abilitato, WP Rocket esclude automaticamente la libreria jQuery e lo script esterno di Google Maps.

La nuova API Script consentirà al nostro plug-in di estendere ulteriormente la libreria delle esclusioni. Di conseguenza, sarà sempre meno probabile che il tuo sito web si interrompa durante il rinvio di JavaScript.

3. Riduci i CSS usati

Oltre all'ottimizzazione JavaScript, la riduzione dei CSS utilizzati è uno dei modi più efficaci per migliorare le prestazioni del tuo sito web. Esistono due modi per gestire tale ottimizzazione:

• Incorporare i file CSS, il che significa integrare i CSS nella stessa pagina utilizzando un tag `style`.
• Usa file esterni separati.

L'idea sbagliata è che fornire il CSS utilizzato in file separati sia sempre il modo migliore per affrontare tale ottimizzazione.

La verità è che incorporare CSS va benissimo e presenta due importanti vantaggi dal punto di vista delle prestazioni e dell'esperienza utente:

• È un processo più rapido perché il browser effettuerà solo una piccola richiesta per verificare l'aggiornamento della pagina. Se la pagina non è cambiata, come generalmente accade, il browser fornirà una copia cache della pagina. Per questo motivo, l'Inline Used CSS migliorerà le prestazioni: il browser non caricherà e non analizzerà un file CSS ma elaborerà direttamente il CSS inline sulla pagina.
  
• L'incorporamento di tutti i CSS della pagina previene problemi come FOUC (Flash di contenuto senza stile) e non influisce sull'esperienza dell'utente, come potrebbe fare l'utilizzo del Critical Path CSS in aggiunta a un file separato. Per evitare il peggioramento di altre metriche, dovrebbe essere richiesto il Critical Path CSS quando il CSS utilizzato viene fornito utilizzando un file.

Ecco perché WP Rocket incorpora CSS e consente a chiunque di sfruttare una funzionalità avanzata come la rimozione di CSS inutilizzati con un solo clic:

Ancora una volta, Adam Silverstein di Google condivide il nostro punto di vista. Gli abbiamo chiesto qual è il modo più efficace per fornire il CSS utilizzato. Dice: "La mia aspettativa è che per le dimensioni CSS più piccole, almeno, l'incorporamento sarà più veloce riducendo la necessità di caricare il file CSS aggiuntivo. La "penalità" per ciò può variare a seconda delle condizioni, ad esempio il dispositivo e la rete che l'utente sta utilizzando".

4. Ospita i font in locale

Se gestisci un sito Web WordPress, potresti già sapere che l'hosting dei caratteri in locale può essere un'altra buona scelta per migliorare le prestazioni. Inoltre, l'hosting di font locali è essenziale per rispettare le regole del GDPR.

Per quanto riguarda i caratteri di Google, è importante controllare da dove verranno inviati i file in modo che non dipendano da Google Fonts CDN, soprattutto se non funziona bene per gran parte del pubblico.

Un malinteso comune è che ospitarli migliorerà automaticamente il tempo di caricamento del tuo sito web.

La verità è che i caratteri di Google saranno più veloci solo se visualizzati nella stessa zona in cui si trova il visitatore.

Se il sito Web utilizza un CDN, i caratteri di Google saranno più veloci solo se la copertura del CDN è migliore di quella dei caratteri di Google, che dipende fortemente dalla posizione del visitatore.

Abbiamo eseguito dei test per convalidare questo presupposto e abbiamo scoperto che i font ospitati erano i meno performanti per i visitatori distanti per quanto riguarda Time to First Byte, una metrica chiave per aumentare la velocità del tuo sito web.

Questi dati sulle prestazioni sono importanti perché influenzeranno direttamente l'elemento LCP se si tratta di un testo che utilizza i caratteri di Google.

L'altro malinteso sull'hosting dei font in locale è che WP Rocket non può precaricare i font di Google. Questo è falso: il nostro plug-in può precaricare automaticamente i caratteri Google se abilitato dall'opzione Rimuovi CSS inutilizzati.

5. Suggerimento per la risorsa Fetchpriority

Il fetch priority hint è un attributo che indica al browser la priorità delle risorse da rilevare e scaricare in modo che la pagina possa caricarsi il più velocemente possibile. Attualmente, il suo utilizzo è ancora limitato a poco meno del 70% degli utenti in tutto il mondo.

L'idea sbagliata è che dovresti sempre usare il suggerimento per la risorsa fetchpriority. La verità è che il suggerimento sulle risorse può sembrare un must, ma non è così semplice come sembra.

Sebbene fetchpriority hint renda disponibili le risorse critiche in tempo, può deteriorare le prestazioni se le risorse vengono recuperate senza la giusta priorità. Si tratta di un'attività di ottimizzazione delle prestazioni molto complessa ed è difficile implementarla senza testare o analizzare le pagine.

Allo stesso tempo, l'impatto di questa attività sulle prestazioni è limitato a ciò che può essere automaticamente prioritario o deprioritizzato.

Abbiamo elencato alcuni esempi per spiegare come fetchpriority dipende da diversi fattori.

• Logo e immagine LCP : questo è facile: questi elementi sono candidati ovvi con un'alta priorità di recupero.
  
• Cursori : inizia a diventare complicato.
  
  Le immagini di un dispositivo di scorrimento sopra o vicino alla piega avranno una priorità di recupero soggettiva a seconda che causino un problema.
  
  Se il dispositivo di scorrimento è vicino alla piega ma ritenuto critico per l'esperienza dell'utente, la sua prima immagine dovrebbe avere la massima priorità.
  
  Se uno slider è ritardato, non è necessario dare la priorità al recupero delle sue immagini, anche se è above the fold.

• Risorse CSS, JS e di terze parti : solo i rispettivi sviluppatori possono valutare se devono essere prioritarie o depriorizzate. E anche con il loro input e quando si mescolano diversi plug-in e risorse, la priorità di recupero sarebbe basata sui casi.

Puoi vedere cosa intendiamo quando diciamo che i suggerimenti sulle risorse non sono così facili come potresti supporre.

Ecco perché WP Rocket non include ancora tale funzionalità, sebbene la fetchpriority possa avere un impatto positivo sulla velocità del tuo sito web se utilizzata correttamente. Stai tranquillo, il nostro plug-in aiuta a ottenere prestazioni ottimali grazie ad altre funzionalità potenti e avanzate.

Abbiamo anche chiesto al team di Google qual è la loro opinione sull'utilizzo di un'alta priorità di recupero per tutte le immagini above the fold e una bassa per tutte le immagini below the fold.

Adam Silverstein spiega: “In generale, l'obiettivo dovrebbe essere quello di aggiungere fetchpriority=high solo alle immagini critiche perché aggiungerlo a più immagini generalmente annullerà i vantaggi. In genere si desidera impostare l'immagine LCP con questo attributo, ma riflettere attentamente prima di utilizzarla su molte altre risorse. Questa pagina è la migliore risorsa per comprendere la priorità di caricamento. In generale, tutte le immagini iniziano con una priorità bassa. Le immagini all'interno del viewport iniziano con priorità "bassa" e poi al momento del layout, quando il browser si rende conto che si trovano nel viewport, vengono potenziate a "alta". Taggandolo nel markup usando fetchpriority="high", possono iniziare immediatamente da "high" e caricarsi molto più velocemente. Se tagghi troppe immagini come priorità alta, competeranno per le stesse risorse. Una possibile eccezione potrebbe essere il tentativo di contrassegnare l'immagine LCP sia per i punti di interruzione desktop che per dispositivi mobili (che potrebbe essere un'immagine diversa). La funzione 'esperimenti' di WebPageTest è un ottimo modo per testare questo”.

Parlando di fetchpriority, è interessante sottolineare che il Core Performance Team ha proposto di aggiungere l'attributo fetchpriority=”high” alle immagini LCP nel core di WordPress per migliorare le prestazioni LCP.

Avviso spoiler : abbiamo lavorato su un modo automatico per aggiungere la priorità di recupero sull'elemento LCP, rendendo il più semplice possibile per i nostri utenti beneficiare dell'opzione. Potresti vedere di cosa stiamo parlando in una delle nostre prossime uscite.

6. Caricamento pigro delle immagini di sfondo

Il lazy loading è un'altra importante tecnica di ottimizzazione delle prestazioni web. Consente al browser di caricare le immagini solo quando necessario in modo che non tutte le immagini vengano caricate contemporaneamente e la pagina possa essere visualizzata e visualizzata rapidamente.

Ecco perché il caricamento lento delle immagini di sfondo può risparmiare le richieste di immagini non necessarie below the fold, migliorando così le prestazioni.

L'idea sbagliata è che le immagini di sfondo aggiunte al CSS interno (tag `style`) e ai file CSS possano essere caricate in modo lazy. La verità è che WordPress, le librerie lazyload e il lazyload nativo non consentono questa ottimizzazione, che deve essere accurata e non è così semplice come potrebbe sembrare.

In WP Rocket, abbiamo lavorato su una funzione specifica per rendere questa ottimizzazione semplice e automatizzata pur essendo precisa.

7. Immagini LCP vs. Immagini above the fold

Parlando di lazy loading e dell'attributo fetch priority, un altro malinteso è che tutto above the fold dovrebbe essere impostato su un valore alto (fetchpriority=high).

Adam Silverstein spiega: “Le ottimizzazioni Fetchpriority dovrebbero idealmente essere applicate solo all'immagine LCP. Allo stesso tempo, tutte le immagini above the fold dovrebbero evitare il lazy loading”.

E aggiunge un esempio: “Diciamo che ci sono sei immagini above the fold e un'immagine LCP. Quindi, l'approccio migliore sarebbe omettere il lazy loading da tutte le immagini e applicare fetchpriority all'immagine LCP”.

8. Escludi immagini above-the-fold dal caricamento lento

Se hai familiarità con le best practice per l'ottimizzazione delle prestazioni web, è probabile che tu sappia che escludere le immagini above the fold dal caricamento lento è un buon modo per accelerare le prestazioni del tuo sito web.

Questo è in parte un malinteso, poiché dipende principalmente da come lo gestiscono gli strumenti attuali.

Sebbene l'esclusione delle immagini above the fold possa aumentare la velocità del tuo sito Web, potrebbe comportare il salto di immagini aggiuntive dal lazy load se non è implementata per le immagini attualmente incluse above the fold. Di conseguenza, la pagina verrà caricata più lentamente invece del contrario.

Inoltre, il numero di immagini da escludere di solito differisce da un viewport all'altro, rendendo l'ottimizzazione delle prestazioni più difficile da gestire.

Tale ottimizzazione richiede il controllo per trovare immagini accurate da saltare dal caricamento lento.

Le attuali soluzioni non sono automatizzate e si basano su una "ipotesi" piuttosto che sull'esclusione delle immagini effettive. Ecco perché abbiamo sviluppato la soluzione più semplice possibile per consentire a chiunque di affrontare questa ottimizzazione delle prestazioni.

Abbiamo fatto alcuni test e ottenuto risultati interessanti. Se implementato correttamente ed escludendo il numero esatto di immagini above the fold dal caricamento lento, può migliorare metriche come First Contentful Paint, Largest Contentful Paint e Speed ​​Index. Inoltre, può gestire i controlli di PageSpeed ​​Insights come Evita enormi payload di rete e Mantieni basso il conteggio delle richieste e ridotte le dimensioni dei trasferimenti.

Nel frattempo, WP Rocket ti consente di risolverlo con un plug-in di supporto.

9. Immagine di anteprima dell'iframe di YouTube

Potresti avere ragione se pensi che abilitare l'immagine di anteprima dell'iframe di YouTube aumenterà la velocità del tuo sito web. Questa soluzione evita di caricare gli script di YouTube e avvia il caricamento del video solo se l'utente fa clic sul pulsante di riproduzione.

Tuttavia, a questo punto dell'articolo, dovresti avere familiarità con il concetto di: dipende.

L'implementazione dell'immagine di anteprima dell'iframe di YouTube per ottimizzare le prestazioni non funzionerà per tutti i siti web. Potrebbe causare problemi se l'elemento genitore che contiene il video stilizza le immagini in modo inutilizzabile. In tal caso, l'immagine di anteprima non verrà visualizzata correttamente e potrebbe essere necessario un codice CSS aggiuntivo per annullare lo stile in conflitto dell'elemento principale.

L'iframe probabilmente verrà caricato allo stesso modo poiché verrà reinserito dopo aver fatto clic sull'immagine di anteprima.

Abbiamo eseguito alcuni test e convalidato il presupposto che l'hosting autonomo dell'immagine di anteprima di YouTube non sempre dia risultati migliori. I dati sulle prestazioni migliori si applicano solo ai segmenti di pubblico locali o se viene utilizzato un CDN.

I nostri test mostrano che il CDN di YouTube offre ancora prestazioni migliori e ha il TTFB più basso, influenzando la velocità di recupero dell'immagine.

Considerare questo risultato è essenziale perché tali dati sulle prestazioni influenzano l'elemento LCP se l'immagine di anteprima ne fa parte.

10. Utilizzo di un CDN

L'ultimo malinteso che vogliamo trattare è l'utilizzo costante di un CDN per migliorare le prestazioni. Sebbene sia vero che un CDN renderà il tuo sito web più veloce se il tuo pubblico è mondiale, non è corretto affermare che aiuterà sempre le prestazioni del tuo sito web.

Dipende dalla posizione del visitatore e dalla distanza tra l'utente e le risorse richieste.

Facciamo un paio di esempi per renderlo più chiaro.

• Pubblico locale : gestisci un'attività locale in Francia e il tuo sito web è già ospitato su un server locale. L'utilizzo di un CDN che non ha un PoP (Points of Presence) in Francia o vicino ad esso peggiorerà l'esperienza dell'utente, poiché la pagina e le sue risorse verranno spedite da un data center lontano, diciamo, New York. D'altra parte, la distanza sarà più breve se utilizzi solo il server di origine.

• Pubblico regionale o mondiale : gestisci un'attività regionale in tutta Europa. Scegliere un CDN con una forte presenza in Europa darà risultati migliori rispetto a scegliere un CDN che ha solo uno o due PoP in Europa.

In breve, quando scegli un CDN, devi assicurarti che la copertura dei loro PoP corrisponda alle posizioni del pubblico.

Avvolgendo

L'ottimizzazione delle prestazioni Web non è affatto facile e questo articolo lo dimostra ancora una volta. Si spera che abbia fatto luce su alcune idee sbagliate su argomenti chiave come l'ottimizzazione di JavaScript e CSS e il caricamento lento.

In WP Rocket, ci sforziamo di rendere il nostro plug-in per le prestazioni il più semplice offrendo al contempo le funzionalità più avanzate per migliorare le prestazioni del tuo sito web. Sappiamo di cosa stiamo parlando e cercheremo sempre di spiegarlo nel modo più semplice possibile. Nel frattempo, prova WP Rocket e scopri quanto è facile e potente!