Analisi di pagine per dispositivi mobili in PageSpeed Insights

PageSpeed Insights analizza le pagine per controllare se rispettano i nostri consigli per la visualizzazione delle pagine in meno di un secondo sulle reti mobili. Da una ricerca è emerso che i ritardi superiori a un secondo causano l'interruzione del flusso di pensiero degli utenti, che comporta un'esperienza negativa. Il nostro obiettivo è mantenere alto l'interesse dell'utente per la pagina e offrire un'esperienza ottimale, a prescindere dal dispositivo o dal tipo di rete utilizzati.

Non è facile rispettare il budget di tempo di un secondo. Fortunatamente per noi, non è necessario mostrare l'intera pagina entro questo budget, ma dobbiamo pubblicare e mostrare i contenuti above the fold (ATF) in meno di un secondo per consentire all'utente di iniziare a interagire con la pagina nel più breve tempo possibile. Dopodiché, mentre l'utente interpreta la prima pagina di contenuti, è possibile pubblicare progressivamente il resto della pagina in background.

Adattamento alle reti mobili ad alta latenza

Il rispetto dei criteri di visualizzazione dei contenuti ATF in un secondo sui dispositivi mobili mette di fronte a difficoltà che non si riscontrano su altre reti. Gli utenti potrebbero accedere al sito tramite una serie di reti 2G, 3G e 4G diverse. Le latenze di queste reti sono molto più elevate rispetto a quelle delle connessioni cablate e consumano una parte notevole del nostro budget di 1000 ms a disposizione per la visualizzazione dei contenuti ATF:

  • Tempi di roundtrip di 200-300 ms per le reti 3G
  • Tempi di roundtrip di 50-100 ms per le reti 4G

Il 3G è il tipo di rete più diffuso in assoluto e, anche se le implementazioni delle reti 4G si stanno diffondendo in tutto il mondo, gran parte degli utenti dovrebbe ancora accedere alla tua pagina tramite una rete 3G. Per questo motivo, dobbiamo presupporre che ogni richiesta di rete richieda, in media, 200 millisecondi.

Tenendo conto di questo, procediamo a ritroso. Se prendiamo in considerazione una tipica sequenza di comunicazioni tra un browser e un server, 600 ms del tempo a disposizione vengono già consumati dall'overhead di rete: una ricerca DNS per convertire il nome host (ad esempio google.com) in un indirizzo IP, un roundtrip di rete per eseguire l'handshake TCP e infine un roundtrip di rete completo per inviare la richiesta HTTP. Ci rimangono soltanto 400 ms.

Ottenimento della visualizzazione in meno di un secondo

Dopo avere sottratto la latenza della rete, ci rimangono soltanto 400 millisecondi del nostro budget e c'è ancora tanto lavoro da fare: il server deve eseguire il rendering della risposta, deve essere eseguito il codice dell'applicazione lato client e il browser deve strutturare e mostrare i contenuti. Tenendo conto di questo, i seguenti criteri dovrebbero consentirci di rientrare nel budget:

(1) Il server deve eseguire il rendering della risposta (< 200 ms)
Il tempo di risposta del server è il tempo necessario al server per restituire il codice HTML iniziale, escluso il tempo di trasporto della rete. Abbiamo pochissimo tempo, pertanto questa operazione dovrebbe richiedere un tempo minimo, idealmente massimo 200 millisecondi e preferibilmente ancora meno.
(2) Il numero di reindirizzamenti deve essere ridotto al minimo
Ulteriori reindirizzamenti HTTP possono aggiungere uno o due roundtrip di rete extra (due se è necessaria un'ulteriore ricerca DNS), causando centinaia di millisecondi di latenza extra sulle reti 3G. Per questo motivo, consigliamo vivamente ai webmaster di ridurre al minimo il numero di reindirizzamenti e, idealmente, di eliminarli del tutto. È particolarmente importante per i documenti HTML (evita di utilizzare i reindirizzamenti a pagine specifiche per dispositivi mobili, se possibile).
(3) Il numero di roundtrip per la prima visualizzazione dovrebbe essere ridotto al minimo

A causa della modalità con cui TCP stima la capacità di una connessione (vale a dire la Slow-start TCP, anche chiamata Partenza lenta), una nuova connessione TCP non può utilizzare subito la larghezza di banda totale disponibile tra il client e il server. Per questo motivo, il server può inviare massimo dieci pacchetti TCP su una nuova connessione (~14 kB) nel primo roundtrip, dopodiché deve aspettare che il client riconosca questi dati prima di poter ampliare la sua finestra di congestione e procedere con la pubblicazione di altri dati.

A causa di questo comportamento di TCP, è importante ottimizzare i contenuti per ridurre al minimo il numero di roundtrip necessari per pubblicare i dati per la prima visualizzazione della pagina. I contenuti ATF dovrebbero rientrare in 14 kB per consentire al browser di rappresentare la pagina dopo un solo roundtrip. È importante anche tenere presente che il limite di dieci pacchetti (IW10) è un aggiornamento recente dello standard TCP: dovresti assicurarti che il tuo server sia aggiornato all'ultima versione per poter sfruttare questo cambiamento. In caso contrario, è probabile che il limite sia di tre o quattro pacchetti.

(4) Evita codice JavaScript e CSS di blocco esterno nei contenuti above-the-fold

Prima che un browser possa mostrare una pagina all'utente, deve analizzarla. Se durante l'analisi il browser rileva uno script esterno non asincrono o di blocco, deve interrompersi e scaricare la risorsa. Tale operazione comporta ogni volta un ulteriore roundtrip di rete, che genera un ritardo nella prima visualizzazione della pagina.

Di conseguenza, il codice JavaScript e CSS necessario per la visualizzazione dell'area above the fold deve essere integrato e il codice JavaScript o CSS necessario per aggiungere funzionalità alla pagina deve essere caricato dopo la pubblicazione dei contenuti ATF.

(5) Lascia tempo per la strutturazione e visualizzazione da parte del browser (200 ms)
La procedura di analisi del codice HTML, CSS e l'esecuzione di JavaScript richiedono tempo e risorse del client. A seconda della velocità del dispositivo mobile e della complessità della pagina, questa procedura può richiedere centinaia di millisecondi. Il nostro consiglio è di destinare 200 millisecondi all'overhead del browser.
(6) Ottimizza l'esecuzione di JavaScript e il tempo di visualizzazione
Per l'esecuzione di script complessi e di codice inefficiente potrebbero occorrere decine o centinaia di millisecondi. Utilizza strumenti per sviluppatori incorporati nel browser per delineare e ottimizzare il codice. Per avere una presentazione straordinaria, dai un'occhiata al nostro corso interattivo sugli strumenti per sviluppatori di Chrome.

Domande frequenti (FAQ)

In che modo le reti 4G incidono sui criteri per dispositivi mobili sopra citati?
Le minori latenze dei roundtrip rappresentano uno dei miglioramenti principali delle reti 4G. Tali miglioramenti sono molto utili perché riducono il tempo di overhead totale della rete, che al momento è superiore al 50% del nostro budget di un secondo sulle reti 3G. Tuttavia, le reti 3G sono le più utilizzate e lo saranno per gli anni futuri, pertanto devi ottimizzare le pagine per le reti 3G.
Utilizzo una libreria JavaScript, ad esempio JQuery. Qualche consiglio da darmi?
Molte librerie JavaScript, come JQuery, vengono utilizzate per ottimizzare la pagina con l'aggiunta di ulteriori elementi interattivi, animazioni e altri effetti. Tuttavia, molti di questi comportamenti possono essere aggiunti in modo sicuro dopo la visualizzazione dei contenuti ATF. Valuta la possibilità di posticipare l'esecuzione e il caricamento di questo file JavaScript rispetto al caricamento della pagina.
Utilizzo un framework JavaScript per sviluppare la pagina. Qualche consiglio da darmi?
Se i contenuti della pagina vengono sviluppati mediante una struttura JavaScript lato client, devi valutare la possibilità di incorporare i moduli JavaScript pertinenti evitando così ulteriori roundtrip di rete. Allo stesso modo, se sfrutti il rendering lato server puoi migliorare sensibilmente il rendimento del primo caricamento della pagina: visualizza i modelli JS sul server, incorpora i risultati nel documento HTML, quindi utilizza i modelli lato client una volta che l'applicazione è stata caricata.
Qual è l'utilità di SPDY e HTTP 2.0?
SPDY e HTTP 2.0 servono entrambi a ridurre la latenza del caricamento delle pagine utilizzando in modo più efficiente la connessione TCP (multiplexing, compressione delle intestazioni, definizione di priorità). Inoltre, il push del server può contribuire a migliorare ulteriormente il rendimento eliminando la latenza extra della rete. Ti invitiamo a prendere in considerazione l'aggiunta del supporto di SPDY sui tuoi server e di passare a HTTP 2.0 quando è pronto lo standard.
Come faccio a identificare il CSS fondamentale nella mia pagina?
In Strumenti per sviluppatori di Chrome, apri il riquadro Audits (Controlli) ed esegui un rapporto Web Page Performance (Rendimento delle pagine web). Nel rapporto generato, cerca Remove unused CSS rules (Rimuovi regole CSS inutilizzate). In alternativa, utilizza un altro strumento di terze parti, o script, per identificare i selettori CSS applicati in ogni pagina.
È possibile automatizzare queste best practice?
Certamente. Esistono tanti prodotti di WPO (Web Performance Optimization) commerciali e open source che possono esserti utili per soddisfare alcuni o tutti i criteri spiegati in precedenza. Per le soluzioni open source, dai un'occhiata agli strumenti di ottimizzazione PageSpeed.
Come faccio a regolare il mio server per soddisfare questi criteri?
Innanzitutto, assicurati che sul tuo server sia in esecuzione una versione aggiornata del sistema operativo. Per poter usufruire delle maggiori dimensioni della finestra di congestione TCP iniziale (IW10), devi avere il kernel Linux 2.6.39 o versioni successive. Per altri sistemi operativi, consulta la documentazione.
Per ottimizzare i tempi di risposta del server, instrumenta il codice o utilizza una soluzione di monitoraggio delle applicazioni per identificare i colli di bottiglia, ad esempio runtime di scripting, chiamate al database, richieste RPC, rendering ecc. L'obiettivo è eseguire il rendering della risposta HTML entro 200 millisecondi.
Per quanto riguarda le norme sulla sicurezza dei contenuti?
Se utilizzi CSP, potresti dover aggiornare le tue norme predefinite.
Innanzitutto, gli attributi CSS integrati negli elementi HTML (ad esempio, &lt p style=...&gt) dovrebbero essere evitati, se possibile, perché spesso causano la duplicazione superflua di codice e vengono bloccati per impostazione predefinita con il CSP (disattivati tramite "unsafe inline" in "style-src"). Se CSP viene attivato, blocca per impostazione predefinita tutti i tag di script integrati. Se hai JavaScript integrato, devi aggiornare le norme CSP in modo da utilizzare nonce o hash di script oppure utilizzare "unsafe-inline" per attivare tutti gli script integrati da eseguire. Se hai stili integrati, devi aggiornare le norme CSP in modo da utilizzare nonce o hash di stile o utilizzare "unsafe-inline" per attivare tutti i blocchi di stile integrati da elaborare.

Hai altre domande? Non esitare a porre domande e fornire feedback nel nostro gruppo di discussione all'indirizzo pagespeed-insights-discuss.