La portada y casi todas las páginas funcionan bien, pero una URL tarda varios segundos o queda bloqueada después de cargar. Es una buena pista: un fallo general del hosting afectaría a más rutas. Esa página probablemente añade una plantilla, consulta, recurso o dependencia que las demás no usan.
Encuentra esa diferencia antes de aplicar una optimización global.
Elegir una comparación justa
Compara el artículo con otro artículo, el producto con uno de complejidad parecida o la landing con otra creada mediante el mismo constructor y cabecera.
Registra sesión, estado de caché, primer byte, bytes transferidos, peticiones, plantilla y funciones exclusivas. Dos páginas completamente distintas aportan poco aislamiento.
Separar servidor y navegador
Mide ambas URL varias veces:
curl -s -o /dev/null
-w 'Primer byte: %{time_starttransfer}s Total: %{time_total}sn'
https://example.com/pagina-sana/
curl -s -o /dev/null
-w 'Primer byte: %{time_starttransfer}s Total: %{time_total}sn'
https://example.com/pagina-lenta/No compares un HIT sano con un MISS lento como si fueran iguales. Si el primer byte difiere, revisa WordPress, PHP y MySQL; si el HTML tarda lo mismo, compara Network y Performance.
Una URL puede quedar excluida de caché por formularios, personalización, sesión WooCommerce, parámetros, cookies o una regla de ruta. Comprueba cabeceras en peticiones desconectadas repetidas. No la caches solo para igualar el indicador: primero confirma que no contiene información privada.
Identificar plantilla y código particular
Revisa la plantilla seleccionada, jerarquía del tema, condiciones del constructor, bloques, *shortcodes*, campos personalizados, funciones de plugins y scripts condicionales.
Una plantilla decorativa puede lanzar consultas o APIs mucho antes de aparecer en pantalla. Compara sus recursos y consultas con la plantilla normal.
Encontrar consultas que escalan
La página puede recuperar todas las entradas de una categoría, demasiados productos, relaciones de campos, términos con metadatos, comentarios o resultados sin límite.
Usa Query Monitor o perfilado protegido durante una sesión controlada. Localiza consultas lentas o duplicadas asociadas con el bloque, widget o *shortcode*. No borres contenido para reducirlas: corrige límites, índices, diseño de consulta o el componente que solicita registros innecesarios.
Un *shortcode* pequeño puede ejecutar varias consultas, llamar a una API, generar un DOM enorme y cargar CSS o JavaScript. En staging, retira un bloque sospechoso cada vez y mide. Si mejora, repara su implementación en lugar de eliminar a ciegas contenido esencial.
Comparar medios y terceros
Agrupa las diferencias de la cascada por imágenes, vídeo, fuentes, CSS, JavaScript, terceros, Ajax y REST. Una imagen de fondo enorme o un vídeo automático puede explicar casi toda la primera visita; un script pequeño puede consumir mucha CPU.
No optimices toda la biblioteca porque una landing usa una imagen incorrecta.
Mapas, reservas, formularios, reseñas, vídeo y redes sociales también pueden retrasar una sola URL. Comprueba si cargan antes de verse, bloquean contenido, reintentan, abren muchos dominios o dependen del consentimiento.
El mensaje y los datos de contacto deberían seguir disponibles si el tercero falla. Una vista previa ligera puede sustituir la carga inmediata cuando no es esencial.
Revisar DOM y constructor
Una página puede contener demasiados contenedores anidados, secciones duplicadas para móvil, carruseles fuera de pantalla y ventanas emergentes ocultas. Revisa nodos, profundidad, contenido duplicado y marcado repetido.
Simplifica en staging conservando diseño adaptable y accesibilidad. Reducir envoltorios sin comprobarlos puede romper la estructura.
Buscar avisos específicos
Carga solo la URL afectada y consulta registros protegidos. Un bloque puede generar el mismo aviso PHP cientos de veces. Activa depuración únicamente durante una ventana breve y nunca muestres errores al visitante:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Protege el archivo y restaura la configuración después. No purgues revisiones solo porque la página se editó mucho: normalmente no se cargan completas en una visita pública y conservan un historial útil.
Probar la interacción particular
Quizá la carga inicial sea correcta y falle un filtro, acordeón, calculadora, galería, variación, formulario o «cargar más». Graba Network y Performance para saber si espera a WordPress o bloquea el hilo principal.
Evita migrar hosting, añadir caché o retrasar todo JavaScript por un fallo local. Prefiere corregir una imagen, limitar una consulta, reparar un *shortcode*, diferir un elemento externo o simplificar una sección.
Verificar contra la página de control
Tras el cambio, prueba la URL lenta con visita limpia, su interacción principal y la página sana de comparación. Revisa móvil, escritorio, formularios, analítica, consentimiento y registros.
Para una evaluación envía ambas URL, estado del visitante, dispositivo, retraso aproximado y cambios recientes, además de cascada o tiempo de respuesta si existen. No envíes contraseñas.
El resultado debe explicar qué diferencia hacía lenta la página y demostrar que el arreglo puntual no introdujo una regresión general.