Performance Lab: probando mejoras de rendimiento en WordPress

Hace unos meses que el equipo de Core de WordPress planteó la posibilidad de tener un grupo de trabajo específico para mejorar el rendimiento de WordPress. Tras varios meses ya tenemos los primeros resultados.

El objetivo inicial del grupo ha sido triple.

Por un lado, tenemos las propuestas de mejoras con respecto a los formatos de imágenes. Lo que se quiere conseguir es el uso de WebP como formato por defecto, lo que significa que, en un futuro, cuando se suba una imagen JPEG se convertirá automáticamente a WebP y será la que se utilice. Si más adelante aparecen formatos óptimos, se haría el cambio por esos.

La segunda línea es la informativa, y para ello se utilizará el Salud del Sitio, donde comenzaremos a ver notificaciones sobre el soporte a WebP, la cantidad de recursos CSS y JavaScript encolados o la posibilidad y necesidad de utilizar una caché de objetos.

Para acabar, aunque en este caso va directamente al núcleo de WordPress, se está trabajando en mejorar las funciones y funcionalidades de la caché de objetos. Estos cambios comenzarán a verse ya en la próxima versión de WordPress 6.0.

Performance Lab: el plugin

Con la creación de este grupo de trabajo también se planteó la posibilidad de crear un plugin para hacer experimentos. Antes de incluir cualquier novedad en el núcleo de WordPress pasaría por este plugin. Es un plugin seguro, ya que las funciones experimentales vienen desactivadas por defecto.

El plugin Performance Lab, en su versión 1.0.0-beta.1, que es su primera versión, incluye cuatro experimentos.

  • Subidas de WebP: Crea versiones WebP para las nuevas subidas de imágenes JPEG si el alojamiento es compatible.
  • Compatibilidad con WebP: Añade una comprobación de compatibilidad para WebP en el estado de Salud del Sitio.
  • Comprobación del estado de la caché de objetos persistente: Añade una comprobación de la caché de objetos persistente para los sitios con una cantidad no trivial de datos en el estado de la salud del sitio.
  • Auditoría de recursos en cola: Añade una comprobación de recursos CSS y JS en el estado de Salud del Sitio.

Una vez tengamos el plugin instalado, podemos visitar la sección de Ajustes > Rendimiento donde encontraremos la posibilidad de activar o desactivar las distintas pruebas.

Activar Subidas de WebP

La opción de subidas de WebP aún es muy limitada. Al subir la imagen en JPEG se van a crear las imágenes más pequeñas en formato WebP, pero, todavía no, la imagen original. Se puede insertar la imagen con el mismo nombre, pero cambiando la extensión .jpg por .webp.

Este módulo sufrirá bastantes mejoras en próximas versiones, y se incorporarán sistemas sencillos para que los usuarios no tengan que hacer nada, o puedan elegir qué formato desean utilizar.

Salud del Sitio

En la sección de Estado del Salud del Sitio nos encontraremos con cuatro nuevos bloques de información sobre el estado del sitio.

Scripts en cola

Este bloque nos indicará de la cantidad de JavaScript que temas y plugins incluyen de forma extra. Nos informará si estamos usando una cantidad justa o excesiva de elementos y su tamaño total.

Estilos en cola

Este bloque nos indicará de la cantidad de CSS que temas y plugins incluyen de forma extra. Nos informará si estamos usando una cantidad justa o excesiva de elementos y su tamaño total.

Compatibilidad WebP

Informa sobre la posibilidad o no de utilizar el nuevo formato WebP. En general el uso depende mucho de la versión de PHP que tengas y de las extensiones instaladas, además de la configuración del hosting.

Caché de Objetos persistente

WordPress incorpora de forma nativa el soporte a distintos sistemas de caché de objetos persistentes.

El mensaje te informará sobre la necesidad o no de utilizar una, y en caso de tener esa disponibilidad, de cómo activarla o solicitar a tu proveedor de hosting que lo haga.

Mejorar WordPress

Aunque esta es una versión muy básica del plugin, es la primera que lanza el equipo con el foco en que poco a poco se vaya incluyendo estas mejoras en las siguientes versiones de WordPress.

Si pruebas el plugin y tienes sugerencias o dudas o nuevas ideas, puedes abrir un ticket en la sección de issues de su Github.

Si te interesan las mejoras de rendimiento de WordPress, recuerda visitar la página del grupo de WordPress Performance y participar en su chat semanal en Slack (actualmente, los martes a las 16:00 UTC).

Redactado: Javier Casares

Cómo recuperar los Widgets clásicos

Uno de los mayores cambios de WordPress 5.8 es el lanzamiento de la nueva pantalla de Widgets en formato bloques, sustituyendo a la antigua pantalla.

Con este cambio, al igual que ya pasó con el editor, se pueden producir incompatibilidades con plugins o temas ya existentes y, por eso, la Comunidad WordPress ha decidido lanzar un plugin que vuelve a dejar todo lo relacionado con Widgets como antes.

Si con el cambio a WordPress 5.8 tienes alguna incompatibilidad, te recomendamos el uso de Classic Widgets, un feature-plugin que, en este caso, en vez de activar una nueva funcionalidad, reactiva una vieja funcionalidad.

Este plugin tendrá soporte hasta 2022, tiempo suficiente para que los desarrolladores de plugins y temas lancen versiones adaptadas a las nuevas funcionalidades.

¿Trunk o etiquetas? ¿Qué es mejor? (Respuesta: Etiquetas)

tl;dr – Te recomendamos enérgicamente que uses carpetas de etiqueta cuando publiques tus plugins. Tu yo del futuro te lo agradecerá.

Aunque siempre hemos recomendado usar carpetas de etiqueta en vez del «trunk», hay muchos desarrolladores que siguen usando trunk como valor para la etiqueta «Stable Tag». Tiene sentido. Usando trunk como tu etiqueta estable parece que tienes una cosa menos de la que preocuparte cuando publicas una actualización de tu plugin.

El problema de esta configuración es que hace que a todo el mundo le cueste seguir tu plugin, asegurarse de que está descargando la versión correcta y, sobre todo… hace que sea casi imposible volver a una versión anterior. Y desde la llegada de las actualizaciones automáticas a los plugins, esto último va a perjudicarte a largo plazo.

De hecho, estás empeorando todo esto:

  • No hay una forma sencilla de descargar las versiones anteriores para depurar problemas de compatibilidad.
  • Los traductores no pueden adelantarse a la publicación de una versión. Eso quiere decir que en cuanto publiques tu código, la traducción va a estar obsoleta hasta que los voluntarios puedan actualizarla.
  • Aumentas el riesgo de una publicación accidental.
  • No hay forma de permitirle a la gente descargarse la siguiente versión de una fuente oficial de WordPress.org
  • No hay forma de volver a versiones anteriores.

Entonces ¿Cuál es la forma correcta?

  1. Asegúrate de que la etiqueta «stable tag» de tu archivo readme.txt tiene la misma versión que la «stable version» del archivo principal de tu plugin (las dos tienen que coincidir)
  2. Añade todo en la carpeta trunk cuando hagas checkout en local (usa svn add y demás)
  3. Ejecuta svn cp trunk tags/1.2.3 — esto hará una copia de trunk a la carpeta de etiqueta
  4. Ejecuta svn ci -m "Releasing new version" — esto publicará tanto trunk como la etiqueta

Y ya está, has terminado. Ahora puedes editar y actualizar trunk todo lo que necesites, como versión de desarrollo y, mientras que el readme apunte a la etiqueta estable correcta, tus usuarios no recibirán ninguna actualización.

Vale, pero ¿Qué pasa si quieres tener una versión trunk para pruebas? ¡No cambies la etiqueta «stable tag» del readme de trunk! Ese es el valor que le dice a WordPress cuál es la versión «estable». Si estás trabajando en la 1.2.3, mantén la 1.2.2 como la estable en trunk y nadie recibirá el código nuevo hasta que estés listo.


Traducido de Trunk vs Tags? Which is Better? (Answer: Tags) de Mika Epstein