Questo case study descrive un flusso di lavoro passo passo per eseguire il debug e il miglioramento di INP
Reazione utilizzata da Trendyol sfruttando strumenti di Google come PageSpeed
Insights (PSI), Chrome DevTools e sull'API scheduler.yield.
Due componenti fondamentali di qualsiasi sito web di e-commerce sono la pagina scheda di prodotto (PLP) e la Pagina dei dettagli del prodotto. Spesso il traffico e-commerce proviene pagine delle schede di prodotto tramite campagne email, social media pubblicità. Di conseguenza, è fondamentale garantire che l'esperienza PLP attentamente progettato per ridurre il tempo necessario per effettuare un acquisto. Priorità la qualità dell'esperienza utente è essenziale per raggiungere il successo. Pubblicazioni di ricerca come Milliseconds Make Millions hanno già rivelato i significativi dell'impatto delle prestazioni web sui disponibili a spendere denaro e interagire con i brand online.
Trendyol è una piattaforma di e-commerce con circa 30 milioni di clienti e 240.000 venditori, che ci ha spinti a diventare la prima attività in Turchia con una valutazione di oltre 10 miliardi di dollari, e una delle principali piattaforme di e-commerce in nel mondo.
Per raggiungere l'obiettivo di fornire la migliore esperienza utente possibile su larga scala mantenendo la flessibilità dei contenuti e lavorando con una versione precedente di React, Trendyol ha puntato sull'interazioni con Next Paint (INP) come metrica chiave per migliorare. Questo case study descrive il percorso di Trendyol per migliorare l'INP nel suo PLP, con una conseguente riduzione del 50% dell'INP e un aumento dell'1% della ricerca metrica aziendale dei risultati.
Processo di indagine INP di Trendyol
INP misura l'adattabilità di un sito web all'input dell'utente. Un buon INP indica che il browser sia in grado di rispondere in modo rapido e affidabile a tutti gli input degli utenti e colorare la pagina, che è un componente fondamentale per una buona esperienza utente.
Il percorso di Trendyol per migliorare l'INP del suo PLP è iniziato con un'analisi approfondita l'esperienza utente prima di apportare miglioramenti. In base a un report PSI, l'esperienza utente reale del PLP aveva un INP di 963 millisecondi il dispositivo mobile, come mostrato nella figura successiva.
Per garantire una buona reattività, i proprietari di siti devono puntare a un INP di seguito o alla 200 millisecondi, vuol dire che, in quel momento, l'INP di Trendyol era "scadente" intervallo.
Fortunatamente, PSI fornisce entrambi i dati dei campi per le pagine incluse nel campo User Chrome User
Report sull'esperienza (CrUX) e dati diagnostici dettagliati del lab. Uno sguardo al laboratorio
il controllo del tempo di esecuzione JavaScript di Lighthouse ha suggerito che
Lo script search-result-v2 occupava il thread principale per più tempo rispetto ad altri
script della pagina.
Per identificare i colli di bottiglia del mondo reale, abbiamo utilizzato il riquadro delle prestazioni in Chrome DevTools per risolvere i problemi relativi all'esperienza PLP e identificare l'origine del problema. Emulazione delle prestazioni mobile con un rallentamento della CPU quadruplicato in Chrome DevTools ha rivelato un'attività di 700-900 millisecondi sul thread principale. Se l'istanza principale il thread è occupato da altre attività per più di 50 millisecondi, potrebbe non essere in grado di rispondere all'input dell'utente in modo tempestivo, il che comporta un un'esperienza utente positiva.
L'attività più lunga è stata causata da un callback dell'API Intersection Observer sulla script dei risultati di ricerca all'interno di un componente React. A questo punto, abbiamo iniziato suddividere l'attività lunga in piccole parti per fornire al browser opportunità di rispondere a lavori prioritari, comprese le interazioni degli utenti.
Si è scoperto che l'utilizzo dell'operazione setState che attiva la reazione
il rerendering all'interno del callback di Intersection Observer ha un costo elevato,
il che potrebbe essere problematico per i dispositivi di fascia bassa occupando il thread principale
troppo lungo.
Un metodo usato dagli sviluppatori per suddividere le attività in più piccole
riguarda setTimeout. Abbiamo usato questa tecnica per posticipare l'esecuzione del
setState in un'attività separata. Anche se setTimeout consente il rinvio
l'esecuzione di JavaScript, non offre alcun controllo sulla priorità. Ciò ha portato
di partecipare alla prova dell'origine di scheduler.yield per garantire
continuazione dell'esecuzione dello script dopo il passaggio al thread principale:
/*
* Yielding method using scheduler.yield, falling back to setTimeout:
*/
async function yieldToMain() {
if('scheduler' in window && 'yield' in scheduler) {
return await scheduler.yield();
}
return new Promise(resolve => {
setTimeout(resolve, 0);
});
}
/*
* Yielding to the main thread before changing the state of the component:
*/
const observer = new IntersectionObserver((entries) => {
entries.forEach(handleIntersection);
const maxNumberOfEntries = Math.max(...this.intersectingEntries);
if (Number.isFinite(maxNumberOfEntries)) {
await this.yieldToMain();
this.setState({ count: maxNumberOfEntries });
}
}, { threshold: 0.5 });
L'aggiunta di questo metodo di rendimento al codice PLP ha portato a un miglioramento INP, poiché l'attività principale lunga è stata suddivisa in una serie di attività più piccole, lavori prioritari, come le interazioni degli utenti e le successive attività di rendering, per avvengono prima del previsto.
Tieni presente che Trendyol utilizza il framework PuzzleJs per implementare un micro-frontend utilizzando React v16.9.0. Con la reazione 18, le stesse prestazioni potrebbero essere ma per una serie di motivi, Trendyol non può eseguire l'upgrade nel tempo.
Risultati aziendali
Per misurare l'impatto del miglioramento INP implementato, abbiamo eseguito un test A/B per vedere l'impatto sulle metriche aziendali. Nel complesso, le nostre modifiche al PLP hanno portato in un miglioramento significativo, tra cui una riduzione del 50% dell'INP e una riduzione dell'1% di aumento delle percentuali di clic dalla pagina delle schede alla pagina dei dettagli del prodotto per sessione utente. Nella figura seguente puoi vedere come è migliorato INP nella PLP nel tempo:
Conclusione
L'ottimizzazione di INP è un processo complesso e iterativo, ma può essere semplificato con un flusso di lavoro chiaro. Un approccio semplice al debug e al miglioramento L'INP di un sito web dipende dalla raccolta o meno di dati sul campo. Se non lo sono, PSI e Lighthouse sono un buon punto di partenza. Una volta identificati pagine con problemi, puoi usare DevTools per analizzare più a fondo e tentare di riprodurre che le applicazioni presentino problemi di prestazioni.
Possibilità di tornare al thread principale di tanto in tanto per offrire al browser più
di svolgere lavori urgenti rende il tuo sito web più reattivo, garantendo
la migliore esperienza utente dei tuoi clienti. API di pianificazione più recenti
come scheduler.yield(), semplificano questa attività.
Un ringraziamento speciale a Jeremy Wagner, Barry Pollard e Houssein Djirdeh, Google e il team tecnico di Trendyol per il loro contributo a questo lavoro.