Cómo realizar una auditoría WPO efectiva para tu proyecto

El rendimiento web es uno de los pilares fundamentales para garantizar una buena experiencia de usuario, mejorar el posicionamiento en buscadores y optimizar la conversión. Sin embargo, antes de poder aplicar mejoras, es imprescindible realizar una auditoría WPO completa que nos permita entender dónde están los problemas reales.

En este artículo no vamos a hablar de cómo optimizar un sitio web WordPress, sino de cómo auditarlo eficazmente. Nuestro objetivo es identificar cuellos de botella, recopilar datos fiables y crear un punto de partida que sirva de base para futuras decisiones técnicas.

Una auditoría WPO consiste en analizar todas las capas que intervienen en el rendimiento de un sitio: desde el DNS y el servidor hasta la base de datos, el back-end de WordPress y el front-end. Cada uno de estos niveles puede esconder problemas que, aislados, no parecen graves, pero combinados, afectan seriamente a la experiencia del usuario.

Este proceso va dirigido principalmente a perfiles técnicos: desarrolladores, sysadmins, responsables de mantenimiento de webs WordPress, agencias digitales y cualquier persona encargada de garantizar el buen funcionamiento de un sitio web. Pero también puede ser útil para consultores SEO o especialistas en marketing que deseen detectar problemas de velocidad antes de contactar con un desarrollador.

A lo largo del artículo veremos:

• Cómo estructurar una auditoría completa por capas
• Qué herramientas utilizar para cada parte
• Cuáles son las métricas clave que debemos recoger
• Y, sobre todo, una checklist completa para no dejarnos nada

Importante: no entraremos en la parte de cómo optimizar cada elemento, sino en qué debemos medir, detectar y documentar para decidir si es necesario intervenir.

Las herramientas que se utilizan en este tipo de auditorías incluyen navegadores (Chrome y Firefox DevTools), servicios online (PageSpeed, GTmetrix, WebPageTest), plugins como Query Monitor o Health Check, y herramientas de línea de comandos como WP-CLI. Cada una cumple un papel específico en la recogida de datos.

Vamos a ver paso a paso cómo hacer una auditoría WPO efectiva y profesional.

1. Enfoque y metodología de auditoría
2. Checklist de auditoría WPO por capas
3. Recogida de datos y documentación
4. Herramientas para auditoría
5. Conclusión

Enfoque y metodología de auditoría

¿Cuándo hacer una auditoría WPO?

Una auditoría WPO no debería ser algo que se realice únicamente cuando el sitio ya es lento. Lo ideal es incluir este análisis como parte del mantenimiento preventivo del sitio web. Algunos momentos clave donde conviene realizarla:

• Antes o después de un rediseño completo: para comprobar si la nueva versión del sitio mejora o empeora el rendimiento.
• Tras una migración de hosting o dominio: para validar tiempos de carga y configuración del nuevo entorno.
• Cuando hay quejas de lentitud o caídas: tanto de usuarios como del equipo editorial.
• Después de instalar nuevos plugins pesados: por ejemplo, constructores visuales, WooCommerce, LMS, etc.
• De forma periódica: como parte de un servicio de mantenimiento trimestral o anual.

Incluir auditorías regulares permite detectar regresiones de rendimiento antes de que afecten negativamente al SEO o a la experiencia de usuario.

Preparación y contexto

Antes de comenzar con la auditoría, hay que definir bien el contexto en el que se va a realizar y asegurarse de tener todo preparado:

• ¿Producción o entorno de staging? Lo ideal es auditar en producción para tener datos reales, pero puede combinarse con un entorno de staging para pruebas más invasivas.
• Tipo de sitio: no es lo mismo una web corporativa sencilla que un WooCommerce o un multisite. Cada tipo requiere atención especial a ciertas capas (productos, filtros, búsquedas, etc.).
• Dispositivos y conexiones simuladas: los test deben incluir móviles, conexiones lentas y ubicaciones geográficas relevantes para el negocio.
• Accesos técnicos: necesitarás acceso al back-end, al servidor si es posible, y permisos suficientes para instalar herramientas de análisis.
• Herramientas de apoyo: tener a mano Chrome DevTools, PageSpeed Insights, WP-CLI, plugins como Query Monitor, etc.

Tener estos puntos claros antes de empezar nos ahorra tiempo y nos permite una auditoría más precisa y completa.

Definición de las métricas clave

No se puede auditar correctamente lo que no se mide (gran axioma del WPO). Por eso, uno de los pasos clave antes de comenzar la auditoría es definir qué métricas vamos a registrar y con qué herramientas:

Métricas recomendadas:

• TTFB (Time to First Byte): mide el tiempo que tarda el servidor en empezar a responder. Clave para evaluar el rendimiento back-end.
• FCP (First Contentful Paint): mide cuándo se muestra el primer contenido visible.
• LCP (Largest Contentful Paint): cuándo se muestra el contenido más grande visible en el viewport.
• CLS (Cumulative Layout Shift): mide los cambios de diseño inesperados durante la carga.
• TTI (Time to Interactive): cuándo el sitio se vuelve usable por completo.
• Total Blocking Time (TBT): mide los bloqueos entre FCP y TTI.

Herramientas para recogerlas:

• Chrome DevTools + Lighthouse (en modo incógnito y sin extensiones)
• Lighthouse CLI (automatizar recogida de datos)
• WebPageTest.org (tests más detallados y realistas)
• PageSpeed Insights (resumen con datos de campo + test sintético)
• GTmetrix (para usuarios avanzados y para realizar comparativas)
• Query Monitor (para métricas del back-end en WordPress)

Es importante tomar capturas de los resultados, guardar reportes y dejar constancia de la línea base para comparar en el futuro tras aplicar mejoras.

Checklist de auditoría WPO por capas

DNS y red

¿Qué auditar?

El DNS y la red son el primer eslabón de la cadena en la carga de una web. Aunque parezcan factores externos, pueden marcar una diferencia significativa, especialmente en sitios internacionales.

Checklist de auditoría:

• Tiempo de resolución DNS:
  • Utiliza herramientas como DNSPerf o dig desde terminal para comprobar la velocidad de respuesta de los servidores DNS asociados al dominio.
  • Medir tanto desde tu ubicación como desde localizaciones internacionales clave si el sitio tiene alcance global.
• Latencia entre cliente y servidor:
  • Se puede medir con ping o servicios como WebPageTest.org
  • Si la latencia supera los 100 ms de forma constante, puede ser recomendable usar un CDN.
• Uso de CDN (Content Delivery Network):
  • Revisa si el sitio ya está detrás de una CDN como Cloudflare, Bunny, etc. Puedes detectarlo observando cabeceras HTTP (cf-cache-status, x-cdn o similares).
  • Verifica si las respuestas están siendo servidas desde el edge o directamente desde el origen.
• Número de redirecciones:
  • Asegúrate de que no hay múltiples redirecciones desde http a https o de www a non-www (o viceversa).
  • Puedes usar herramientas como Redirect-checker.org o las DevTools del navegador.
• Revisión de registros DNS:
  • Comprueba que los registros A/AAAA, CNAME y TXT estén correctamente configurados, especialmente si se usa CDN o proxy.

Herramientas sugeridas:

• dig y ping desde terminal
• DNSPerf
• WebPageTest.org
• Redirect-checker.org
• Cabeceras HTTP (DevTools > pestaña Network)

Hosting y servidor

¿Qué auditar?

El entorno del alojamiento es responsable directo del rendimiento base del sitio. Una mala configuración o un proveedor inadecuado pueden arruinar cualquier intento de optimización en otras capas. Si nuestro hosting para WordPress es WordPress.com ya tenemos muchas bazas ganadas con una configuración altamente optimizada.

Checklist de auditoría:

• Tipo de alojamiento:
  • ¿Es un hosting compartido, VPS, dedicado o cloud?
  • ¿Está el sitio en una plataforma especializada en WordPress?
  • ¿El proveedor tiene limitaciones de CPU, RAM o procesos simultáneos?
• Recursos asignados:
  • CPU, RAM, disco, IOPS, procesos simultáneos.
  • ¿Están cerca de los límites? Esto puede generar cuellos de botella.
  • Lo consultamos desde el panel del hosting o vía herramientas como top, htop o monitorización externa.
• Versión de PHP:
  • ¿Está usando una versión moderna (8.1 o superior)?
  • ¿Hay soporte activo por parte del proveedor?
  • Lo verificamos con phpinfo(), WP-CLI (wp --info) o plugins como Health Check.
• Motor web:
  • ¿Apache, Nginx, LiteSpeed, OpenLiteSpeed…?
  • Cada motor tiene características distintas, sobre todo en gestión de caché y headers.
• Estado de los headers HTTP:
  • ¿Se está aplicando compresión gzip o Brotli?
  • ¿Keep-Alive está habilitado?
  • ¿Los headers Cache-Control, Expires y ETag están bien configurados?
  • Podemos revisar esto desde Chrome DevTools > pestaña Network > columna “Response headers”.
• Soporte de HTTP/2 o HTTP/3:
  • ¿Está activo? Mejora la eficiencia en conexiones paralelas.
  • Lo verificamos con tools.keycdn.com/http2-test o desde DevTools (en la columna “Protocol”).
• Tiempo medio de respuesta del servidor:
  • Lo vemos en Lighthouse, WebPageTest o herramientas de monitorización como New Relic o Pingdom.

Herramientas sugeridas:

• WP-CLI (wp --info, wp doctor)
• Health Check plugin
• Chrome DevTools (Network > Response Headers)
• keycdn HTTP/2 Test
• Panel de control del hosting
• Monitorización externa: UptimeRobot, HetrixTools, New Relic

Back-end de WordPress

¿Qué auditar?

El núcleo de WordPress puede volverse ineficiente si no se gestiona correctamente. Aquí buscamos detectar cuellos de botella en la ejecución del código PHP, plugins, temas y el comportamiento del sistema desde el lado del servidor.

Checklist de auditoría:

• Plugins activos:
  • ¿Cuántos plugins están activos?
  • ¿Cuáles generan más consultas o consumo de recursos?
  • Usamos Query Monitor para ver qué plugins están generando más carga o ralentizando el back-end.
  • Cuidado con plugins que duplican funcionalidades o que cargan scripts innecesarios.
• Tema activo:
  • Revisamos si el tema genera muchas plantillas condicionales o carga múltiples estilos/scripts.
  • Comprobamos si se están usando funciones pesadas en functions.php o en los hooks globales (init, wp_loaded, etc.).
• Tiempos de ejecución del back-end:
  • Mide con Query Monitor cuánto tarda cada solicitud en completarse.
  • Verifica si hay diferencias entre tipos de contenido o plantillas.
  • Si se dispone de New Relic u otra herramienta de APM, las usamos para ver el tiempo por transacción y función.
• Heartbeat API:
  • Detectar si está activa en front-end o back-end innecesariamente.
  • Puede generar muchas solicitudes AJAX por minuto si no se controla.
  • Revisar desde DevTools (ver peticiones a admin-ajax.php) o con plugins como Heartbeat Control.
• Hooks pesados o consultas personalizadas:
  • Usar Query Monitor para ver qué acciones o filtros se ejecutan en cada carga.
  • Identificar funciones personalizadas que consultan la base de datos en cada carga.
  • Buscar acciones en init, template_redirect, wp_footer y similares.

Herramientas sugeridas:

• Plugin Query Monitor (imprescindible)
• Debug Bar + Debug Bar Actions and Filters Addon
• Health Check
• DevTools > pestaña Network (para detectar heartbeat)
• New Relic (si el hosting lo permite)

Base de datos

¿Qué auditar?

La base de datos es un componente crítico del rendimiento de WordPress, especialmente cuando crece con el tiempo. Consultas mal diseñadas, tablas hinchadas o configuraciones poco eficientes pueden afectar seriamente la velocidad.

Checklist de auditoría:

• Tamaño total y número de tablas:
  • ¿Cuántas tablas tiene la base de datos?
  • ¿Existen tablas de plugins que ya no están activos?
  • Usar WP-CLI (wp db size, wp db tables) o desde phpMyAdmin para visualizarlo.
• Tamaño de la tabla wp_options:
  • ¿Cuánto pesa la tabla wp_options?
  • ¿Hay muchas entradas con autoload = 'yes'?
  • Una tabla wp_options muy grande o con demasiados autoloads puede ralentizar cada carga de página.
• Consultas lentas detectadas:
  • Habilita el log de consultas lentas en el servidor o usa plugins como Query Monitor o Debug Bar para identificarlas.
  • Identifica si hay peticiones repetidas, mal indexadas o costosas.
• Transients, revisiones y datos residuales:
  • ¿Existen muchos transients expirados o innecesarios?
  • ¿El número de revisiones por post es excesivo?
  • ¿Hay comentarios de spam, entradas en la papelera, entradas huérfanas de plugins desactivados?
• Índices y optimización de tablas:
  • Revisa si las tablas están optimizadas y si tienen índices adecuados en columnas que se consultan con frecuencia.
  • Usa wp db optimize o herramientas del panel del hosting.

Herramientas sugeridas:

• WP-CLI: wp db size --human-readable, wp db tables --all-tables, wp option list --autoload=on, wp transient list
• Query Monitor (para ver consultas en tiempo real)
• phpMyAdmin o Adminer
• Logs del servidor (consulta con el hosting)
• Plugins como WP-Optimize o Advanced Database Cleaner (solo para análisis, no ejecutar todavía)

Medios y archivos estáticos

¿Qué auditar?

Los archivos multimedia (imágenes, vídeos, SVG, iconos, etc.) y los recursos estáticos (fuentes, scripts de terceros) impactan de forma directa en el tiempo de carga, especialmente en dispositivos móviles o conexiones lentas.

Checklist de auditoría:

• Tamaño medio de las imágenes:
  • ¿Cuánto pesan las imágenes que se cargan en la portada o páginas clave?
  • Puedes verlo desde DevTools > pestaña Network (filtro img) o con WebPageTest.org (Waterfall View).
• Formatos de imagen usados:
  • ¿Se están sirviendo imágenes modernas como WebP o AVIF?
  • ¿Hay PNG o JPEG que podrían convertirse a WebP o AVIF sin pérdida visible?
• Lazy Load de imágenes y vídeos:
  • ¿Las imágenes que no están en el viewport se cargan con loading="lazy"?
  • ¿Los vídeos embebidos de YouTube, Vimeo, etc., se cargan directamente o mediante placeholder/lazy iframe?
  • Revisa el HTML con DevTools o inspecciona el código fuente.
• Iconos y SVGs:
  • ¿Están usando icon fonts (como FontAwesome) o SVGs inline?
  • Los SVGs inline suelen ser más ligeros y accesibles, además de no requerir peticiones externas.
• Número de recursos externos en la carga inicial:
  • ¿Se cargan fuentes desde Google Fonts, iconos de redes sociales, scripts de terceros?
  • Cuantos más dominios externos haya, más búsquedas DNS y riesgo de cuellos de botella.
• Peso total de recursos en la página de inicio:
  • Suma del total de KB/MB que se descargan al visitar la portada.
  • Revisar en DevTools (barra inferior > Total transferred) o WebPageTest.

Herramientas sugeridas:

• Chrome DevTools > Network
• WebPageTest.org (detalle de imágenes, waterfall)
• Plugins como Enable Media Replace y WP CLI wp media image-size para ver los tamaños de imagen registrados (para análisis, no para actuar aún)
• Lighthouse (sección «Medios» del informe)
• find en terminal si tienes acceso SSH (find wp-content/uploads -type f -size +1M)

Front-end: CSS, JS y HTML

¿Qué auditar?

El front-end es la capa visible del sitio y una de las más críticas desde la perspectiva del usuario final. Aquí se evalúa todo lo que influye en el tiempo de renderizado y la estabilidad visual: hojas de estilo, scripts, HTML, fuentes externas, etc.

Aunque muchas decisiones de front-end dependen del tema o el maquetador utilizado, en esta etapa de la auditoría buscamos identificar archivos innecesarios, peticiones excesivas, scripts que bloquean la carga y problemas de estructura que afectan a la experiencia de usuario.

Checklist de auditoría:

• Número total de peticiones HTTP en la carga inicial:
  • Evalúa cuántas peticiones realiza la página sin interacción.
  • Una carga inicial por encima de 100 peticiones suele indicar exceso de archivos (imágenes, fuentes, scripts externos).
  • Revisa desde DevTools (pestaña Network) o WebPageTest (Waterfall View).
• Tamaño total de CSS y JS en portada:
  • ¿Cuántos KB/MB ocupan los archivos CSS y JavaScript combinados?
  • ¿Hay archivos grandes que podrían dividirse?
  • Herramientas como GTmetrix o DevTools ofrecen el detalle del peso individual por archivo.
• Carga de scripts bloqueantes:
  • Identifica si hay archivos JavaScript o CSS que bloquean el renderizado (sin async o defer).
  • Lighthouse y WebPageTest lo marcan claramente como oportunidades de mejora.
  • También puedes verlo en DevTools, pestaña «Performance».
• Orden y prioridad de recursos:
  • ¿Se están cargando primero los recursos críticos?
  • ¿Existen preload, prefetch o preconnect definidos para priorizar elementos clave?
  • Este tipo de análisis es útil para detectar cuellos de botella en el inicio de carga.
• Carga de fuentes externas:
  • ¿Cuántas fuentes externas (Google Fonts, Adobe Fonts, etc.) se están cargando?
  • ¿Están bien agrupadas o hay varias llamadas por separado?
  • Verifica desde DevTools > pestaña Network > filtro font.
• Cumulative Layout Shift (CLS):
  • Revisa si hay saltos de contenido visibles durante la carga, lo que genera una mala experiencia.
  • Lighthouse te da una puntuación de CLS y muestra qué elementos lo causan.
  • Suele deberse a imágenes sin tamaño definido, anuncios o fuentes que cambian tras cargar.
• HTML general y estructura:
  • ¿El HTML está limpio o contiene muchos comentarios, estilos inline o scripts innecesarios?
  • ¿Hay elementos duplicados, divs sin utilidad, comentarios de plugins o maquetadores visuales?
  • Puedes inspeccionar el código fuente o usar herramientas como HTMLHint.

Herramientas sugeridas:

• Chrome DevTools (pestañas Network, Performance y Coverage)
• Lighthouse (informe completo)
• GTmetrix (detalle por archivo)
• WebPageTest (Vista en cascada, optimizaciones y estabilidad visual)
• PageSpeed Insights
• Herramientas de inspección de HTML: HTMLHint, Validator.w3.org

Cachés y persistencia

¿Qué auditar?

La caché es uno de los componentes que más influyen en la velocidad de carga de un sitio WordPress. Afecta tanto al frontend como al backend y puede aplicarse a múltiples niveles: página completa, objetos, transients, navegador, CDN, base de datos, etc.

En esta sección se analiza si existe alguna capa de caché activa, cómo está configurada y si está funcionando correctamente. También se audita la persistencia de datos dinámicos y su impacto en el rendimiento general.

Checklist de auditoría:

• ¿Existe caché de página activa?
  • Verifica si hay un sistema de caché de página completa (HTML) como parte del stack del servidor, un plugin de WordPress o un CDN.
  • Revisa las cabeceras HTTP (x-cache, cf-cache-status, x-wp-cf-super-cache, etc.) para comprobar si la respuesta viene de caché.
  • También puedes comprobar el HTML generado (muchos plugins añaden un comentario al final del código fuente indicando si fue cacheado).
• Caché de navegador (client-side):
  • ¿Los recursos estáticos tienen cabeceras de expiración (Cache-Control, max-age)? ¿Están configuradas correctamente?
  • Evalúa esto desde DevTools, pestaña Network, columna «Size» o «Cache-Control».
  • Comprobar si los elementos sin caché pueden recargarse en cada visita, incluso si no han cambiado.
• Uso de object cache (persistente o no persistente):
  • ¿Está activa una caché de objetos como Redis o Memcached?
  • ¿Se está usando una capa de persistencia entre peticiones (no solo caché en memoria)?
  • Puedes detectarlo con plugins como Query Monitor o con WP-CLI (wp cache type en WordPress 6.1+).
• Estado del sistema de transients:
  • ¿Existen muchos transients caducados o innecesarios en la base de datos?
  • Puedes listar todos los existentes con WP-CLI (wp transient list) y verificar cuáles están en uso o han expirado.
  • La acumulación excesiva de transients puede inflar la base de datos y degradar el rendimiento.
• Caché del CDN (si aplica):
  • ¿Se están cacheando correctamente los recursos en la red de distribución?
  • ¿Existe diferencia notable de TTFB entre la primera carga y las siguientes?
  • Herramientas como WebPageTest permiten testear desde múltiples ubicaciones para comprobar el edge caching.
• Invalidación de caché y control de versiones:
  • ¿El sistema permite invalidar o purgar la caché fácilmente?
  • ¿Se están usando parámetros de versión (?ver=) para controlar la renovación de archivos modificados?
  • Analiza si los cambios recientes del sitio se reflejan de inmediato o si hay problemas de caché estancada.

Herramientas sugeridas:

• Chrome DevTools (cabeceras HTTP y pestaña Network)
• WP-CLI: wp cache type, wp transient list, wp option get para opciones relacionadas
• Query Monitor (para ver si hay object cache activo)
• WebPageTest (para comprobar si se sirve desde edge o desde origen)
• Plugin Site Health (estado de caché de objetos en WordPress 6.1+)
• Herramientas del proveedor de caché o CDN (paneles de control, logs, cabeceras personalizadas)

Recogida de datos y documentación

Una auditoría sin documentación clara es como hacer un diagnóstico y no compartir los resultados: pierde valor y dificulta la toma de decisiones. Por eso, en esta parte nos centramos en cómo recoger, organizar y presentar la información recopilada durante la auditoría WPO.

El objetivo no es solo tener datos sueltos, sino generar un informe útil, comprensible y accionable. Esto incluye dejar constancia de los problemas detectados, su nivel de gravedad, y establecer una línea base para poder comparar en el futuro tras aplicar mejoras.

Plantillas de informe

¿Cómo organizar la información?

Una buena práctica es utilizar una tabla o checklist estructurada por capas, como las que hemos visto en la parte previa de la checklist. Cada ítem debe incluir:

• Elemento evaluado (por ejemplo, «TTFB», «versión PHP», «autoloads en wp_options»…)
• Valor actual medido (por ejemplo, «TTFB: 50 ms», «PHP 7.4», «autoloads: 3750 entradas»)
• Observaciones (qué significa ese valor y si está dentro de lo esperado)
• Nivel de prioridad: puede usarse una escala de tres niveles:
  • Crítico o bloqueante (impacto alto en rendimiento o estabilidad)
  • Recomendable de corregir
  • Menor o informativo

También es útil incluir capturas de pantalla de herramientas clave como Lighthouse, WebPageTest o Query Monitor para respaldar los hallazgos y facilitar su comprensión.

Formato sugerido:

• Podemos usar Google Docs, Notion, Markdown o PDF.
• Si trabajas en equipo, Notion o Google Docs permiten comentarios colaborativos.
• En proyectos más técnicos o repetitivos, es útil convertir el informe en una plantilla reutilizable.

Ejemplo de tabla base:

Capa	Ítem auditado	Valor actual	Observación	Prioridad
Servidor	Versión de PHP	7.4	Sin soporte activo	Crítico
Base de datos	Autoloads en wp_options	5125 entradas	Alto número de opciones cargadas	Recomendable
Frontend	CLS (Cumulative Layout Shift)	0.27	Supera el umbral recomendado (<0.1)	Crítico
Caché	Cabeceras de recursos estáticos	No hay Cache-Control	Recursos no cacheables en navegador	Recomendable

Consideración adicional:

• Para clientes no técnicos, puedes preparar una versión reducida del informe con una lista priorizada de acciones necesarias y su impacto estimado, evitando tecnicismos.
• También puedes adjuntar una hoja Excel/CSV con los datos medidos por herramientas online para futuras comparaciones.

Comparación entre auditorías

Una auditoría es una fotografía del estado actual del sitio, pero su mayor utilidad está en poder comparar versiones anteriores y posteriores. Esto permite comprobar si las optimizaciones han funcionado y evitar regresiones.

¿Qué comparar?

• Métricas de rendimiento (TTFB, LCP, CLS, etc.) antes y después de los cambios.
• Número de consultas a base de datos, uso de memoria, tiempos de carga de scripts.
• Peso total de la página y número de peticiones.
• Evolución del tamaño de tablas de base de datos.

Cómo hacerlo:

• Guarda todos los reportes generados en PDF o Markdown antes de aplicar cambios.
• Incluye capturas de pantalla con fecha y hora.
• Si trabajas con WebPageTest, GTmetrix o Lighthouse, descarga los reportes o usa sus historiales si tienes cuenta.
• Puedes crear una hoja de cálculo para comparar los valores antiguos y nuevos de forma visual.

Sugerencia de campos comparativos:

Métrica	Auditoría inicial	Auditoría post-opt	Diferencia (%)
TTFB	630 ms	210 ms	-67 %
LCP	4.3 s	1.2 s	-72 %
CLS	0.27	0.04	-85 %
Peticiones totales	128	69	-46 %
Peso total de la página	3.9 MB	1.8 MB	-54 %

Esto permite justificar el impacto de las mejoras implementadas y demostrar el retorno del tiempo invertido en optimización, especialmente en entornos corporativos o de mantenimiento recurrente.

Herramientas para auditoría

Una auditoría WPO efectiva no depende de una sola herramienta, sino del uso combinado de varias fuentes que aporten datos complementarios. Cada capa de la web —desde el servidor hasta el navegador— requiere una aproximación distinta y herramientas específicas para poder analizarla a fondo.

En esta sección recopilamos las principales herramientas que podemos usar para auditar un sitio WordPress. Algunas son online, otras requieren instalación en el sitio, y otras son accesibles desde la línea de comandos. El criterio es que todas permiten recoger información precisa sin intervenir en el rendimiento del sitio (diagnóstico pasivo).

Herramientas online

Estas herramientas permiten analizar el comportamiento del sitio desde una perspectiva externa, simulando la experiencia de un usuario real. Son útiles para revisar rendimiento percibido, carga de recursos, tiempos y problemas generales de front-end.

Principales herramientas:

• Google PageSpeed Insights
  • Ofrece un informe simplificado con métricas web vitales, datos de campo (si están disponibles) y recomendaciones.
  • Muy útil para clientes, ya que muestra una puntuación general.
• Lighthouse (versión web o en navegador)
  • Proporciona un desglose técnico completo de métricas clave: TTFB, FCP, LCP, CLS, TTI, etc.
  • Puede ejecutarse desde Chrome DevTools o desde la web (PageSpeed Insights lo usa internamente).
  • Ideal para tests rápidos y para documentar un estado inicial.
• WebPageTest.org
  • Una de las herramientas más completas para auditoría avanzada.
  • Permite configurar ubicación, dispositivo, velocidad de conexión y navegador.
  • Muestra detalles como el Waterfall completo, número de redirecciones, CDN activo, primer byte, visualización progresiva y más.
  • Excelente para validar hipótesis de rendimiento back-end o comportamiento bajo carga.
• GTmetrix
  • Similar a PageSpeed + WebPageTest, pero con su propia puntuación y enfoque.
  • Muy visual y útil para comparar versiones de una web antes y después de aplicar cambios.
• tools.keycdn.com/http2-test
  • Para comprobar si el sitio está sirviendo contenido vía HTTP/2 o HTTP/3.
• Redirect-checker.org
  • Detecta redirecciones en cascada (por ejemplo, de http a https y luego a www).

Plugins y herramientas en el sitio

Estas herramientas permiten auditar el comportamiento interno de WordPress sin necesidad de acceso al servidor. Son ideales para identificar cuellos de botella en el back-end, plugins lentos o consultas mal optimizadas.

Principales herramientas:

• Query Monitor
  • Plugin imprescindible para desarrolladores y técnicos.
  • Muestra el tiempo de ejecución de cada petición, consultas SQL, hooks, scripts, llamadas AJAX, estado del object cache, transients, errores de PHP y más.
  • Muy útil para auditar el back-end, el comportamiento del tema y plugins concretos.
• Health Check & Troubleshooting
  • Plugin oficial del equipo de WordPress.org.
  • Ofrece un diagnóstico básico del entorno (versión PHP, estado del servidor, constantes activas, tamaño de la base de datos, etc.).
  • Permite activar el modo de prueba para desactivar todos los plugins sin afectar al sitio en producción (solo visible para el usuario conectado).
• Debug Bar + Add-ons
  • Amplía el sistema de depuración nativo de WordPress.
  • Muestra información de hooks, consultas, constantes, errores, uso de memoria y más.
• Heartbeat Control (opcional)
  • Para revisar si la API Heartbeat está activa de forma excesiva en frontend o back-end.
  • Útil cuando se sospecha que hay un exceso de peticiones AJAX.

Nota: estos plugins deben usarse con cuidado en producción. Aunque no modifican el comportamiento del sitio, consumen recursos extra al estar activos. Es recomendable instalarlos temporalmente y en horario de baja carga y después desinstalarlos.

WP-CLI y herramientas de terminal

Cuando se dispone de acceso por SSH al servidor, WP-CLI se convierte en una herramienta sumamente poderosa para auditar WordPress de forma rápida, precisa y sin necesidad de plugins. También permite exportar resultados y automatizar tareas de diagnóstico.

Comandos útiles:

• Información del sistema:
  • wp --info: versión de PHP, WP-CLI y entorno.
  • wp doctor check: si está disponible, ejecuta comprobaciones básicas de salud (los instalamos con wp package install wp-cli/doctor-command:@stable).
• Base de datos:
  • wp db size --human-readable: muestra el tamaño total de la base de datos.
  • wp db tables --all-tables-with-prefix: lista todas las tablas.
  • wp option list --autoload=on: lista todas las opciones autoload (muy útil para auditar wp_options).
  • wp transient list: muestra todos los transients activos.
• Usuarios y plugins:
  • wp plugin list: para revisar qué plugins están activos, desactualizados, etc.
  • wp user list: audita cantidad y tipo de usuarios activos (listar los administradores wp user list --role=administrator).
• Caché y cron:
  • wp cache type: (en WordPress 6.1+) muestra si hay object cache activo.
  • wp cron event list: para revisar el estado y frecuencia de las tareas programadas.
• Archivo de configuración y constantes:
  • Inspecciona wp-config.php para ver constantes como WP_DEBUG, DISABLE_WP_CRON, WP_MEMORY_LIMIT, etc.

Otras herramientas de terminal útiles:

• dig, ping, curl -I: para revisar DNS, latencia, headers HTTP.
• top, htop, vmstat, iostat: si se tiene acceso root o de sistema, para evaluar consumo de recursos en tiempo real.
• mysqlslowlog o equivalente: si el servidor lo permite, para detectar consultas lentas reales.

Consejo: puedes crear tus propios scripts para exportar automáticamente información relevante (por ejemplo, cada mes, generar un .json o .csv con el estado de rendimiento para monitoreo continuo).

Tabla resumen de herramientas por tipo de uso

Herramientas online:

Herramienta	¿Qué audita?	Observaciones útiles
PageSpeed Insights	Frontend, Web Vitals	Resumen sencillo, incluye datos de campo si hay tráfico
Lighthouse (web o navegador)	Frontend, JS/CSS, accesibilidad	Ideal para tests rápidos, buena visualización
WebPageTest	Frontend, red, TTFB, CDN	Muy configurable, análisis detallado, visualizaciones
GTmetrix	Frontend, assets, puntuación global	Similar a Lighthouse, permite comparativas históricas
Redirect-checker.org	Redirecciones HTTP	Detecta redirecciones en cascada
keycdn HTTP/2 Test	Protocolo HTTP usado	Verifica si el sitio usa HTTP/2 o HTTP/3

Plugins de WordPress:

Herramienta	¿Qué audita?	Observaciones útiles
Query Monitor	Backend, SQL, hooks, AJAX, object cache	Muy detallado, ideal para desarrolladores
Health Check & Troubleshooting	Configuración general del sitio	Muestra info básica + modo seguro para pruebas
Debug Bar + Add-ons	Debug PHP, hooks, constantes	Complemento ideal para desarrollo
Heartbeat Control	Peticiones AJAX automáticas	Útil para detectar o controlar uso excesivo del Heartbeat

Herramientas de terminal / WP Cli:

Herramienta	¿Qué audita?	Observaciones útiles
wp db size, wp db tables	Base de datos: tamaño y tablas	Requiere SSH o WP-CLI, muy rápido y preciso
wp option list --autoload=on	Opciones autoload	Clave para auditar wp_options
wp transient list	Transients activos	Detecta acumulación excesiva
wp cache type	Estado de object cache	Disponible desde WordPress 6.1 en adelante
wp plugin list	Plugins instalados, activos, desactualizados	Útil para revisión de mantenimiento
dig, ping, curl -I	DNS, latencia, headers HTTP	Comandos rápidos de red
top, htop, iostat	Recursos del sistema	Requiere permisos de sistema (VPS, dedicado)

Conclusión

Una auditoría WPO no resuelve por sí sola los problemas de rendimiento, pero marca el camino correcto para hacerlo. Es el punto de partida imprescindible antes de cualquier intervención técnica seria.

Muchos proyectos se lanzan a instalar plugins de optimización, configurar cachés o minificar archivos sin haber analizado previamente qué está fallando y por qué. Esta aproximación sin diagnóstico previo suele llevar a soluciones parciales, conflictos innecesarios o incluso empeoramientos.

Con este artículo hemos planteado una auditoría WPO estructurada por capas, que permite revisar desde los aspectos más básicos (DNS, red, servidor) hasta los más internos (consultas SQL, object cache, estructura del front-end). Acompañada de una checklist exhaustivo, esta metodología te servirá como guía tanto para auditorías puntuales como para procesos de mantenimiento periódico.

Claves finales:

• No todo lo que parece lento lo es realmente: por eso es vital medir y registrar métricas clave antes de actuar.
• Cada capa cuenta: pequeños cuellos de botella combinados pueden convertirse en problemas graves de rendimiento.
• El informe es tan importante como el análisis: documentar hallazgos, métricas y prioridades permite trabajar mejor en equipo y justificar acciones ante clientes o responsables de producto.
• Las herramientas no solucionan, solo diagnostican: asegúrate de interpretar correctamente los datos antes de hacer cambios.

Este enfoque puede aplicarse tanto en sitios WordPress pequeños como en grandes instalaciones WooCommerce, LMS o multisite. Solo hay que adaptar la profundidad de la auditoría y el nivel de análisis según el caso.

Si nuestro hosting es WordPress.com ya tendremos integrados en nuestro panel de control de administración herramientas de mucha utilidad para las auditorías como la herramienta de Monitorización o la de Rendimiento.

O comandos específicos desde la consola por medio de WP CLI como por ejemplo: wp wpcomsh.

Contar con un buen hosting puede simplificar tanto el análisis como la redacción del informe final, gracias a las herramientas y accesos que nos proporcione.

¡Hey! También tienes disponible este contenido en vídeo en nuestro canal de YouTube, con preguntas en directo de la audiencia. Échale un vistazo, te va a encantar.