La risorsa più rapida e ottimizzata è una risorsa non inviata. Dovresti eliminare le risorse non necessarie dall'applicazione. È buona norma mettere in discussione e rivedere periodicamente i presupposti impliciti ed espliciti con il team. Ecco alcuni esempi:
- Hai sempre incluso la risorsa X nelle tue pagine, ma il costo del download e della visualizzazione della risorsa compensa il valore fornito all'utente? Sei in grado di misurare e dimostrare il suo valore?
- La risorsa (soprattutto se si tratta di una risorsa di terze parti) offre un rendimento costante? Questa risorsa si trova nel percorso critico o dovrebbe esserlo? Se la risorsa si trova nel percorso critico, potrebbe trattarsi di un single point of failure per il sito? Cioè, se la risorsa non è disponibile, influisce sulle prestazioni e sull'esperienza utente delle tue pagine?
- Questa risorsa richiede o ha uno SLA? Questa risorsa segue le best practice per le prestazioni: compressione, memorizzazione nella cache e così via?
Troppo spesso le pagine contengono risorse non necessarie o peggio ancora che ne ostacolano le prestazioni senza offrire un valore elevato al visitatore o al sito su cui sono ospitate. Questo vale sia per le risorse e i widget proprietari che di terze parti:
- Il sito A ha deciso di mostrare un carosello di foto nella sua home page per consentire al visitatore di visualizzare l'anteprima di più foto con un rapido clic. Tutte le foto vengono caricate quando la pagina è caricata e l'utente passa da una foto all'altra.
- Domanda: hai misurato quanti utenti visualizzano più foto nel carosello? Se scarichi risorse che la maggior parte dei visitatori non visualizza mai, potresti incorrere in un overhead elevato.
- Il sito B ha deciso di installare un widget di terze parti per visualizzare contenuti correlati, migliorare il coinvolgimento sui social o fornire altri servizi.
- Domanda: hai monitorato quanti visitatori utilizzano il widget o fanno clic sui contenuti forniti dal widget? Il coinvolgimento generato da questo widget è sufficiente a giustificarne l'overhead? Inoltre, puoi utilizzare una strategia di caricamento per assicurarti che lo script non venga caricato finché non è necessario?
Determinare se eliminare i download non necessari spesso richiede un'attenta valutazione e valutazione. Per ottenere risultati ottimali, fai un inventario periodico e rivedi queste domande per ogni asset nelle tue pagine.
Effetti sui Segnali web essenziali
L'iniziativa Core Web Vitals è stata introdotta da Google per fornire un insieme di metriche che riflettono l'esperienza degli utenti mentre utilizzano il web. Sebbene esistano molte strategie di ottimizzazione per Segnali web essenziali, se ti chiedi se caricare una determinata risorsa su una pagina potresti trovare un modo per migliorare queste metriche sul tuo sito web. Di seguito sono riportati alcuni esempi, raggruppati per Segnali web essenziali, che vale la pena esaminare. Anche se questo non è un elenco esaustivo (e ce ne sono molti) di esempi, rileggerli potrebbe fornire spunti di riflessione.
Largest Contentful Paint (LCP)
La metrica Largest Contentful Paint (LCP) misura il caricamento dei contenuti più grandi, ad esempio un'immagine hero o un titolo. È considerata un'importante metrica percettiva che dà all'utente l'impressione che un sito si carichi rapidamente.
In generale, il download di meno risorse significa che la larghezza di banda di cui dispone l'utente sarà allocata tra meno risorse e può tradursi in un miglioramento della metrica LCP. Un esempio classico è il caricamento lento, per cui le immagini esterne all'area visibile durante il caricamento pagina non vengono scaricate finché il browser non ha stabilito che è più probabile che le vedano. Se disponi di una grande galleria di miniature di, ad esempio, 50 immagini, il caricamento lento tutte le foto tranne le prime dieci significa che il browser può utilizzare in modo più efficiente la larghezza di banda a sua disposizione e le prime immagini che l'utente vedrà verranno caricate più rapidamente.
Tuttavia, non si tratta solo di caricare meno immagini, necessariamente. Il browser ha uno schema di prioritizzazione interno che determina la quantità di larghezza di banda che ogni risorsa deve ricevere. Tuttavia, anche con tutte le risorse, in particolare quelle scaricate con priorità elevata, hanno il potenziale di privare la risorsa dipendente di un potenziale elemento LCP. in particolare per le connessioni di rete lente. Questa risorsa dipendente può essere un file immagine che rappresenta l'elemento LCP della pagina, ma potrebbe anche essere una risorsa di carattere web di cui il browser ha bisogno per visualizzare un nodo di testo che potrebbe essere determinato come elemento LCP della pagina.
Se il tuo sito web è ricco di testo, l'elemento LCP di una pagina potrebbe essere un nodo di testo. Anche se esistono molte strategie di caricamento e ottimizzazione dei caratteri efficaci, può essere opportuno valutare se un carattere di sistema è sufficiente per le esigenze del tuo sito web, in modo che gli elementi LCP, ovvero nodi di testo, possano essere caricati senza alcuna dipendenza da una risorsa di carattere web e vengano visualizzati quasi immediatamente quando il CSS e l'HTML arrivano dal server.
Cumulative Layout Shift (CLS)
Ogni risorsa caricata potenzialmente può contribuire al Cumulative Layout Shift (CLS) di una pagina, in particolare se il download non è terminato entro il momento in cui è stata visualizzata la pagina iniziale. Per le immagini, evita che il CLS implichi pratiche come l'impostazione di dimensioni esplicite. Per quanto riguarda i caratteri, la gestione del caricamento dei caratteri e la potenziale corrispondenza dei caratteri di riserva possono ridurre al minimo le variazioni durante il periodo di scambio di un carattere web. Per JavaScript, potrebbe essere necessario gestire il modo in cui lo script manipola il DOM in modo che le variazioni del layout vengano ridotte a un numero accettabile.
Ogni risorsa che contribuisce al CLS di una pagina richiede un certo impegno per garantire che il layout della pagina sia sufficientemente stabile. Mettendoti in dubbio se hai bisogno o meno di una risorsa specifica, non solo accelera i caricamenti delle pagine, ma riduci anche lo sforzo cognitivo necessario per preservare la stabilità del layout. Ciò porta non solo a un'esperienza utente molto meno frustrante, ma anche a un'esperienza sviluppatore meno frustrante, poiché avrai più tempo per perseguire altri obiettivi nei tuoi progetti.
Interaction to Next Paint (INP) e First Input Delay (FID)
Interaction to Next Paint (INP) e First Input Delay (FID) sono metriche che misurano la reattività agli input degli utenti. Anche se a marzo 2024 è prevista la sostituzione di FID come Segnale web essenziale a marzo 2024, le strategie di ottimizzazione per FID tendono a essere applicate anche a INP. Inoltre, in genere l'INP è più difficile da ottimizzare rispetto a FID, in quanto monitora la latenza completa dell'interazione per tutte le interazioni delle pagine, non solo il ritardo di input della prima interazione come misura FID.
INP e FID tendono a essere maggiormente interessati da JavaScript, in quanto JavaScript è ciò che determina la maggior parte delle esperienze di interattività sul web. Sia per INP che per FID, la quantità di risorse di script scaricate durante il caricamento della pagina darà inizio a operazioni potenzialmente dispendiose nella valutazione e compilazione degli script. Minore è il numero di JavaScript caricato durante l'avvio, minore è il lavoro che il browser deve svolgere in quel punto critico dell'esperienza sulla pagina.
Sebbene esistano strategie per ridurre le dimensioni delle risorse JavaScript scaricate durante l'avvio, ad esempio la suddivisione del codice e la tremolio ad albero, vale la pena controllare i pacchetti utilizzati nei progetti per vedere se sono necessari. Ad esempio, lodash offre molti metodi che sono ancora utili oggi, ma è fornito con metodi predefiniti forniti dal browser, come Array funzioni specifiche per la mappatura, la riduzione e il filtro e molti altri.
Il miglioramento progressivo è anche un approccio utile a JavaScript, in quanto ti consente di offrire un'esperienza di base (ma ancora funzionale) agli utenti, che puoi aggiungere agli utenti con dispositivi più potenti e connessioni di rete più veloci. Indipendentemente dal fatto che tu segua o meno il principio del miglioramento progressivo, il punto è: ogni risorsa JavaScript che puoi evitare di scaricare può generare un'esperienza che risponde più rapidamente alle interazioni degli utenti, un aspetto fondamentale delle prestazioni web.
Conclusione
Verificare l'eventuale presenza di download non necessari sul tuo sito web potrebbe essere solo un aspetto della velocità delle esperienze utente, ma è un aspetto che potenzialmente ha un impatto elevato. Ricapitolando:
- Esegui l'inventario dei tuoi asset e di quelli di terze parti nelle tue pagine.
- Misura le prestazioni di ogni asset: il suo valore e le sue prestazioni tecniche.
- Determina se le risorse forniscono un valore sufficiente.
- Comprendi l'effetto dei download non necessari sui Segnali web essenziali e sulle metriche di supporto.
Ottimizzando l'efficienza dei contenuti in questo modo, non solo puoi migliorare il rendimento complessivo, ma puoi anche fare attenzione a non sprecare la larghezza di banda degli utenti, nonché a migliorare potenzialmente le metriche incentrate sull'utente e a offrire una migliore esperienza utente.