Performance front-end 2021: test e monitoraggio

Pubblicato: 2022-03-10
Riassunto veloce ↬ Facciamo il 2021… veloce! Un elenco di controllo annuale delle prestazioni del front-end con tutto ciò che devi sapere per creare esperienze veloci sul Web oggi, dalle metriche agli strumenti e alle tecniche di front-end. Aggiornato dal 2016.

Sommario

  1. Prepararsi: pianificazione e metriche
  2. Stabilire obiettivi realistici
  3. Definire l'ambiente
  4. Ottimizzazioni degli asset
  5. Costruisci ottimizzazioni
  6. Ottimizzazioni di consegna
  7. Rete, HTTP/2, HTTP/3
  8. Test e monitoraggio
  9. Vittorie veloci
  10. Tutto in una pagina
  11. Scarica la lista di controllo (PDF, Apple Pages, MS Word)
  12. Iscriviti alla nostra newsletter via email per non perdere le prossime guide.

Test e monitoraggio

  1. Hai ottimizzato il flusso di lavoro di auditing?
    Potrebbe non sembrare un grosso problema, ma avere le giuste impostazioni a portata di mano potrebbe farti risparmiare un bel po' di tempo nei test. Prendi in considerazione l'utilizzo di Alfred Workflow per WebPageTest di Tim Kadlec per inviare un test all'istanza pubblica di WebPageTest. In effetti, WebPageTest ha molte caratteristiche oscure, quindi prenditi il ​​tempo necessario per imparare a leggere un grafico di visualizzazione a cascata di WebPageTest e come leggere un grafico di visualizzazione di connessione di WebPageTest per diagnosticare e risolvere più rapidamente i problemi di prestazioni.

    Puoi anche guidare WebPageTest da un foglio di calcolo di Google e incorporare accessibilità, prestazioni e punteggi SEO nella tua configurazione di Travis con Lighthouse CI o direttamente in Webpack.

    Dai un'occhiata a AutoWebPerf recentemente rilasciato, uno strumento modulare che consente la raccolta automatica di dati sulle prestazioni da più origini. Ad esempio, potremmo impostare un test giornaliero sulle tue pagine critiche per acquisire i dati sul campo dall'API CrUX e i dati di laboratorio da un report Lighthouse di PageSpeed ​​Insights.

    E se hai bisogno di eseguire rapidamente il debug di qualcosa ma il tuo processo di compilazione sembra essere notevolmente lento, tieni presente che "la rimozione degli spazi bianchi e la manipolazione dei simboli rappresentano il 95% della riduzione delle dimensioni nel codice minimizzato per la maggior parte di JavaScript, non elaborare le trasformazioni del codice. Puoi disabilita semplicemente la compressione per velocizzare le build di Uglify da 3 a 4 volte."

Uno screenshot della notifica della richiesta pull di GitHub in cui si afferma che è necessaria la revisione e che l'unione è bloccata fino a quando i controlli non sono stati risolti con successo
L'integrazione di accessibilità, prestazioni e punteggi SEO nella configurazione di Travis con Lighthouse CI metterà in evidenza l'impatto sulle prestazioni di una nuova funzionalità per tutti gli sviluppatori che contribuiscono. (Fonte immagine) (Anteprima grande)
  1. Hai testato in browser proxy e browser legacy?
    I test su Chrome e Firefox non sono sufficienti. Guarda come funziona il tuo sito web nei browser proxy e nei browser legacy. UC Browser e Opera Mini, ad esempio, detengono una quota di mercato significativa in Asia (fino al 35% in Asia). Misura la velocità media di Internet nei tuoi paesi di interesse per evitare grandi sorprese lungo la strada. Testare con la limitazione della rete ed emulare un dispositivo con DPI elevati. BrowserStack è fantastico per i test su dispositivi reali remoti e integralo anche con almeno alcuni dispositivi reali nel tuo ufficio: ne vale la pena.
  1. Hai testato le prestazioni delle tue 404 pagine?
    Normalmente non ci pensiamo due volte quando si tratta di 404 pagine. Dopotutto, quando un client richiede una pagina che non esiste sul server, il server risponderà con un codice di stato 404 e la pagina 404 associata. Non c'è molto da fare, vero?

    Un aspetto importante di 404 risposte è la dimensione effettiva del corpo della risposta che viene inviata al browser. Secondo la ricerca di 404 pagine di Matt Hobbs, la stragrande maggioranza delle 404 risposte proviene da favicon mancanti, richieste di caricamento di WordPress, richieste JavaScript non funzionanti, file manifest nonché file CSS e font. Ogni volta che un cliente richiede una risorsa che non esiste, riceverà una risposta 404 e spesso tale risposta è enorme.

    Assicurati di esaminare e ottimizzare la strategia di memorizzazione nella cache per le tue 404 pagine. Il nostro obiettivo è fornire HTML al browser solo quando si aspetta una risposta HTML e restituire un piccolo errore di payload per tutte le altre risposte. Secondo Matt, "se mettiamo una CDN davanti alla nostra origine, abbiamo la possibilità di memorizzare nella cache la risposta della pagina 404 sulla CDN. Questo è utile perché senza di essa, colpire una pagina 404 potrebbe essere utilizzato come vettore di attacco DoS, da costringendo il server di origine a rispondere a ogni richiesta 404 anziché lasciare che la CDN risponda con una versione memorizzata nella cache."

    Gli errori 404 non solo possono danneggiare le tue prestazioni, ma possono anche costare traffico, quindi è una buona idea includere una pagina di errore 404 nella suite di test di Lighthouse e tenerne traccia nel tempo.

  2. Hai testato le prestazioni delle tue richieste di consenso GDPR?
    In tempi di GDPR e CCPA, è diventato comune affidarsi a terze parti per fornire opzioni ai clienti dell'UE per accettare o rifiutare il monitoraggio. Tuttavia, come con qualsiasi altro script di terze parti, le loro prestazioni possono avere un impatto piuttosto devastante sull'intero sforzo di prestazioni.

    Naturalmente, è probabile che il consenso effettivo cambi l'impatto degli script sulle prestazioni complessive, quindi, come ha notato Boris Schapira, potremmo voler studiare alcuni profili di prestazioni web diversi:

    • Il consenso è stato completamente rifiutato,
    • Il consenso è stato parzialmente rifiutato,
    • Il consenso è stato interamente dato.
    • L'utente non ha agito alla richiesta di consenso (o la richiesta è stata bloccata da un blocco dei contenuti),

    Normalmente le richieste di consenso ai cookie non dovrebbero avere un impatto su CLS, ma a volte lo fanno, quindi prendi in considerazione l'utilizzo di opzioni gratuite e open source Osano o cookie-consent-box.

    In generale, vale la pena esaminare le prestazioni del popup poiché sarà necessario determinare l'offset orizzontale o verticale dell'evento del mouse e posizionare correttamente il popup rispetto all'ancora. Noam Rosenthal condivide gli insegnamenti del team di Wikimedia nell'articolo Case study sulle prestazioni Web: anteprime della pagina di Wikipedia (disponibili anche come video e minuti).

  3. Mantieni un CSS di diagnostica delle prestazioni?
    Sebbene possiamo includere tutti i tipi di controlli per garantire che il codice non performante venga distribuito, spesso è utile avere una rapida idea di alcuni dei frutti a basso impatto che potrebbero essere risolti facilmente. Per questo, potremmo usare il brillante Performance Diagnostics CSS di Tim Kadlec (ispirato allo snippet di Harry Roberts che mette in evidenza immagini caricate pigre, immagini non dimensionate, immagini in formato legacy e script sincroni.

    Ad esempio, potresti voler assicurarti che nessuna immagine above the fold venga caricata in modo pigro. È possibile personalizzare lo snippet in base alle proprie esigenze, ad esempio per evidenziare i caratteri Web non utilizzati o per rilevare i caratteri delle icone. Un piccolo grande strumento per garantire che gli errori siano visibili durante il debug o semplicemente per controllare il progetto corrente molto rapidamente.

    /* Performance Diagnostics CSS */ /* via Harry Roberts. https://twitter.com/csswizardry/status/1346477682544951296 */ img[loading=lazy] { outline: 10px solid red; }
  1. Hai testato l'impatto sull'accessibilità?
    Quando il browser inizia a caricare una pagina, crea un DOM e, se è presente una tecnologia assistiva come uno screen reader in esecuzione, crea anche un albero di accessibilità. L'utilità per la lettura dello schermo deve quindi interrogare l'albero di accessibilità per recuperare le informazioni e renderle disponibili all'utente, a volte per impostazione predefinita ea volte su richiesta. E a volte ci vuole tempo.

    Quando si parla di Time to Interactive veloce, di solito si intende un indicatore di quanto presto un utente può interagire con la pagina facendo clic o toccando collegamenti e pulsanti. Il contesto è leggermente diverso con gli screen reader. In tal caso, Time to Interactive veloce indica quanto tempo passa prima che l'utilità per la lettura dello schermo possa annunciare la navigazione su una determinata pagina e un utente dell'utilità per la lettura dello schermo può effettivamente premere la tastiera per interagire.

    Leonie Watson ha tenuto un discorso illuminante sulle prestazioni di accessibilità e in particolare sull'impatto che il caricamento lento ha sui ritardi degli annunci degli screen reader. Le utilità per la lettura dello schermo sono utilizzate per annunci veloci e navigazione rapida e quindi potrebbero essere potenzialmente anche meno pazienti degli utenti vedenti.

    Le pagine di grandi dimensioni e le manipolazioni DOM con JavaScript causeranno ritardi negli annunci degli screen reader. Un'area piuttosto inesplorata che potrebbe richiedere un po' di attenzione e test poiché gli screen reader sono disponibili letteralmente su ogni piattaforma (Jaws, NVDA, Voiceover, Narrator, Orca).

  2. È previsto un monitoraggio continuo?
    Avere un'istanza privata di WebPagetest è sempre vantaggioso per test rapidi e illimitati. Tuttavia, uno strumento di monitoraggio continuo, come Sitespeed, Calibre e SpeedCurve, con avvisi automatici ti darà un quadro più dettagliato delle tue prestazioni. Imposta i tuoi indicatori di temporizzazione utente per misurare e monitorare metriche specifiche dell'azienda. Inoltre, prendi in considerazione l'aggiunta di avvisi di regressione delle prestazioni automatizzati per monitorare le modifiche nel tempo.

    Cerca di utilizzare le soluzioni RUM per monitorare i cambiamenti nelle prestazioni nel tempo. Per strumenti di test di carico automatizzati simili a unit test, puoi usare k6 con la sua API di scripting. Inoltre, controlla SpeedTracker, Lighthouse e Calibre.

Sommario

  1. Prepararsi: pianificazione e metriche
  2. Stabilire obiettivi realistici
  3. Definire l'ambiente
  4. Ottimizzazioni degli asset
  5. Costruisci ottimizzazioni
  6. Ottimizzazioni di consegna
  7. Rete, HTTP/2, HTTP/3
  8. Test e monitoraggio
  9. Vittorie veloci
  10. Tutto in una pagina
  11. Scarica la lista di controllo (PDF, Apple Pages, MS Word)
  12. Iscriviti alla nostra newsletter via email per non perdere le prossime guide.