Este caso de éxito describe un flujo de trabajo paso a paso de depuración y mejora de INP
en React, utilizado por Trendyol aprovechando herramientas de Google como PageSpeed
Insights (PSI), Herramientas para desarrolladores de Chrome y la API de scheduler.yield.
Dos componentes fundamentales de cualquier sitio web de comercio electrónico son la página de ficha de producto (PLP) y la página de detalles del producto (PDP). El tráfico de comercio electrónico suele provenir de las páginas de fichas de productos, ya sea a través de campañas por correo electrónico, redes sociales publicidad. Por eso, es fundamental garantizar que la experiencia de PLP diseñados cuidadosamente para reducir el tiempo que lleva realizar una compra. Priorización la calidad de la experiencia del usuario es esencial para lograr el éxito. Publicaciones de investigación como Milliseconds Make Millions ya revelaron la importancia del rendimiento web en las redes voluntad de gastar dinero e interactuar con marcas en línea.
Trendyol es una plataforma de comercio electrónico con alrededor de 30 millones de clientes y 240,000 vendedores, lo que nos impulsó a convertirnos en la primera empresa en Türkiye con una valoración de más de $10, 000 millones y es una de las principales plataformas de comercio electrónico de del mundo.
Para lograr su objetivo de proporcionar la mejor experiencia del usuario posible a gran escala sin perder la flexibilidad del contenido y trabajar con una versión anterior de en React, Trendyol se centró en Interaction to Next Paint (INP) como métrica clave para que puedes mejorar. Este caso de éxito describe el recorrido de Trendyol para mejorar INP en su PLP, lo que generó una reducción del 50% del INP y un aumento del 1% en la búsqueda métrica comercial del resultado.
Proceso de investigación de INP de Trendyol
INP mide la capacidad de respuesta de un sitio web a la entrada del usuario. Un buen INP indica que el navegador pueda responder de forma rápida y confiable a todas las entradas del usuario y volver a pintar la página, lo que es un componente clave para una buena experiencia del usuario.
El recorrido de Trendyol para mejorar el INP en su PLP comenzó con un análisis exhaustivo la experiencia del usuario antes de realizar cualquier mejora. Según un informe de PSI, la experiencia real del usuario del PLP tuvo un INP de 963 milisegundos móvil, como se muestra en la siguiente figura.
Para garantizar una buena capacidad de respuesta, los propietarios de los sitios deben tener como objetivo un INP menor o con 200 milisegundos, lo que significa que, en ese momento, el INP de Trendyol estaba “deficiente” del rango de destino de la ruta.
Afortunadamente, PSI proporciona datos de ambos campos para las páginas incluidas en la página de usuarios de Chrome
Experience Report (CrUX) y datos de diagnóstico de laboratorio detallados Revisar el lab
datos, la auditoría de tiempo de ejecución de JavaScript de Lighthouse sugirió que
La secuencia de comandos search-result-v2 estuvo ocupando el subproceso principal durante más tiempo que otro
secuencias de comandos en la página.
Para identificar los cuellos de botella del mundo real, usamos el panel de rendimiento de Chrome. Herramientas para desarrolladores para solucionar problemas relacionados con la experiencia de PLP e identificar el origen del error problema. Emulación del rendimiento en dispositivos móviles con una demora de CPU 4 veces mayor en las Herramientas para desarrolladores de Chrome reveló una tarea de 700 a 900 milisegundos de duración en el subproceso principal. Si el código principal subproceso esté ocupado con otras tareas durante más de 50 milisegundos, puede no podremos responder a la entrada del usuario de manera oportuna, lo que resulta en un la experiencia del usuario.
La tarea más larga fue causada por una devolución de llamada de la API de Intersection Observer en el secuencia de comandos de resultados de la búsqueda dentro de un componente de React. En este punto, empezamos dividir esa tarea larga en fragmentos pequeños para darle al navegador más oportunidades para responder al trabajo de mayor prioridad, incluidas las interacciones de los usuarios.
Resulta que usar la operación setState, que activa React
la renderización en la devolución de llamada
Intersection Observer tiene un costo alto
lo que puede causar problemas para los dispositivos de gama baja, ya que ocupa el subproceso principal
demasiado extenso.
Un método que los desarrolladores han usado para dividir las tareas en otras más pequeñas
incluye setTimeout. Utilizamos esta técnica para posponer la ejecución de la
setState en una tarea separada. Si bien setTimeout permite diferir
la ejecución de JavaScript, no proporciona ningún control sobre la prioridad. Esto llevó a
unirnos a la prueba de origen de scheduler.yield con el fin de garantizar la
continuación de la ejecución de nuestra secuencia de comandos después de ceder al subproceso principal:
/*
* 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 });
Agregar este método de rendimiento al código PLP dio como resultado un INP mejorado, ya que el la tarea larga principal se dividió en una serie de otras más pequeñas, lo que permite trabajo de mayor prioridad, como las interacciones del usuario y el trabajo de renderización posterior, para se lleven a cabo antes de lo que hubieran ocurrido en otras circunstancias.
Ten en cuenta que Trendyol usa el framework PuzzleJs para implementar un microfrontend de Terraform con React v16.9.0. Con React 18, el mismo rendimiento podría verse conseguido, pero por varias razones, Trendyol no puede actualizarse con esta tiempo.
Resultados empresariales
Para medir el impacto de la mejora de INP implementada, ejecutamos una prueba A/B para ver cómo se vieron afectadas las métricas empresariales. En general, los cambios en el PLP dieron lugar a en una mejora significativa, incluida una reducción del 50% en el INP y una reducción del 1% de aumento en las tasas de clics de la página de fichas a la página de detalles del producto por sesión de usuario. En la siguiente imagen, se puede ver cómo INP mejoró la PLP a lo largo del tiempo:
Conclusión
La optimización del INP es un proceso iterativo y complejo, pero se puede facilitar con un flujo de trabajo claro. Un enfoque simple para depurar y mejorar tu del INP de tu sitio web depende de si recopilas tus propios datos de campo. Si PSI y Lighthouse son un buen punto de partida. Una vez que hayas identificado páginas con problemas, puedes usar Herramientas para desarrolladores para profundizar en el intento de reproducir problemas.
ceder al subproceso principal de vez en cuando para darle al navegador más
las oportunidades para hacer trabajos urgentes harán que tu sitio web sea más responsivo, lo que garantizará
para que tus clientes tengan una mejor experiencia del usuario. APIs de programación más nuevas
como scheduler.yield() facilitan esta tarea.
Agradecimientos especiales a Jeremy Wagner, Barry Pollard y Houssein Djirdeh del Google y el equipo de Ingeniería de Trendyol por su contribución a este trabajo.