Para mejorar los Core Web Vitals de WordPress, mide plantillas representativas, identifica la etapa lenta y modifica el comportamiento responsable del alojamiento, tema o plugin. Empieza por páginas públicas como visitante sin sesión y continúa con las interacciones importantes. Un plugin de caché puede reducir la espera del HTML, pero no corrige todas las imágenes pesadas, los diseños inestables ni los manejadores de clic lentos.
Las condiciones de funcionamiento también cambian. Una publicación con caché, una zona de miembros y el pago de WooCommerce necesitan reglas distintas. Documenta esas diferencias antes de aplicar una optimización a toda la instalación.
Establece una referencia por plantilla y estado del visitante
Selecciona la portada, un artículo típico, un archivo, una página de destino y, si corresponde, un producto y el carrito. Incluye una página con una galería grande o un componente interactivo. Una prueba satisfactoria de la portada no demuestra que el resto del sitio funcione igual.
Utiliza los datos reales disponibles para identificar plantillas y dispositivos afectados. Después reproduce el problema con PageSpeed Insights y grabaciones del navegador. La introducción a Core Web Vitals explica las diferencias entre LCP, INP y CLS. La ausencia de datos de campo es una falta de información, no un cero ni un aprobado.
Anota las versiones de WordPress, PHP, tema y plugins relevantes junto a la fecha. Indica si hay sesión iniciada, carrito, consentimiento activo y acierto en la caché de página. Mantén constantes el tamaño de pantalla, la red y la secuencia al comparar cambios.
Prepara una copia de pruebas y un procedimiento de recuperación antes de editar el tema o cambiar PHP. Utiliza contenido representativo sin exponer datos de clientes. El entorno de pruebas puede tener otro alojamiento o caché: úsalo para compatibilidad y confirma el rendimiento en la configuración publicada después de su aprobación.
Investiga el tiempo del servidor antes de modificar la interfaz
Si el navegador espera demasiado al documento, examina el recorrido del servidor. Compara un acierto de caché, la primera solicitud tras vaciarla y una página deliberadamente excluida. Un fallo de caché lento sigue importando aunque las visitas repetidas sean rápidas. Revisa ejecución PHP, consultas, llamadas HTTP externas y competencia por recursos con el proveedor o desarrollador.
En la consulta del 17 de octubre de 2026, los requisitos oficiales de WordPress recomendaban PHP 8.3 o posterior, MariaDB 10.11 o posterior o MySQL 8.0 o posterior, y HTTPS. Eso no significa que cualquier plugin antiguo admita cualquier PHP nuevo. Confirma compatibilidad, prueba actualizaciones y utiliza una rama de PHP con soporte adecuada a la instalación.
Consulta al alojamiento sobre saturación de procesos PHP, caché de código de operación, límites de memoria y diagnóstico de solicitudes lentas. Más procesos no siempre mejoran el resultado: necesitan CPU y memoria. Una llamada externa en cada solicitud puede requerir caché o rediseño, no una tarifa superior.
Evita convertir la limpieza de base de datos en borrado indiscriminado. Identifica las consultas caras y el plugin propietario de los datos. Haz una copia antes de retirar registros obsoletos, conserva el historial necesario y comprueba que el trabajo no reaparece en la siguiente solicitud. Si el documento sigue siendo el cuello de botella, consulta la guía de tiempo de respuesta del servidor.
Distingue las capas de caché y sus excepciones
La caché de objetos predeterminada de WordPress dura una solicitud. Para conservar objetos entre solicitudes necesitas una integración y un servicio compatibles. Reutilizar datos no equivale a servir una página HTML guardada: decide sobre cada capa por separado.
Esta comparación ayuda a asignar una función a cada nivel.
| Capa | Trabajo que puede evitar | Comprobaciones independientes |
|---|---|---|
| Caché de página completa | Reconstrucción del HTML apto | Sesiones, personalización y carrito |
| Caché persistente de objetos | Recuperación o cálculo repetidos | Invalidación, disponibilidad y memoria |
| Caché de código de operación PHP | Recompilación en cada ejecución | Configuración y actualización del código |
| Caché de recursos del navegador | Descarga de archivos sin cambios | URLs versionadas e invalidación |
| CDN o caché perimetral | Entrega repetida desde el origen | Claves, cookies, purgas y contenido privado |
Asigna un responsable a cada capa. Dos plugins que reescriben scripts, generan CSS crítico o sustituyen URLs de imágenes dificultan el diagnóstico. Revisa la caché existente del proveedor antes de añadir otra. Que una opción esté activada no demuestra que la respuesta pública pueda almacenarse ni que se esté usando.
Comprueba cabeceras y solicitudes repetidas sin iniciar sesión. Tras editar contenido, verifica que la página pública se actualiza. Prueba idioma, moneda, contenido según dispositivo y consentimiento. Si cambian la respuesta, define variaciones o exclusiones seguras en lugar de suponer que la caché comprende todos los plugins.
No sirvas el carrito o la cuenta de una persona a otra mediante caché compartida. WooCommerce identifica Carrito, Finalizar compra y Mi cuenta como páginas dinámicas que deben excluirse de una caché de página incompatible. Revisa también las rutas personalizadas y el comportamiento real de las sesiones.
Audita el comportamiento de temas y plugins, no su cantidad
Enumera qué función aporta cada plugin y dónde se necesita. Un formulario presente en Contacto requiere una investigación distinta de un buscador utilizado en todas las páginas. La cantidad de plugins no revela el coste de consultas, HTML, servicios externos ni ejecución JavaScript.
En pruebas, desactiva un componente no esencial, vacía las cachés pertinentes y repite el escenario. Registra qué desaparece y qué mejora. Observa tanto servidor como navegador. Un plugin puede ralentizar solicitudes sin caché sin añadir archivos visibles, o incorporar un widget sin modificar apenas el tiempo PHP.
Si la página sigue siendo pesada, prueba un tema más sencillo con contenido representativo. Una demostración vacía no equivale a un artículo con navegación, traducciones, anuncios y galerías. Compara funciones útiles en condiciones semejantes; la puntuación de una tienda de temas no predice tu instalación.
Los temas de bloques y el editor de bloques no garantizan una página ligera. Consultas repetidas, estructuras anidadas, galerías y extensiones interactivas siguen generando trabajo. Examina el resultado final. Simplifica patrones que repiten información y comprueba si componentes no utilizados todavía cargan estilos o scripts compartidos.
Incluye las decisiones editoriales. Sustituir un carrusel decorativo por una imagen útil puede resultar más mantenible que corregir indefinidamente su JavaScript. Conserva información y accesibilidad al retirar comportamientos que no ayudan al lector.
Aprovecha el marcado de imágenes de WordPress y comprueba el resultado
Las funciones de adjuntos pueden generar dimensiones y candidatos responsive a partir de los metadatos. Utiliza un tamaño registrado apropiado en lugar del original completo para cada miniatura. Cuando el tema cambie los tamaños, comprueba los archivos antiguos: quizá necesiten regeneración, con su correspondiente coste de almacenamiento y procesamiento.
Este fragmento muestra la imagen destacada mediante la API de adjuntos. Debe estar en una plantilla PHP de WordPress con una entrada actual disponible.
<?php
$image_id = get_post_thumbnail_id();
if ( $image_id ) {
echo wp_get_attachment_image(
$image_id,
'large',
false,
array( 'class' => 'article-featured-image' )
);
}
?>Inspecciona el HTML final, no solo este fragmento. El tema o un plugin puede modificar srcset, sizes, atributos de carga o dimensiones. Compara la imagen elegida por el navegador con su espacio en móvil y escritorio. La guía de optimización de imágenes explica el efecto del tamaño visible y la densidad de píxeles.
WordPress admite WebP desde 5.8 y AVIF desde 6.5 cuando la biblioteca de imágenes del servidor es compatible. Eso no convierte automáticamente todos los JPEG antiguos. Comprueba formato entregado, alternativas y tamaños generados antes de contratar o activar otro servicio de procesamiento.
La lógica de carga ha evolucionado, incluida la coordinación de carga diferida y prioridad incorporada en 6.3. No todas las imágenes deben usar carga diferida. Identifica la imagen LCP real, asegúrate de que se descubra pronto y verifica que ningún plugin le añada loading="lazy". Marcar todas como prioritarias tampoco permite priorizar de forma útil.
Reduce recursos bloqueantes sin romper dependencias
Identifica la hoja de estilos o el script que retrasa el contenido. Averigua quién lo añade antes de eliminarlo. Un archivo de formularios puede servir también a una caja del pie, una ventana modal o una plantilla traducida. Prueba esos estados al limitar su carga a determinadas páginas.
Para scripts propios, utiliza la API de encolado de WordPress en lugar de reescribir etiquetas con filtros generales de texto. WordPress 6.3 incorporó strategy para defer y async. Declara correctamente las dependencias: WordPress considera ese árbol al elegir una estrategia compatible.
Este ejemplo pertenece al functions.php de un tema hijo; el archivo al que apunta debe existir en ese tema.
<?php
add_action( 'wp_enqueue_scripts', function () {
wp_enqueue_script(
'site-navigation',
get_stylesheet_directory_uri() . '/assets/navigation.js',
array(),
'1.0.0',
array( 'strategy' => 'defer', 'in_footer' => true )
);
} );No convierte todos los scripts de plugins en diferidos. Enseña a declarar uno propio sin dependencias registradas. Si el tuyo utiliza otra biblioteca, añade su identificador y prueba el orden de inicialización. Mantén la funcionalidad durante la carga y no retrases la navegación esencial hasta que alguien pulse un botón inactivo.
Utiliza CSS crítico o eliminación de recursos solo después de revisar el resultado generado. Prueba menús, buscador, mensajes de validación, consentimiento y contenido dinámico. El CSS que no se usa durante una navegación puede ser necesario después. Una captura correcta no demuestra que toda la interfaz siga funcionando.
Mantén estables las fuentes y el diseño
Inventaría familias tipográficas, pesos y conjuntos de caracteres solicitados. Elimina variantes sin uso y familias redundantes. Si alojas fuentes localmente, comprueba licencias y conserva los caracteres de todos los idiomas. Un subconjunto latino no sirve correctamente contenido hebreo o coreano.
Examina el texto de sustitución antes de llegar la fuente elegida. Compara saltos de línea, ancho de botones y altura de títulos. Una opción de visualización puede mantener el texto visible, pero la sustitución aún puede desplazarlo si cambian las métricas. Reserva espacio para publicidad, medios y avisos, y evita insertar contenido encima de la lectura.
Prueba cabeceras fijas y menús con ampliación y pantallas realistas. Un diseño estable en una captura de escritorio puede moverse cuando el texto se divide en un teléfono. Corrige dimensiones o flujo del componente en lugar de ocultar el síntoma durante la prueba.
Crea una matriz de pruebas específica para WooCommerce
Prueba productos simples y variables, filtros, minicarrito, Carrito y Finalizar compra. Incluye añadir productos, cambiar cantidades, introducir cupones y seleccionar pago en el entorno adecuado. Mide después de la carga visual: los scripts de variaciones pueden hacer lenta una compra aunque la presentación inicial sea rápida.
Evita consejos generales desactualizados sobre fragmentos del carrito. Desde WooCommerce 7.8, wc-cart-fragments no se encola por defecto en todas las rutas. Puede aparecer cuando se muestra el widget de carrito, otro script lo declara como dependencia o el código lo carga expresamente. El bloque Minicarrito utiliza otro enfoque y no emplea esa API.
Comprueba la implementación antes de cambiarla. Desactivar el script antiguo sin entender el widget puede dejar la cesta desactualizada. Migrar al bloque exige verificar compatibilidad y estilos, especialmente con acciones personalizadas de añadir productos. Un ahorro teórico no compensa mostrar un estado incorrecto del pedido.
Las galerías necesitan reglas propias. Carga pronto la primera imagen visible, reserva sus dimensiones y evita inicializar inmediatamente todos los videos o ampliaciones. Conserva los medios alternativos al seleccionarlos. Comprueba que las variaciones mantengan sincronizadas imagen, precio y disponibilidad.
Convierte la mejora en una rutina de publicación
Registra cada cambio: plantilla, causa sospechada, ajuste exacto, reversión y mediciones. Utiliza la lista de comprobación de rendimiento y conserva las trazas que explican la decisión.
Después de actualizar, repite los recorridos con caché fría y caliente. Comprueba solicitudes fallidas, errores JavaScript, contenido obsoleto y formularios antes de interpretar una mejor puntuación. Observa datos reales por dispositivo y plantilla para que una página mejorada no oculte otra que empeoró.
Revisa plugins nuevos y cambios importantes de tema antes de publicarlos; actualiza el inventario cuando cambien las funciones del negocio. Las guías de plataformas separan particularidades del sistema y problemas comunes del navegador. Para el siguiente cambio, elige un cuello de botella medido, define qué debe seguir funcionando y verifica ambas cosas juntas.
