El desarrollo de WordPress 6.2 condujo a mejoras en la forma en que trabaja el equipo central de desarrollo, lo que resultó en un enfoque constante en el rendimiento en cada paso del desarrollo. Estos nuevos procesos detectan los problemas en el momento en que se introducen los cambios y evitan que lleguen a la versión final.
Las dos mejoras responsables de este cambio son:
- Un nuevo rol principal de rendimiento para la coordinación entre equipos.
- Evaluación comparativa automatizada
Estas dos mejoras permitieron que el equipo de WordPress hiciera que el rendimiento fuera parte del desarrollo de cada parte de WordPress, esencialmente agregándolo a su ADN de desarrollo.
Los resultados hablan por si mismos:
6.2 es la primera versión importante que mejora el rendimiento del lado del servidor en todos los ámbitos:
- +25 % para temas de bloque en todas las métricas (mediana, mín., máx., percentil 75).
- +10% de mejora para temas clásicos (percentil 75).
Estos resultados son más notables en comparación con las versiones anteriores de la versión principal.
Las versiones de WordPress 6.1, 6.0, 5.8 y 5.9 se quedaron atrás con mediciones de rendimiento negativas.
Lecciones aprendidas de WordPress 6.1
La versión anterior de WordPress, la versión 6.1, se caracterizó por una caída general en el rendimiento, a lo que WordPress se refiere como una caída en el rendimiento.
La regresión del rendimiento se produce cuando una mejora conduce a una disminución del rendimiento.
Lo que descubrieron fue que, a pesar de que habían solucionado la principal causa de degradación del rendimiento e introducido varias mejoras de rendimiento, el rendimiento general del sitio aún se veía afectado por cambios que afectaban el rendimiento.
WordPress explicó la lección que aprendieron de la versión 6.1:
«A pesar de que otras mejoras de rendimiento terminaron en estas versiones, las regresiones finalmente anularon las mejoras».
… Cuantas más regresiones haya, menos efectivas serán todas las demás mejoras de rendimiento en general».
Líder de desarrollo de WordPress
El proceso de desarrollo de WordPress 6.2 ha concluido con la coordinación de un nuevo rol de Performance Lead.
El gestor de rendimiento no inicia los cambios y mejoras. Esa fue la tarea del equipo de desarrollo.
El rendimiento conduce simplemente coordinado entre los equipos.
Cada uno de los equipos es responsable de las ganancias de rendimiento de sus proyectos.
El administrador de energía explicó cómo funcionaba esto:
“Esto me permitió trabajar de cerca y apoyar a los demás colaboradores y alinear nuestros enfoques para medir el desempeño con ellos.
…las ganancias de rendimiento en esta versión son el resultado del excelente trabajo de varios colaboradores para identificar el bajo rendimiento.
Presentar el rol principal de rendimiento… solo trajo una mejor representación del rendimiento junto con los otros miembros del equipo de lanzamiento».
Evaluación comparativa automatizada de WordPress
WordPress descubrió que las regresiones en el rendimiento pasaban desapercibidas porque no todos los cambios podían verificarse manualmente para determinar el impacto en el lanzamiento general.
Para abordar la falta de poder probar manualmente cada cambio en el núcleo, WordPress introdujo una evaluación comparativa de rendimiento automatizada para todos los cambios.
La evaluación comparativa de rendimiento automatizada mide el impacto de cada cambio para descubrir cuellos de botella de rendimiento ocultos antes de que lleguen a las versiones finales.
WordPress describe este cambio de flujo de trabajo:
“Varios colaboradores han colaborado para introducir un flujo de trabajo de CI automatizado para la medición del rendimiento en el núcleo de WordPress…
Con este flujo de trabajo de CI, las métricas de rendimiento del núcleo de WordPress ahora se registran para cada confirmación individual y están disponibles en este panel.
Esto nos permite detectar fácilmente posibles regresiones donde antes habrían pasado desapercibidas”.
La actualización de WordPress 6.1 introdujo regresiones de rendimiento en Gutenberg, problemas que se habrían detectado de antemano con pruebas automatizadas.
Las pruebas de rendimiento automatizadas ocurren en cada confirmación central en GitHub para medir cómo funciona WordPress en bloques y temas clásicos.
La prueba también recopila métricas de tiempo del servidor utilizando la última versión de PHP.
Más información sobre el monitoreo de rendimiento automatizado aquí: Monitoreo de rendimiento automatizado en WordPress Core.
Colaboradores de WordPress colaboraron
El personal de WordPress trabajó para identificar las áreas que necesitaban mejoras, con un enfoque renovado en el rendimiento.
El rendimiento del lado del servidor del núcleo de WordPress se perfiló utilizando las herramientas de código abierto Xdebug, XHProf y Blackfire (SaaS).
La evaluación comparativa del núcleo de WordPress fue menos fácil ya que los grupos de desarrollo utilizaron diferentes herramientas.
La estandarización de las herramientas de medición del desempeño está en curso para que todos los equipos midan lo mismo con las mismas herramientas.
Hecho: WordPress 6.2 funciona mejor
El resultado de la evaluación comparativa de rendimiento automatizada y el ajuste de rendimiento entre los equipos de desarrollo es una mejora significativa en las métricas de rendimiento.
WordPress compartido:
“Según los puntos de referencia del laboratorio, WordPress 6.2 se carga entre un 14 % y un 18 % más rápido en general para los temas de bloque y entre un 2 % y un 5 % más rápido en general para los temas clásicos (medido a través de Largest Contentful Paint / LCP).
En particular, el rendimiento del lado del servidor (medido a través del tiempo hasta el primer byte/TTFB) ve un gran aumento del 17 al 23 % para los temas de bloque y del 3 al 5 % para los temas clásicos, lo que contribuye directamente al tiempo de carga general”.
Las pruebas de rendimiento no solo se llevan a cabo en la fase de confirmación central, sino que se realizan evaluaciones comparativas para todos los candidatos de lanzamiento de WordPress.
WordPress describe este proceso:
“Especialmente en este punto, es recomendable utilizar la versión ZIP de producción del núcleo de WordPress (por ejemplo, una versión beta o RC específica) en lugar de medir en el entorno de desarrollo del núcleo de WordPress.
El comando benchmark-web-vitals mencionado en la sección anterior es perfecto para este caso de uso, ya que proporciona métricas de rendimiento de alto nivel que capturan el rendimiento tanto del lado del servidor como del lado del cliente.
Los datos resultantes se pueden comparar con las mismas métricas de, p. B. la versión estable anterior para tener una idea de cómo ha cambiado el rendimiento del núcleo de WordPress (¡ojalá haya mejorado!) en la nueva versión.”
WordPress ha dado la vuelta al rendimiento
WordPress ha trabajado duro durante los últimos años para incorporar mejoras de rendimiento en el flujo de trabajo de desarrollo.
Al principio, el equipo de rendimiento hizo mejoras, p. B. reducir el JavaScript redundante o innecesario cargado para cada página y agregar cosas como la carga diferida de imágenes.
Pero ahora el equipo de rendimiento integra los puntos de referencia de rendimiento directamente en la fase de desarrollo de cada componente mejorado en el nivel de compromiso de GitHub y aprovecha los puntos de referencia de rendimiento automatizados para escalar las mejoras.
En esencia, WordPress ha incorporado con éxito el rendimiento en el ADN de su proceso de desarrollo.
Este es uno de los cambios más trascendentales en el desarrollo de WordPress y una señal de que WordPress está en camino de ponerse al día con otros sistemas de administración de contenido.
Finalmente, WordPress puede estar de vuelta en el juego de rendimiento.
Lea el anuncio completo de WordPress, que incluye detalles sobre su progreso y enlaces a las herramientas utilizadas para comparar el rendimiento.
Los beneficios de la priorización y la medición del rendimiento en WordPress 6.2
Imagen destacada de Shutterstock/Asier Romero
