Home Istruzioni Assicuratevi un carico inferiore al secondo per il vostro sito di eCommerce
Applications

Assicuratevi un carico inferiore al secondo per il vostro sito di eCommerce

About The Author

Outline

Garantire tempi di caricamento inferiori al secondo per il tuo sito di eCommerce è un lavoro impegnativo. A Layer0, abbiamo cercato di renderlo un processo molto più semplice, e Layer0 è qui per aiutarti a raggiungere questo traguardo. Quello che abbiamo fatto qui è creare una lista di controllo che puoi seguire per assicurarti che il tuo sito di produzione sia incredibilmente veloce e spendi il minor tempo a realizzarlo.

Per prima cosa, parliamo di come misuriamo la velocità:

Misurazione delle prestazioni

** Abbiamo utilizzato SpeedCurve (SC) in questo caso, ma è possibile utilizzare WebPageTest o qualsiasi altro prodotto
Ci stiamo concentrando sulle metriche LCP per le nostre misurazioni. I nostri obiettivi sono:

  • Pagina iniziale <1.5s
  • Navigazione da PLP a PDP: 0,5 s.

È anche importante tenere a mente i seguenti 3 casi in quanto influisce sull’esperienza del consumatore quando A) direttamente ai PLP/PDP a seguito del traffico di ricerca organico e (b) quando si accede alle pagine del carrello/cassa, un aspetto cruciale per i nostri clienti dal punto di vista aziendale:

  • PLP come pagina di destinazione
  • PDP come pagina di destinazione
  • PWA -> origine/legacy (ad es. Al carrello/checkout)

Iniziamo con alcuni controlli di base che potrebbero aiutarci a ottenere alcuni importanti guadagni di velocità

  • Assicurarsi che vengano utilizzati gli scheletri e che il layout sia stabile.
  • Messaggio «Waiting for…» (o simile) nella finestra del browser (un problema noto in WebPageTest utilizzato da SC): Ispezionare le immagini a cascata per vedere se questa è l’unica causa di degradazione delle metriche.
  • L’opzione da immagine a bassa risoluzione a immagine ad alta risoluzione potrebbe anche causare una degradazione delle metriche in SC – ispezionare le immagini a cascata per vedere se questa è l’unica causa.
  • Artefatti da componenti personalizzati (rispetto ai componenti RSF nativi creati tenendo presente le BEST practice) – stili/elementi che causano un rendering eccessivo dei componenti. Esaminare nuovamente le immagini a cascata per verificare la presenza di artefatti visibili (ad esempio, immagine a bassa risoluzione -> carosello immagini su> transizione PLP-PDP)

Navigazione da PLP a PDP

La navigazione dalle pagine PLP (Search Results o Category/Brand Pages) alle pagine PDP è l’elemento di navigazione più importante dell’intero percorso del consumatore. Per ogni acquisto effettuato, un utente medio accede a 8,8 pagine PDP. Anche un rallentamento minore delle pagine con una frequenza così elevata può avere un impatto negativo notevole sull’esperienza utente. Ecco alcune cose che puoi seguire per garantire un’esperienza utente perfetta da PLP a PDP:

  • Utilizzare uno scheletro per la pagina sopra la piega e garantire la stabilità del layout
  • Assicurarsi che il contenuto sopra la piega corrisponda all’altezza dello schermo del dispositivo dell’utente.
  • Assicurarsi che la memorizzazione nella cache sia configurata correttamente. Ciò significa memorizzare nella cache i dati di pagina generici e non i punti dati specifici dell’utente. (Consulta la nostra guida sul caching per ulteriori dettagli)
  • USA il pre-caricamento (consulta la nostra guida sul pre-caricamento per ulteriori dettagli)
  • Utilizzare la stessa istanza di miniature ovunque per evitare lo sfarfallio con il componente Inoltra miniatura
  • Passare il maggior numero di informazioni da PLP a PDP nelle pagine props per visualizzare tali informazioni su PDP

Caricamento home page

La home page di solito è la prima interazione che un utente ha con il sito Web. Garantire un ottimo inizio di viaggio è fondamentale per fornire agli utenti un flusso di lavoro soddisfacente fino alla cassa e all’ordine. Di seguito sono riportate alcune delle cose che puoi seguire per garantire un’esperienza di Home Page ottimale:

  • Assicurarsi che la memorizzazione nella cache sia configurata correttamente. Ciò significa memorizzare nella cache i dati di pagina generici e non memorizzare nella cache alcun punto dati specifico dell’utente.
  • Carico lento al di sotto del contenuto della piega
  • Utilizzare l’etichetta di preconnessione
  • Ottimizzare le immagini
  • Ritardare l’idratazione fino al completamento del caricamento della pagina
  • Altri miglioramenti

Caricamento pagina PDP

Dedicare del tempo all’ottimizzazione di Home Page e PLP alla navigazione PDP sarebbe inutile se l’utente non avesse una grande esperienza sulla pagina PDP stessa. Garantire che le informazioni più importanti siano disponibili all’utente il prima possibile e ritardare gli oggetti che non sono immediatamente visibili o utilizzabili è fondamentale per ottimizzare i caricamenti delle pagine PDP. Di seguito sono riportati alcuni elementi da tenere a mente durante l’ottimizzazione delle pagine PDP:

  • Memorizzare nella cache risorse e dati generici, incluse le risposte API, per garantire il recupero immediato dei dati e ridurre i colli di bottiglia sui sistemi back-end.
  • Contenuto di carico lento sotto la piega
  • Utilizzare una prima immagine ottimizzata per ridurre i tempi di caricamento.
  • Utilizzare miniature separate e avvicinare e ingrandire le immagini e caricarle solo su richiesta.

Caricamento pagina PLP

  • Precaricare le immagini PDP per i risultati sopra la piega.
  • Contenuto di carico lento sotto la piega
  • Ridurre o evitare le richieste per determinare le modifiche alle pagine PLP, ad esempio le modifiche al colore di sfondo o altri elementi visivi.

Altri puntatori

I metodi menzionati sopra coprono la maggior parte delle cose con cui un utente interagisce durante il viaggio. Ma c’è più di ciò che è visibile in una piattaforma. Assicurarsi che i meccanismi interni della piattaforma siano ottimizzati è il prossimo passo che dobbiamo fare. Di seguito sono riportati alcuni elementi da controllare per recuperare ulteriori miglioramenti nelle prestazioni:

  • TTL: controllare la dimensione del bundle usando Analyze=True npm run build
  • FCP: se un cliente sceglie di utilizzare un Webfont, il punteggio LH si riduce.
  • Indice di velocità : la presenza di finestre a comparsa sullo schermo riduce l’indice di velocità della pagina
  • Evitare lunghe operazioni di esecuzione nell’ambito del modulo, ad esempio lato client.
  • I ganci React sono soggetti a un rendering non necessario. Anche se è improbabile che influenzino le metriche, creano un sito Web lento.
  • Utilizzare i punteggi PSI per comprendere l’impatto delle modifiche al codice piuttosto che i punteggi LH della macchina locale e/o i risultati SpeedCurve. Utilizzare la modalità 4G nella produzione per ottenere punteggi LH realistici.