Manuale: Suggerimenti Prestazioni

La funzione "Suggerimenti Prestazioni" di Visual SEO Studio, documentata in dettaglio.

Suggerimenti Prestazioni

Suggerimenti Prestazioni è un insieme di report basato sulle ricerche di Steve Souders sulle web performance e successivi lavori derivati.
Ogni report misura per tutte le pagine della sessione di esplorazione una dimensione specifica e la compara con limiti basati su medie misurate sull'intero Web.

Puoi saperne di più su Suggerimenti Prestazioni in questa pagina: FAQ: Suggerimenti Prestazioni.
Nota: anche lo strumento Ispezione Immagini fornisce informazioni preziose sulla dimensione delle immagini.

Sommario

La scheda Sommario ti fornisce una prospettiva d'insieme dei report disponibili in Suggerimenti Prestazioni.
Puoi selezionarla velocemente quando vuoi, anche se non è visibile, cliccando sul link Mostra Sommario.

Colonne della tabella Report

Descrizione

Il nome descrittivo del report. Il testo è un link attivo, una volta cliccato selezionerà la scheda contenente il report relativo.

Pagine

Il numero di pagine affetta dalla criticità rilevata dal report, ossia il numero di pagine elencate nel report.

Tot Pagine

Il numero totale di pagine prese in considerazione nell'elaborazione del report. Questo numero è lo stesso per tutti i report elencati.

Percentuale

La percentuale di pagine rilevate da report specifico, calcolata come il rapporto tra i due valori precedenti.

Tieni a mente che alcuni dei report operano una decisione binaria nel decidere se catalogare una pagina come affetta o no da una criticità: usano una soglia fissa (configurabile) e vedono se la dimensione misurata eccede o no la soglia.
In tali casi la percentuale non dice come la dimensione è distribuita. Prendi per esempio il report "Dimensione pagina (KB)": ti elencherà - diciamo - tutte le pagine la cui dimensione del file HTML è superiore a 50 KB, e dal loro numero avrai una percentuale. Ma quante di esse sono 500 KB? E quante sono davvero troppo pesanti?
Per fornirti un'idea molto migliore della distribuzione, ogni report che usa una soglia per essere computato è fornito di una vista a Istogramma dedicata. La puoi trovare nel pannello in basso.

Icona grafico a torta

Un mini grafico a torta che riporta visivamente due importanti informazioni:

La percentuale mostrata nella colonna precedente, relativa alla fetta colorata della torta.
Il livello della criticità investigata dal report. È riportata dal colore della fetta:
- Rosso: la criticità investigata deve essere considerata un Errore.
- Giallo: la criticità investigata deve essere considerata un Avvertimento.
  Nota che un avvertimento non è un "errore lieve", ma qualcosa che in questo stadio il programma non può determinare se sia un errore potenziale o qualcosa di voluto.
- Azzurro: il report è puramente Informazionale.

Come detto in precedenza per la colonna Percentuale, report che usano una soglia per essere computati sono meglio valutati guardando anche il pannello Istogramma in basso per comprendere come la dimensione misurata sia distribuita.

Dimensione pagina (KB)

Tipo di criticità: Avvertimento

Con dimensione pagina qui intendiamo il peso in KB del solo file HTML.
La dimensione della pagina non è normalmente un gran problema in termini di prestazioni dato che la parte HTML è di solito solo una frazione del peso totale della pagina (pensa al peso aggiunto dai file immagine, per esempio). Ciononostante, tutto fa, e in grossi siti web con alti volumi di traffico ridurre il peso della pagina può portare a importanti risparmi in banda passante e miglioramenti nella responsività del server.
Non solo: più spesso che no grosse dimensioni di pagina indicano errori nelle impostazioni del server dove tonnellate di codice CSS e javascript sono aggiunte alla sezione head dell'HTML; in tali casi davvero danneggiando le prestazioni delle pagine web.

Questo report elenca tutte le pagine che eccedono una data soglia di dimensione pagina, ordinate in ordine decrescente. La colonna "KB" mostra per ogni pagina l'effettivo valore di dimensione pagina.

La soglia utilizzata, al momento in cui questa guida è stata scritta, è "Maggiore di 50 KB". Come molte altre, può essere personalizzata nelle Opzioni del programma, raggiungibile tramite la voce Strumenti -> Preferenze... nel menu principale del programma.
Nel tempo, con i cambiamenti nel mondo SEO, aggiorniamo le soglie predefinite per tenerti aggiornato con il mercato in continua evoluzione.

Prima di gettarci a rendere la pagine HTML il più leggere possibile, ricordiamo un concetto base: l'ottimizzazione delle prestazioni web è un mondo fatto di compromessi, e il peso dell'HTML della pagina è spesso la terra di mezzo.

Vuoi ottimizzare per la prima visualizzazione?
La prima visualizzazione è la prima volta che un browser visita il tuo sito. Non c'è nulla nella cache del browser per cui dovrà scaricare tutte le risorse.
Come nella vita, "la prima impressione conta", e vuoi che i nuovi visitatori visualizzino la tua pagina il più velocemente possibile.
Eviti di usare file CSS e javascript condivisi e metti tutto quel carico dentro la pagina, poi usi immagini "embedded" e alla fine hai ridotto notevolmente il numero di chiamate HTTP (che sono costose).
Ora hai una pagina HTML corposa, ma una volta scaricata il browser sa tutto quel che deve sapere per mostrarla.
Vuoi ottimizzare per visualizzazioni ripetute?
Se i visitatori del tuo sito in media visitano più pagine, potresti desiderare abbiamo un'esperienza di navigazione più veloce sfruttando la cache del browser.
Usi il più possibile file CSS e javascript condivisi ed eviti immagini "embedded". Adesso hai una pagina HTML leggera che necessita di risorse condivise separate da scaricare perché il browser sappia come mostrarla. La prima volta scaricherà tutte le risorse condivise con costose chiamate HTTP separate, ma dopo la prima volta le troverà tutte nella cache del browser e per le pagine successive dovrà solo scaricare la leggera parte HTML.
Vuoi ottimizzare sia per la prima visualizzazione che per visualizzazioni ripetute?
Allora usi dei compromessi. Usi script e CSS condivisi, ma aggiungi anche alla pagine le regole CSS che permettono al browser di mostrare il prima possibile il contenuto "al di sopra della piega" (ossia nella parte visibile della finestra del browser) e quanto altro serve per permettere all'utente di interagire prima con la pagina. Il trucco qui è aumentare la "velocità percepita".

Come correggere il problema nelle pagine elencate:

La prima cosa da fare è stabilire quanto grave è il problema, e se ci puoi convivere se le pagine non sono poi così pesanti.
Come regola generale: una dimensione dell'HTML di 25 KB o meno è buona, 50 KB è altamente accettabile, e fino a 80-100 KB è ancora nella varianza delle statistiche globali.
Senza dimenticare che alcune tecniche di ottimizzazione della prima visualizzazione possono rendere l'HTML della pagina leggermente più pesante, prova a capire cosa le rende pesanti:

In siti WP una causa comune è un eccesso di blocchi CSS e script on-page. Controlla il sorgente della pagina per capire se sia questo il caso. Se sì, il colpevole più probabile è un plugin. Assicurati che il/i plugin sia/siano effettivamente usati e utili, e ben configurati.
Altre volte le pagine non sono poi così pesanti, e il problema è solo causato del tema (il modello/template della pagina). Se questo è il caso, la vista Istogramma nel pannello in basso dovrebbe mostrare la maggiore dimensione di pagina distribuita su tutte le pagine. Naturalmente potresti volere ottimizzare anche quello, ma tieni a mente le priorità per prima cosa non ha senso spremere pochi byte nell'HTML, e poi avere grossi carichi - per esempio - nelle immagini.
Un altro problema comune che osserviamo in siti WP: il proprietario ha installato un plugin di "ottimizzazione performance" che nel tentativo di ridurre le chiamate HTTP mette tutto dentro il sorgente della pagina, ma va davvero troppo oltre il limite.
Questi strumenti devono essere tarati con attenzione, misurando sempre il risultato prima di metterlo in produzione! (altre volte li abbiamo osservati cercare di ridurre le chiamate HTTP unendo tutti i CSS e script condivisi, ma stupidamente invocandoli con un nuovo parametro query ogni volta così che la cache del browser non potrà mai aiutare).
Per vecchi siti in ASP.NET WebForms, un colpevole comune è un inutile ViewState. Fai riferimento al report dedicato per maggiori approfondimenti su di esso.

In tutti i casi, controlla il codice sorgente HTML!
Si suppone tu sia in grado di leggerlo, conoscendo almeno le basi di HTML CSS e Javascript.

Tempo download (ms)

Tipo di criticità: Avvertimento

Valori troppo alti per tutte le pagine potrebbero indicare problemi di prestazioni del server che ospita il sito. Valori alti per le singole pagine indicano verosimilmente un contenuto troppo pesante.

Considera il tempo di download di una pagina assieme al valore della dimensione della pagina: un tempo di download alto unitamente a una dimensione di pagina alta indica una pagina troppo pesante, un tempo di download alto unitamente a una dimensione di pagina bassa indica invece un problema di prestazioni lato server.

Questo report elenca tutte le pagine che eccedono una data soglia di tempo di download, ordinate in ordine decrescente. La colonna "Millisecondi" mostra per ogni pagina l'effettivo valore di tempo di download.

La soglia utilizzata, al momento in cui questa guida è stata scritta, è "Maggiore di 1000 ms". Come molte altre, può essere personalizzata nelle Opzioni del programma, raggiungibile tramite la voce Strumenti -> Preferenze... nel menu principale del programma.
Nel tempo, con i cambiamenti nel mondo SEO, aggiorniamo le soglie predefinite per tenerti aggiornato con il mercato in continua evoluzione.

Come correggere il problema nelle pagine elencate:

Prima di tutto, assicurati che l'alto tempo di download non sia causato da una connessione a Internet usata mentre esploravi il sito web con Visual SEO Studio.
Controlla la vista Istogramma nel pannello in basso per vedere come questo è distribuito. Se è distribuito tra tutte le pagine o se vi sono singole anomalie.

Se il problema è nel server web che ospita il sito, considera la possibilità di passare a un piano superiore, o cambiare del tutto il servizio di hosting.
Dovresti anche avere il server web vicino ai tuoi utenti. Per esempio, se la maggioranza dei tuoi visitatori fosse in Europa, avrebbe poco senso tenere il server web negli Stati Uniti.

Se il problema risiede nella dimensione delle pagine, fai riferimento alle soluzioni offerte per il report Dimensione pagina.

TTFB (ms)

Tipo di criticità: Avvertimento

"Time To First Byte" è il tempo che intercorre tra la chiamata HTTP al server web e il primo byte ricevuto dallo spider.
Valori troppo alti per tutte le pagine potrebbero indicare problemi di prestazioni del server che ospita il sito.

Questo report elenca tutte le pagine che eccedono una data soglia di TTFB, ordinate in ordine decrescente. La colonna "Millisecondi" mostra per ogni pagina l'effettivo valore di TTFB.

La soglia utilizzata, al momento in cui questa guida è stata scritta, è "Maggiore di 200 ms". Come molte altre, può essere personalizzata nelle Opzioni del programma, raggiungibile tramite la voce Strumenti -> Preferenze... nel menu principale del programma.
Nel tempo, con i cambiamenti nel mondo SEO, aggiorniamo le soglie predefinite per tenerti aggiornato con il mercato in continua evoluzione.

Come correggere il problema nelle pagine elencate:

Prima di tutto, assicurati che l'alto tempo di download non sia causato da una connessione a Internet usata mentre esploravi il sito web con Visual SEO Studio.

Valori alti di TTFB distribuiti su tutte le pagine (controlla la vista Istogramma nel pannello in basso per vedere come questo è distribuito) potrebbero indicare problemi di prestazioni del server che ospita il sito.

Se hai pieno controllo sul backend del tuo server web a un team di sviluppo interno, consultati con il tuo team per analizzare e risolvere quanto ritarda la costruzione delle pagine web. Nella nostra esperienza con team di sviluppo interno e CMS proprietari questi problemi erano spesso causati da un'eccessiva pressione sul server del database, senza l'impiego di alcun sistema di caching applicativo.

Altre volte alti TTFB in server di produzione sono semplicemente causati da forte traffico sul sito web a consumare troppe risorse, così che le nuove chiamate HTTP sono tenute "in attesa". Ancora, considera di potenziare il tuo server di backend.

Meta charset (non UTF-8)

Tipo di criticità: Avvertimento

Per poter leggere un test, come il codice sorgente HTML di una pagina web, un computer necessita di sapere la codifica usata per scriverlo.
Usare la codifica sbagliata porterebbe a non essere in grado di leggere correttamente caratteri non basati sull'alfabeto Occidentale (caratteri ASCII); puoi notarlo quando vedi pagine web con testi che appaiono nel browser con caratteri strani, o caratteri a quadratini.
Per sapere che codifica di testo utilizzare, browser e spider possono usare tre possibili informazioni:

Leggere dallo header HTTP Content-Type la parte opzionale charset, es:
Content-Type: text/html; charset=utf-8
Leggere il BOM (Byte Order Mark)
Il BOM è una sequenza opzionale di caratteri all'inizio di un flusso di testo Unicode; segnala che tipo di codifica di carattere Unicode è utilizzata. Naturalmente, funziona solo per testi Unicode, quando specificata.
Nota che non tutti i client web sanno leggere correttamente i valori del BOM (anche se questo non viola alcuna specifica di Unicode). Visual SEO Studio può leggerlo correttamente.
Leggere il charset dai meta tag nell'HTML, se specificato.
Storicamente HTML usava il meta tag http-equiv per specificare l'equivalente dello header HTTP Content-Type, es.:
<META http-equiv="Content-Type" content="text/html; charset=EUC-JP">
HTML5 ha introdotto un nuovo attributo charset:
<meta charset="utf-8" />
Tirare a indovinare usando una scelta probabile quando l'informazione non è disponibile, e sperare per il meglio.
Vuole dire usare la codifica più usata, UTF-8.

Fra tutte le possibili vie, la terza, leggere il charset dai meta tag nell'HTML è un po' come avere un "problema del serpente che si mangia la coda":
Per poter leggere la codifica dal meta tag devi leggere il testo, e per poter leggere il testo devi sapere la codifica!
Per fortuna, i meta tag HTML usano solo caratteri ASCII, per cui il problema è risolto così:

Si assume che la codifica sia UTF-8 (ossia si usa l'opzione di tirare a indovinare usando la scelta più probabile);
Si legge il charset dai meta tag, se specificato;
Se il charset letto dai meta tag è UTF-8 (o se non è specificato), si tiene il testo decodificato;
Se il charset letto dai meta tag non è UTF-8, si butta via il testo decodificato e lo si legge di nuovo usando il charset corretto.

Puoi ora capire che quando il charset usato è specificato usando un meta tag e non è UTF-8, il browser paga uno scotto in prestazioni perché dovrà buttare via il testo decodificato finora e ricominciare a leggere il codice sorgente HTML.

La nostra raccomandazione è usare sempre UTF-8, e specificarlo nello header HTTP Content-Type.

Questo report elenca tutte le pagine con un meta charset non UTF-8 (quando il charset non è specificato né nello header HTTP né nel BOM).

Come correggere il problema nelle pagine elencate:

Usa l'HTTP header Content-Type per specificare un charset (fai riferimento alla documentazione del tuo CMS / server web per sapere come farlo) e poi rimuovi il meta tag.
Se puoi, imposta il tuo sistema di backend perché usi la codifica UTF-8.

Dimensione ViewState (byte)

Tipo di criticità: Avvertimento

Dovrai usare questo report solo quando avrai a che fare con pagine web costruite con la vecchia tecnologia "ASP.NET WebForms".
All'epoca gli ingegneri di MS ebbero la terribile idea di mascherare la natura "stateless" del Web a un esercito di programmatori VB che non avevano idea di come funzionasse il Web, per permettere loro di creare applicazioni web in modo simile a quanto erano abituati.
Per ottenere il risultato piazzarono nelle pagine generate dal loro IDE un campo nascosto fatto più o meno così:

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULL ...un valore testuale potenzialmente gigantesco... dtBPL7w=" />

Uno dei tanti problemi era che questo campo nascosto era il più popolato con un enorme testo codificato anche per pagine che non lo necessitavano, come la maggior parte delle pagine pubbliche di un sito web.
Il risultato fu in molti casi pagine pesanti molti MB di dati inutili.

Per quanto presto apparirono in Internet diversi visualizzatori di ViewState per pagine singole, quel che veramente mancava prima che Visual SEO Studio lo realizzasse era uno strumento capace di analizzare il ViewState di tutte le pagine pubbliche di un sito web.
Finora ci risulta essere sempre l'unico strumento in grado di analizzare l'uso del ViewState nell'intero sito.

Puoi utilizzare il Visualizzatore di ViewState nel pannello in basso per avere maggiori dettagli sul ViewState della pagina selezionata.

Questo report elenca tutte le pagine che eccedono una data soglia di dimensione ViewState, ordinate in ordine decrescente. La colonna "Byte" mostra per ogni pagina l'effettivo valore di dimensione ViewState.

La soglia utilizzata, al momento in cui questa guida è stata scritta, è "Maggiore di 1 KB". Come molte altre, può essere personalizzata nelle Opzioni del programma, raggiungibile tramite la voce Strumenti -> Preferenze... nel menu principale del programma.
Nel tempo, con i cambiamenti nel mondo SEO, aggiorniamo le soglie predefinite per tenerti aggiornato con il mercato in continua evoluzione.

Come correggere il problema nelle pagine elencate:

Che fare quando il programma ti ha aiutato a individuare parti della pagina web che usano inutilmente il ViewState?
In ASP.NET WebForm ogni singolo controllo lato server supporta l'attributo booleano EnableViewState, che sfortunatamente ha come volare predefinito true.
Nella nostra esperienza nelle pagine pubbliche il più comune colpevole di intasare il ViewState sono le tabelle generate lato server.
Quando capisci che un singolo controllo non necessita veramente del ViewState perché la pagina web funzioni, imposta l'attributo - o chiedi al tuo sviluppatore di farlo - a false:

<asp:Table runat="server" EnableViewState="false" ...

Nel più dei casi sarai in gradi di impostare EnableViewState="false" a livello di pagina:

<%@ Page EnableViewState = "false" ...

Assicurati però con il tuo sviluppatore di non impattare sul corretto funzionamento del sito quando disabiliti il ViewState a livello di pagina.
Fai riferimento alla documentazione di MS per tutto quanto riguarda il ViewState e l'attributo EnableViewState.

Puoi apprendere di più sul Visualizzatore di ViewState leggendo il blog post che scrivemmo quando pubblicammo la funzione.

Immagini di pagina

Tipo di criticità: Avvertimento

Le immagini sono di solito il "bagaglio pesante" nel peso totale di una pagina web. Lo strumento Ispezione Immagini fornisce informazioni preziose sulla dimensione delle immagini; qui ci focalizzeremo sul loro numero.

Ogni immagine - aggiunta alla pagina web con del codice tipo <img src="...l'URL del file immagine..." /> - rappresenta una chiamata HTTP in più (oltre ai byte da scaricare), e meno chiamate HTTP la pagina richiede per mostrarsi, più veloce si caricherà.

Non c'è una regola fissa su quante immagini una pagina web possa avere al massimo. Dipende dal tipo di sito web: il sito di un fotografo è verosimile abbia più immagini rispetto a quello - ipotizziamo - di un copywriter. Data la regola generale, dovresti personalizzare la soglia usata tarandola per la nicchia del tuo sito web.

Questo report elenca tutte le pagine che eccedono una data soglia di numero di immagini per pagina, ordinate in ordine decrescente. La colonna "Numero" mostra per ogni pagina l'effettivo numero di immagini per pagina.

La soglia utilizzata, al momento in cui questa guida è stata scritta, è "Maggiore di 5". Come molte altre, può essere personalizzata nelle Opzioni del programma, raggiungibile tramite la voce Strumenti -> Preferenze... nel menu principale del programma.
Nel tempo, con i cambiamenti nel mondo SEO, aggiorniamo le soglie predefinite per tenerti aggiornato con il mercato in continua evoluzione.

Come correggere il problema nelle pagine elencate:

Assicurati che le immagini abbiano senso come parte dell'effettivo contenuto. Se hai usato l'opzione di esplorazione "Salva immagini", dovresti essere in grado di vedere le anteprime delle immagini per controllare cosa sono.

Se vedi stai usando immagini decorative come punti, frecce, e così via, sostituiscile con caratteri Unicode decorati con stili CSS. Oltre immagini decorative possono essere raggruppate con la tecnica degli "sprite" per ridurre il numero di file da scaricare.

Se necessiti di tutte quelle immagini, ottimizzane dimensioni e peso (usa Ispezione Immagini per analizzarne peso e dimensione in pixel), e quando non sono "sopra la piega" (ossia nella parte visibile della finestra del browser) usa il lazy loading:

<img src="image.png" loading="lazy" alt="…" width="200" height="200" />

Suggeriamo anche di adottare una politica sul numero massimo di immagini di contenuto per pagina, tagliata su misura per la nicchia e lo stile del tuo sito, e rispettarla.

Tabelle annidate

Tipo di criticità: Errore Errore

In un passato non così distante, quando non c'erano valide alternative a causa dell'infanzia dei CSS, tabelle HTML annidate erano spesso usate per realizzare layout di pagina.
Oltre a non essere usate per il loro scopo semantico (le tabelle HTML dovrebbero essere usate per rappresentare tabelle di dati), le tabelle annidate rendono la presentazione delle pagina web più lenta perché il browser deve ri-computare in modo ricorsivo posizione e dimensione degli elementi della pagina quando la costruisce graficamente. Più sono le tabelle annidate, peggiori sono le prestazioni nel rendering grafico.

Questo report elenca tutte le pagine che eccedono una data soglia di numero di tabelle annidate, ordinate in ordine decrescente. La colonna "Numero" mostra per ogni pagina l'effettivo numero di tabelle annidate.

La soglia utilizzata, al momento in cui questa guida è stata scritta, è "Maggiore di 0". Come molte altre, può essere personalizzata nelle Opzioni del programma, raggiungibile tramite la voce Strumenti -> Preferenze... nel menu principale del programma.
Nel tempo, con i cambiamenti nel mondo SEO, aggiorniamo le soglie predefinite per tenerti aggiornato con il mercato in continua evoluzione.

Come correggere il problema nelle pagine elencate:

Se il modello/template delle tue pagine usa tabelle annidate per ottenere il layout desiderato, è assolutamente il caso lo rifai daccapo con un approccio moderno, responsive e mobile-first, usando griglie CSS.

Se le tabelle annidate sono all'interno delle singole pagine, controlla perché sono usate. Molto probabilmente sono usate per motivi di layout e dovrebbero essere sostituite con stili CSS.

Profondità DOM

Tipo di criticità: Avvertimento

Quando un browser legge il codice sorgente HTML di una pagina web, da esso costruisce un DOM (Document Object Model, o modello a oggetti del documento), una struttura ad albero che tiene in memoria per rappresentare l'intero documento HTML.

Più complesso è il DOM, ossia maggiore è il numero dei nodi elementi e più è profonda la struttura ad albero, più sarà lenta la pagina web a essere mostrata e a reagire alle azioni di utenti e script, e maggiore sarà il consumo di memoria del computer.

Questo report elenca tutte le pagine che eccedono una data soglia di profondità del DOM, ordinate in ordine decrescente. La colonna "Numero" mostra per ogni pagina l'effettivo valore di profondità del DOM.

La soglia utilizzata, al momento in cui questa guida è stata scritta, è "Maggiore di 20". Come molte altre, può essere personalizzata nelle Opzioni del programma, raggiungibile tramite la voce Strumenti -> Preferenze... nel menu principale del programma.
Nel tempo, con i cambiamenti nel mondo SEO, aggiorniamo le soglie predefinite per tenerti aggiornato con il mercato in continua evoluzione.

Come correggere il problema nelle pagine elencate:

Controlla se la complessa struttura del DOM è causata dal tema (il modello/template della pagina). Se così fosse, la vista Istogramma nel pannello in basso dovrebbe mostrare l'alta profondità del DOM distribuita su tutte le pagine. Nel caso, considera il sostituire il template con uno più leggero.

Se l'alta profondità del DOM è presente solo in pagine singole, controlla se le puoi semplificare. Usa anche altre metriche per valutare la priorità degli interventi: tempo di caricamento della pagina, traffico della pagina, etc.

Elementi DOM

Tipo di criticità: Avvertimento

Questo report elenca tutte le pagine che eccedono una data soglia di numero di elementi del DOM, ordinate in ordine decrescente. La colonna "Numero" mostra per ogni pagina l'effettivo numero di elementi del DOM.

La soglia utilizzata, al momento in cui questa guida è stata scritta, è "Maggiore di 500". Come molte altre, può essere personalizzata nelle Opzioni del programma, raggiungibile tramite la voce Strumenti -> Preferenze... nel menu principale del programma.
Nel tempo, con i cambiamenti nel mondo SEO, aggiorniamo le soglie predefinite per tenerti aggiornato con il mercato in continua evoluzione.

Come correggere il problema nelle pagine elencate:

Controlla se la complessa struttura del DOM è causata dal tema (il modello/template della pagina). Se così fosse, la vista Istogramma nel pannello in basso dovrebbe mostrare l'alto numero di elementi del DOM distribuito su tutte le pagine. Nel caso, considera il sostituire il template con uno più leggero.

Se l'alto numero di elementi del DOM è presente solo in pagine singole, controlla se le puoi semplificare. Usa anche altre metriche per valutare la priorità degli interventi: tempo di caricamento della pagina, traffico della pagina, etc.

Script

Tipo di criticità: Avvertimento

Gli script sono spesso colpevoli di problemi di prestazioni web.

Un esempio di tag script nella sintassi HTML è, nel caso di script definito all'interno della pagina web:

<script> ...(il corpo dello script)... </script>

Nel caso di script definito in file condiviso:

<script src="...(un URL relativo o assoluto)..."></script>

Dovresti tenere al minimo il numero di script condivisi per diminuire il numero di chiamate HTTP, ed evitare il più possibile gli script bloccanti, script che forzano il browser ad arrestare la costruzione della pagina da visualizzare. Lo si ottiene normalmente utilizzando gli attributi defer o async, o muovendone la definizione appena prima della chiusura del tag body, dopo che tutti gli elementi HTML visuali sono stati definiti.

Questo report elenca tutte le pagine che eccedono una data soglia di numero di script, ordinate in ordine decrescente. La colonna "Numero" mostra per ogni pagina l'effettivo numero di script.

La soglia utilizzata, al momento in cui questa guida è stata scritta, è "Maggiore di 4". Come molte altre, può essere personalizzata nelle Opzioni del programma, raggiungibile tramite la voce Strumenti -> Preferenze... nel menu principale del programma.
Nel tempo, con i cambiamenti nel mondo SEO, aggiorniamo le soglie predefinite per tenerti aggiornato con il mercato in continua evoluzione.

Come correggere il problema nelle pagine elencate:

Usa il pannello "File CSS/JS di pagina" in basso per vedere che script sono. Potresti scoprire che alcuni non sono realmente usati, e dovrebbero essere rimossi.

Se sono condivisi tra tutte le pagine potresti unirli assieme per ridurre il numero di costose richieste HTTP.
Il CMS usato potrebbe offrirti modi per automatizzarlo; per esempio puoi trovare per WP diversi plugin in grado di unire i file dei tuoi script. Usali con cautela perché se non tarati correttamente potrebbero persino danneggiare le prestazioni: configurali con cura e testa prima di pubblicare in produzione. E poi misura ancora!

Script bloccanti

Tipo di criticità: Avvertimento

Gli script bloccanti - evidenziati nel pannello File CSS/JS di pagina in basso con il simbolo della lumaca - sono script che forzano il browser ad arrestare la costruzione della pagina da visualizzare.

Quando un browser incontra un blocco di <script>, non ha modo di sapere in anticipo se lo script contiene solo definizioni di variabili e funzioni (che non porrebbero problemi) o se contiene comandi diretti da eseguire che altererebbero il documento HTML - cose come il vecchio document.write(...) - per cui deve fermare l'interpretazione dell'HTML, e scaricare ed eseguire lo script prima di continuarla.
Ciò impedisce al browser di mostrare risultati parziali, e lo farza anche a dare precedenza al download dello script quando scarica risorse in parallelo, con l'effetto di aumentare il tempo di caricamento della pagina.

Per prevenire il problema degli script bloccanti la soluzione storica, e sempre valida, era di mettere tutti gli script nell'HTML dopo la definizione di tutti gli elementi visuali, prima della chiusura di tag </body> (metterli dopo il body potrebbe funzionare in alcuni browser, ma questi si suppone interrompano l'interpretazione del contenuto dopo di essa).
In seguito HTML introdusse gli attributi opzionali async e defer per permettere agli sviluppatori di dichiarare se uno script può essere eseguito in modo asincrono, o sincrono dopo che la pagina è stata caricata.

Uno script blocca la costruzione della pagina da visualizzare quando non usa gli attributi async o defer (che hanno senso solo quando l'attributo src è utilizzato), e non è definito dopo che sono definiti tutti gli elementi HTML visuali.

Questo report elenca tutte le pagine che eccedono una data soglia di numero di script bloccanti, ordinate in ordine decrescente. La colonna "Numero" mostra per ogni pagina l'effettivo numero di script bloccanti.

La soglia utilizzata, al momento in cui questa guida è stata scritta, è "Maggiore di 1". Come molte altre, può essere personalizzata nelle Opzioni del programma, raggiungibile tramite la voce Strumenti -> Preferenze... nel menu principale del programma.
Nel tempo, con i cambiamenti nel mondo SEO, aggiorniamo le soglie predefinite per tenerti aggiornato con il mercato in continua evoluzione.

Nota: in via predefinita il programma concede uno script bloccante perché un codice di installazione comune di Google Analytics è in realtà uno "script bloccante", sebbene molto breve e quasi istantaneo a eseguire, che crea un elemento script esterno nel DOM con attributo async.

Come correggere il problema nelle pagine elencate:

Dopo avere rimosso gli script inutilizzati, se quelli rimasti sono "bloccanti" puoi provare a renderli "non bloccanti".

Prima cosa: sposta tutti gli script prima della chiusura del tag </body>. Funzionerà anche per browser più datati che non supportano defer e async, e ha più o meno lo stesso effetto dell'attributo defer: eseguirli dopo che la pagine è stata costruita.
L'ordine di dichiarazione è importante: se lo scriptB dipende dallo scriptA, allora lo scriptA deve apparire prima.

Quando non hai controllo sulla posizione dello script, ma puoi aggiungere l'attributo defer, fallo. L'ordine di esecuzione sarà preservato, e inizierà dopo il caricamento della pagina.

Se sai che lo script non ha dipendenze particolari, puoi aggiungervi l'attributo async per caricarlo in modo asincrono in parallelo con altre risorse.

URL script duplicati

Tipo di criticità: Errore Errore

Invocare lo stesso script condiviso più di una volta può sembrare un errore da poco, perché si potrebbe pensare che avendo il browser già scaricato lo script questo è già nella cache del browser per cui non ci sarebbero problemi di prestazioni... sbagliato!
Può porre seri problemi di prestazioni: gli script non solo definiscono funzioni javascript (definire una funzione due volte non sarebbe un problema), possono anche contenere comandi diretti da eseguire sul DOM del documento. Prendi per esempio un'istruzione da essere eseguita all'evento di load del documento, sarebbe eseguita tante volte quante lo script condiviso appare nel codice sorgente HTML.

Questo report elenca tutte le pagine che eccedono una data soglia di numero di URL di script duplicati, ordinate in ordine decrescente. La colonna "Numero" mostra per ogni pagina l'effettivo numero di URL di script duplicati.

Come correggere il problema nelle pagine elencate:

Rimuovi tutte le dichiarazioni di script duplicate, e testa la correttezza del comportamento prima di mettere in produzione la modifica.

Stili CSS

Tipo di criticità: Avvertimento

Anche se non tanto come gli script, anche gli stili possono impattare le prestazioni.

Un esempio di tag style nella sintassi HTML è, nel caso di stile definito all'interno della pagina web:

<style> ...(il corpo dello stile)... </style>

Nel caso di stile definito in file condiviso:

<link href="...(un URL relativo o assoluto)..." rel="stylesheet" />

Dovresti tenere il numero di file di stile condivisi a un minimo così di ridurre il numero di chiamate HTTP.

Gli stili possono impattare le prestazioni web soprattutto quando sono stili bloccanti, ossia stili definiti all'interno della sezione body invece che nella head dell'HTML. Gli stili bloccanti forzano il browser ad arrestare la costruzione della pagina da visualizzare per rivalutarne le regole di visualizzazione, potenzialmente al costo di ricominciare la visualizzazione della pagina.

Questo report elenca tutte le pagine che eccedono una data soglia di numero di blocchi di stile, ordinate in ordine decrescente. La colonna "Numero" mostra per ogni pagina l'effettivo numero di blocchi di stile.

Come correggere il problema nelle pagine elencate:

Rimuovi tutte le dichiarazioni degli stili non effettivamente necessari, e unisci gli stili CSS condivisi per ridurre il numero delle richieste HTTP.
A seconda del CMS che usi, potresti trovare strumenti per automatizzare la cosa. Per esempio per WP puoi trovare diversi plugin in gradi di unire stili CSS condivisi; non fidarti del loro comportamento predefinito: testa sempre prima di spingere le modifiche in produzione, e assicurati che il risultato unito possa essere salvato nella cache del browser, deve avere un URL fisso.

Stili bloccanti

Tipo di criticità: Avvertimento

Gli stili bloccanti - evidenziati nel pannello File CSS/JS di pagina in basso con il simbolo della lumaca - sono stili definiti all'interno della sezione body invece che nella head dell'HTML. Forzano il browser ad arrestare la costruzione della pagina da visualizzare per rivalutarne le regole di visualizzazione, potenzialmente al costo di ricominciare la visualizzazione della pagina.

Questo report elenca tutte le pagine che eccedono una data soglia di numero di blocchi di stile bloccanti, ordinate in ordine decrescente. La colonna "Numero" mostra per ogni pagina l'effettivo numero di blocchi di stile bloccanti.

Come correggere il problema nelle pagine elencate:

Sposta tutti i blocchi di stile all'interno della sezione head dell'HTML.

URL stili duplicati

Tipo di criticità: Errore Errore

A differenza degli URL di script duplicati, gli URL di stili duplicati non costituiscono grandi problemi nei moderni browser, perché sarebbero scaricati solo una volta (se condividono esattamente lo stesso URL), e le loro regole sarebbero valutate solo una volta.
I browser più vecchi potrebbero però essere meno efficienti.

Questo report elenca tutte le pagine che eccedono una data soglia di numero di URL di stili duplicati, ordinate in ordine decrescente. La colonna "Numero" mostra per ogni pagina l'effettivo numero di URL di stili duplicati.

Come correggere il problema nelle pagine elencate:
Raccomandiamo se possibile di individuare tutti gli script condivisi duplicati e invocarli solo una volta nella sezione head del codice sorgente HTML, così da evitare potenziali problemi di prestazioni con i browser più vecchi.