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 che l'intera pagina venga visualizzata nei limiti di questo budget; dobbiamo pubblicare e visualizzare i contenuti above the fold (ATF) in meno di un secondo, per consentire all'utente di iniziare a interagire con la pagina il prima 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 rete sono molto più elevate di una connessione cablata e consumano una parte significativa del nostro budget di 1000 ms per visualizzare i contenuti ATF.

La rete 4G è il tipo di rete dominante in tutto il mondo, pertanto la maggior parte degli utenti accede alla tua pagina tramite una rete 4G. Per questo motivo, dobbiamo presumere che ogni richiesta di rete richieda, in media, 100 millisecondi.

Tenendo conto di questo, procediamo a ritroso. Se consideriamo una tipica sequenza di comunicazione tra un browser e un server, 300 ms di quel tempo sono già stati utilizzati dall'overhead della rete: una ricerca DNS per risolvere il nome host (ad es. google.com) in un indirizzo IP, un roundtrip di rete per eseguire l'handshake TCP e una connessione TLS facoltativa. Questo lascia 700 ms.

Ottenimento della visualizzazione in meno di un secondo

Dopo aver sottratto la latenza di rete, rimangono solo 700 millisecondi del nostro budget e c'è ancora molto lavoro da fare: il server deve eseguire il rendering della risposta, deve essere eseguito il codice dell'applicazione lato client e il browser deve impostare il layout e visualizzare 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 impiegato da un 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 4G. 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.

Inoltre, è importante notare che il limite di 10 pacchetti (IW10) è un recente aggiornamento dello standard TCP: devi assicurarti che il tuo server sia aggiornato all'ultima versione per sfruttare questa modifica. In caso contrario, è probabile che il limite sia di tre o quattro pacchetti.

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. Idealmente, i contenuti ATF dovrebbero rientrare nei 98 kB per consentire al browser di colorare la pagina dopo soli tre round trip per avere un budget sufficiente per la latenza di risposta del server e il rendering del client.

(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 e CSS e di esecuzione di JavaScript richiede 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
L'esecuzione di script complicati e codice inefficiente può richiedere decine e centinaia di millisecondi. Utilizza gli strumenti per sviluppatori integrati nel browser per profilare e ottimizzare il tuo codice. Per un'introduzione straordinaria, dai un'occhiata al nostro corso interattivo sugli Strumenti per sviluppatori di Chrome.

Domande frequenti

Utilizzo una libreria JavaScript, ad esempio JQuery. Qualche consiglio da darmi?
Molte librerie JavaScript, come JQuery, vengono utilizzate per migliorare la pagina al fine di aggiungere ulteriori interattività, 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 creati mediante codice JavaScript lato client, devi valutare la possibilità di incorporare i moduli JavaScript pertinenti per evitare ulteriori round trip 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.
Come faccio a identificare il CSS fondamentale nella mia pagina?
Negli Strumenti per sviluppatori di Chrome, apri il riquadro Controlli ed esegui un report Rendimento delle pagine web. Nel report generato, cerca 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 server sia in esecuzione una versione aggiornata del sistema operativo. Per trarre vantaggio dall'aumento delle dimensioni iniziali della finestra di congestione TCP (IW10), è necessario un kernel Linux 2.6.39 o versioni successive. Per altri sistemi operativi, consultare la documentazione.
Per ottimizzare i tempi di risposta del server, instrumenta il tuo codice o utilizza una soluzione di monitoraggio delle applicazioni per identificare il collo di bottiglia, ad esempio runtime di scripting, chiamate al database, richieste RPC, rendering e così via. L'obiettivo è eseguire il rendering della risposta HTML entro 200 millisecondi.
Per quanto riguarda le norme sulla sicurezza dei contenuti?
Se usi CSP, potresti dover aggiornare il tuo criterio predefinito.
Innanzitutto, attributi CSS incorporati negli elementi HTML(ad es. < p style=...>) devono essere evitati, ove possibile, poiché spesso comportano una duplicazione non necessaria di codice e sono bloccati per impostazione predefinita con CSP (disattivati tramite "unsafe inline" su "style-src"). Se CSP è attivato, bloccherà tutti i tag di script incorporati per impostazione predefinita. Se hai JavaScript incorporato, dovrai aggiornare le norme CSP in modo da utilizzare nonce o hash di script oppure utilizzare "unsafe-inline" per attivare l'esecuzione di tutti gli script incorporati. Se disponi di stili incorporati, devi aggiornare le norme CSP in modo da utilizzare nonce o hash di stile oppure utilizzare "unsafe-inline" per attivare l'elaborazione di tutti i blocchi di stile incorporati.

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

Feedback

Hai trovato utile questa pagina?