Imágenes, PHP y otras mejoras de velocidad

Módulo 6: Velocidad · Tiempo de lectura: 9 minutos

Objetivo de la lección: Después de esta lección podrá aplicar las principales mejoras de velocidad restantes y medir su efecto.

Conceptos clave: optimización de imágenes, WebP y AVIF, lazy loading, la imagen LCP, fetchpriority, versión de PHP, limpieza de la base de datos (revisiones, transients, autoload), WP-Cron, cron real, DISABLE_WP_CRON, tipografías externas, Heartbeat

Trabaje en el orden correcto

Después de una caché de página (lección 6.2), estas son las mejoras que más rinden, aproximadamente en orden de esfuerzo frente a efecto:

1. imágenes en orden;
2. una versión actual de PHP;
3. menos componentes externos y plugins pesados;
4. una base de datos ordenada;
5. tareas programadas en un cron real.

Mida antes y después de cada paso (lección 6.1), de lo contrario no sabrá qué ha ayudado. Y haga una cosa a la vez.

Imágenes: la mayor ganancia en el navegador

En la mayoría de las páginas, las imágenes son la mayor parte de lo que descarga un visitante. Lo que aprendió en la lección 4.4 da aquí sus frutos:

• Tamaño correcto: no suba imágenes más grandes de lo necesario y deje que WordPress ofrezca formatos más pequeños mediante srcset.
• Compresión y formato: WebP suele ser bastante más pequeño que JPEG con la misma calidad; AVIF a menudo aún más pequeño. Un plugin puede convertir las imágenes existentes y ofrecer la versión más pequeña a los navegadores que la admitan. Compruebe si la conversión se realiza en su propio servidor o en un servicio externo.
• Lazy loading, pero no para todo. WordPress asigna automáticamente loading="lazy" a las imágenes, excepto a la primera imagen grande de la parte superior. Esa imagen suele ser el elemento LCP (lección 6.1): el fragmento de contenido más grande que el visitante ve primero. Si se carga de forma diferida, el navegador espera precisamente a cargarla y su LCP empeora. Por eso WordPress suele asignar a la candidata a LCP fetchpriority="high", para que el navegador la obtenga primero.

<img src="hero-1536x864.webp" width="1536" height="864"
     fetchpriority="high" alt="Taller con bicicletas en fila">
<img src="team-768x512.webp" width="768" height="512"
     loading="lazy" alt="El equipo frente a la tienda">

Un escollo habitual: algunos temas, creadores de páginas y plugins de optimización aplican también lazy loading a la primera imagen, o cargan la imagen grande como fondo mediante CSS (lo que se detecta más tarde). En PageSpeed Insights puede ver, en el apartado de LCP, qué elemento es y si se carga de forma diferida.

PHP: velocidad gratuita

Cada nueva versión principal de PHP es más rápida que la anterior, y los sitios WordPress se benefician de ello directamente, sin cambiar nada en su sitio. Además, las versiones antiguas dejan de recibir actualizaciones de seguridad (lección 8.4). Si actualiza, compruebe que sus plugins y su tema admiten la nueva versión, y hágalo preferiblemente primero en un entorno de pruebas (staging).

En la configuración de PHP, fíjese también en:

• OPcache: en la mayoría de los proveedores de alojamiento está activado por defecto. Una consecuencia: un archivo PHP modificado puede tardar un poco en que PHP use la nueva versión.
• memory_limit: si es demasiado bajo, provoca errores en páginas pesadas; muy alto no hace que su sitio sea más rápido.

Componentes externos y plugins pesados

Cada componente de otro proveedor supone una conexión adicional y un tiempo de espera extra: tipografías de un servicio externo, un vídeo incrustado, un widget de chat, códigos de medición, botones de redes sociales, un mapa. Preguntas por componente:

• ¿Es necesario? Un vídeo que casi nadie reproduce puede sustituirse por una imagen con un enlace.
• ¿Puede alojarse localmente? Las tipografías normalmente puede ponerlas en su propio servidor (con un plugin o mediante theme.json en un tema de bloques). Eso evita una conexión y es mejor para su privacidad (lección 9.3).
• ¿Puede cargarse más tarde? Un widget de chat o un vídeo puede cargarse solo tras un clic.

En el caso de los plugins, ayuda medir con X-Ray (en alojamiento con CloudLinux) o con un plugin como Query Monitor (actívelo temporalmente, visible solo para administradores). Estos muestran qué plugin consume más consultas a la base de datos o más tiempo.

Limpiar la base de datos

Una base de datos crece con cosas que no ve:

• Revisiones (lección 4.1): cada versión guardada de cada página. Limítelas con WP_POST_REVISIONS y elimine las antiguas.
• Comentarios de spam y de la papelera, y entradas en la papelera.
• Transients: datos temporales de plugins en wp_options, que a veces no se limpian.
• Autoload: las opciones de wp_options con autoload activado se cargan de una vez en cada petición. Los plugins que eliminó hace tiempo a veces dejan ahí grandes cantidades de datos. Salud del sitio (lección 5.4) avisa si los datos de autoload son muy grandes.
• Tablas de registro de plugins (estadísticas, registros de seguridad, registros de correo) que nunca se vacían.

Puede limpiar con un plugin de limpieza, con WP-CLI (wp transient delete --expired, wp post delete $(wp post list --post_type=revision --format=ids) --force), o con la función de optimización de phpMyAdmin para las propias tablas. Siempre primero una copia de seguridad. No elimine nada de lo que no sepa qué es.

Tareas programadas: WP-Cron

WordPress tiene tareas que deben ejecutarse en un momento determinado: publicar una entrada programada, comprobar actualizaciones, hacer que funcione un plugin de copias de seguridad. Esto se llama WP-Cron. Por defecto, WP-Cron no se ejecuta según un reloj, sino con cada visita: en cada petición de página, WordPress comprueba si hay una tarea pendiente. Dos inconvenientes:

• Con pocos visitantes, las tareas se ejecutan demasiado tarde (una entrada programada no aparece hasta la primera visita posterior).
• Con muchos visitantes, se comprueba con mucha frecuencia, y una tarea pesada puede ralentizar justo la página de un visitante.

Mejor: desactive WP-Cron en las visitas y deje que un verdadero cronjob del servidor lo ejecute cada cinco o diez minutos. En wp-config.php (encima de «deje de editar»):

define( 'DISABLE_WP_CRON', true );

Y en la pantalla de cron de su panel de alojamiento, una tarea cada 10 minutos:

*/10 * * * *  /usr/local/bin/php /home/usuario/domains/example.com/public_html/wp-cron.php >/dev/null 2>&1

La ruta hacia PHP y hacia su sitio varía según el proveedor de alojamiento; consulte el manual de su panel. O use WP-CLI: wp cron event run --due-now. Compruebe después en Salud del sitio que no haya tareas programadas atrasadas.

Heartbeat y la administración

El Escritorio de WordPress, mientras permanece abierto, se comunica con el servidor cada 15 a 60 segundos (el Heartbeat): para el autoguardado, para avisar de que otra persona está editando la misma entrada, y para las notificaciones. Si deja diez pestañas con la administración abiertas todo el día, son miles de peticiones. Cierre las pestañas que no utilice. Algunos plugins de caché pueden ralentizar el Heartbeat; desactivarlo por completo no es necesario y rompe el autoguardado.

Resumen

• Después de la caché de página: imágenes, versión de PHP, componentes externos y plugins, base de datos, cron. Mida antes y después, un paso a la vez.
• Lazy loading para todo excepto la imagen grande de la parte superior; a esta conviene asignarle fetchpriority="high".
• Una versión más reciente de PHP es velocidad gratuita, siempre que sus plugins lo soporten.
• Limpie revisiones, transients, spam y datos de autoload grandes, siempre con una copia de seguridad.
• Configure WP-Cron con un cronjob real mediante DISABLE_WP_CRON y una tarea en su panel.

Cuestionario

Ejercicio

Ejercicio A6.3: Lazy loading y formatos en su página de inicio. Introduzca la dirección de su sitio. El programa leerá la página de inicio y examinará las imágenes: ¿carece la primera imagen grande de loading="lazy" (y preferiblemente tiene fetchpriority="high"), tienen lazy loading las imágenes situadas más abajo, y qué proporción de las imágenes está en WebP o AVIF?

Ejercicio D6.3: Antes y después. Mida una página de su sitio tres veces en PageSpeed Insights (móvil) y anote el LCP intermedio, el INP (o el valor de laboratorio Total Blocking Time si no hay datos de campo), el CLS y el TTFB del ejercicio A6.1. A continuación, aplique una mejora de esta lección (imágenes, versión de PHP, eliminar un componente externo, limpiar la base de datos o un cron real). Mida de nuevo tres veces y anote los nuevos valores. Describa qué ha hecho y si la diferencia es mayor que la variación habitual entre mediciones.

Para saber más

Estos artículos describen los pasos en los paneles de WebOké; en otros paneles funcionan de forma similar.

• Manual de DirectAdmin 14.1: Elegir la versión de PHP (Select PHP version)
• Manual de DirectAdmin 12.7: Cómo comprobar, reparar y optimizar una base de datos
• Manual de DirectAdmin 15.1: Trabajo Cron: ejecutar tareas automáticamente
• Crear una tarea cron (y qué hacer si no se ejecuta)
• Manual de DirectAdmin 17.4: X-Ray: detectar páginas lentas
• Conectar WP-Cron al cron del sistema (developer.wordpress.org, en inglés): https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler/
• Lazy loading y LCP (web.dev, en inglés): https://web.dev/articles/lcp-lazy-loading