Velocidad de WordPress: medir una página y corregir la causa

Elige una página representativa y un recorrido

Empieza por una entrada que contenga imágenes y las funciones reales del sitio. Anota URL, dispositivo o perfil de prueba, fecha y si había una sesión iniciada. Una portada vacía, una caché caliente y una visita de un lector nuevo pueden mostrar comportamientos distintos.

Conserva el resultado de la herramienta utilizada y el recorrido que probaste. Si la petición falla por cuota o conexión, no la conviertas en una puntuación. Tampoco atribuyas a un plugin todo el retraso de una medición aislada sin identificar qué estaba haciendo la página.

Distingue qué parte tarda

El tiempo de respuesta del servidor describe una parte del proceso. Después llegan HTML, estilos, imágenes, fuentes y scripts. LCP se relaciona con la aparición del elemento principal más grande; INP con la respuesta a interacciones y CLS con desplazamientos inesperados del diseño. Son señales distintas, no un único temporizador.

Los datos recogidos de visitas reales y los ensayos de laboratorio también tienen alcances diferentes. Una prueba controlada ayuda a investigar una causa; no describe necesariamente todas las conexiones o dispositivos de tus lectores. Conserva esa diferencia al comparar informes.

Investiga imágenes y elemento principal

Comprueba las dimensiones que necesita el diseño y las del archivo enviado. Una imagen mucho mayor que su espacio visible puede transferir datos innecesarios. Prepara una versión adecuada y compara peso y calidad sin degradar el contenido que el lector necesita ver.

Identifica la imagen o el bloque que determina el LCP antes de cambiar la carga. Retrasar indiscriminadamente todas las imágenes puede perjudicar al elemento principal. Reserva dimensiones o una proporción adecuada para evitar que la llegada de una imagen desplace el texto. Revisa también qué sucede con pies de imagen y tablas.

Examina las funciones que añaden trabajo

Haz una relación de scripts, fuentes, vídeos, herramientas y servicios externos utilizados por la página. Pregunta qué función cumple cada pieza y qué páginas la necesitan. No elimines una función necesaria sólo para mejorar un número en un ensayo que ya no representa el sitio.

Si hay scripts de anuncios o consentimiento, diferencia su comportamiento del de la plantilla. No provoques clics o recargas repetidas para forzar anuncios durante una prueba. Cualquier cambio de monetización necesita respetar las decisiones y requisitos del proyecto, además de su impacto en lectura.

Utiliza caché con atención al contenido variable

Una caché puede reducir trabajo repetido, pero no debe entregar datos de otra sesión ni formularios con credenciales de acción caducadas. Identifica qué páginas son públicas y estables y cuáles incluyen datos personalizados o tokens. No apliques una duración universal a todo el HTML sin revisar esas diferencias.

Después de un cambio, comprueba que el visitante recibe la versión correcta. Un archivo nuevo en el servidor no demuestra que todas las capas de caché ya lo estén sirviendo. Conserva las respuestas que permitan distinguir una versión antigua de un fallo de publicación.

Cambia una causa y compara

Si el problema está en una imagen, modifica esa imagen y repite el recorrido comparable. Si la causa parece estar en el servidor, conserva la observación y revisa sus recursos con el proveedor o responsable. No mezcles una migración, un tema nuevo y diez plugins en una sola prueba si después necesitas explicar qué mejoró.

Registra resultado, cambios y límites. La lista de mantenimiento puede incluir una medición pendiente sin declarar aprobado el rendimiento. La elección de tema y la de alojamiento deben apoyarse en páginas reales, no en promesas de una demo.

Documentación consultada

• Optimizar LCP
• Core Web Vitals