El propietario de un sitio puede mejorar su velocidad preparando mejor las imágenes, eliminando funciones innecesarias y revisando la caché. Conviene recurrir a ayuda técnica cuando el retraso nace de las plantillas compartidas, el servidor o las interacciones con JavaScript, o cuando un cambio puede afectar a las compras, la indexación o una función esencial. El punto de partida debe ser un problema reproducible en una página real, no una puntuación decepcionante por sí sola.
Identifica qué va lento antes de elegir la solución
Una página puede aparecer enseguida y responder mal al abrir el menú. Otra puede responder con agilidad, pero mover el contenido justo cuando alguien intenta pulsar un botón. Ambas necesitan atención, aunque comprimir una imagen no resolverá necesariamente ninguno de esos problemas.
Las Core Web Vitals distinguen aspectos importantes de esa experiencia. Largest Contentful Paint, o LCP, indica cuándo se muestra el mayor elemento de contenido visible que cumple los criterios de la métrica. Interaction to Next Paint, o INP, mide la capacidad de respuesta a las interacciones. Cumulative Layout Shift, o CLS, mide los desplazamientos visuales inesperados.
Los umbrales considerados buenos son LCP igual o inferior a 2.5 s, INP igual o inferior a 200 ms y CLS igual o inferior a 0.1, evaluados en el percentil 75. Son referencias de experiencia de usuario, no promesas de posicionamiento. El rendimiento debe acompañar a un contenido útil, una navegación accesible y una web técnicamente correcta.
Empieza por una página importante: un producto, un servicio, un artículo o el contacto. Describe lo que ocurre con palabras sencillas. ¿La imagen principal tarda en aparecer? ¿Un filtro se queda pensando? ¿Un aviso empuja el texto hacia abajo? Esa descripción da una finalidad a la medición.
Lee PageSpeed Insights junto con Search Console
PageSpeed Insights combina datos de campo, cuando están disponibles, con una prueba de laboratorio controlada. Los datos de campo reflejan experiencias de usuarios reales que cumplen los requisitos de recopilación y navegan en condiciones diversas. El laboratorio analiza un entorno concreto y sirve para reproducir problemas e investigar posibles causas.
Ambos resultados pueden diferir sin que exista un error. Los visitantes utilizan otros dispositivos, conexiones y patrones de interacción. Además, los datos de campo corresponden a un periodo de observación, mientras que la prueba de laboratorio examina la página en el momento del análisis. Una mejora puede aparecer en el laboratorio antes de reflejarse en el informe de campo.
Comprueba si los datos de campo pertenecen a esa URL o al conjunto del origen. El resultado del origen aporta contexto, pero no demuestra que todas las páginas se comporten igual. La ausencia de datos tampoco acredita un buen rendimiento: puede faltar una muestra suficiente.
El informe de Core Web Vitals de Search Console permite detectar grupos de URL similares con problemas. Úsalo para encontrar patrones y después examina páginas representativas. Una plantilla de producto compartida exige una intervención distinta de una imagen demasiado pesada en un artículo aislado.
No confundas la puntuación de rendimiento de Lighthouse con la evaluación de campo. Una prueba de navegación estándar tampoco reproduce todo lo que hace una persona. Abre menús, despliega secciones, envía formularios y utiliza filtros en un dispositivo real. Anota dónde se atasca la experiencia.
Decide qué puedes cambiar con seguridad
El alcance importa tanto como la dificultad. Un ajuste pequeño puede afectar a todo el sitio, mientras que sustituir una imagen de forma controlada puede limitarse a una página. Antes de intervenir, confirma cómo recuperar la versión anterior y comprueba los recorridos importantes.
| Qué observas | Acción razonable del propietario | Cuándo pedir ayuda técnica |
|---|---|---|
| Una imagen editorial grande aparece tarde | Subir una versión comprimida y de tamaño adecuado | La plantilla retrasa la detección o carga de la imagen principal |
| Hay widgets que ya no se utilizan | Identificar qué funciones siguen siendo necesarias | Los scripts se comparten o existen dependencias |
| Las páginas públicas tardan en llegar | Revisar la caché existente y consultar al alojamiento | Persisten las respuestas lentas o hay contenido personalizado |
| El contenido salta durante la carga | Revisar dimensiones de imágenes y ajustes de inserciones | El movimiento procede de plantillas, fuentes o componentes añadidos |
| Menús y filtros responden tarde | Documentar la interacción y el dispositivo | JavaScript o el renderizado bloquean la respuesta |
Esta tabla orienta la investigación. No demuestra que un plugin, proveedor de alojamiento o tema sea culpable. Cambia una parte acotada, observa el resultado y conserva un registro de la intervención.
Reduce el peso de las imágenes sin retrasar la principal
Prepara imágenes adecuadas al tamaño en que se mostrarán. Una fotografía destinada a impresión puede contener información innecesaria para un espacio pequeño de una página. Comprímela, revisa que no tenga defectos visibles y utiliza un formato moderno adecuado cuando el flujo de publicación lo permita.
También importa la adaptación a la pantalla. El navegador debe poder elegir una variante apropiada para sus condiciones de visualización. El CMS quizá ya genere esas variantes, pero un tema o constructor visual puede impedir que se aprovechen correctamente.
Las imágenes fuera de la zona inicial suelen poder cargarse más tarde. La imagen destacada que aparece al entrar no debería recibir automáticamente el mismo tratamiento. Aplicar carga diferida a la imagen que probablemente determina el LCP puede retrasar el contenido principal. Si lo controla la plantilla, solicita una corrección específica.
Reserva las dimensiones o la proporción de aspecto del contenido multimedia. Sustituir un archivo pesado por otro ligero no evitará los saltos si el navegador sigue sin saber cuánto espacio debe dejarle.
Revisa plugins, scripts y fuentes según su utilidad
Enumera las funciones que añaden código: analítica, chat, vídeo incrustado, publicidad, elementos sociales y módulos del constructor de páginas. Identifica quién mantiene cada función y para qué sirve. Una etiqueta de una campaña terminada no debería quedarse porque nadie recuerda quién la instaló.
Contar plugins no basta para diagnosticar. Una función sencilla puede añadir poca carga; un plugin necesario puede ejecutar mucho código en páginas que no lo utilizan. Averigua qué se ejecuta, dónde y si debe hacerlo inmediatamente.
Prueba las eliminaciones en un entorno de ensayo cuando sea posible. Un formulario, un control de consentimiento o una integración de pago puede depender de código que parece prescindible en un informe de velocidad. Retrasar scripts puede mejorar la carga en ciertas situaciones y, al mismo tiempo, romper una interacción esencial.
Aplica el mismo criterio a las fuentes. Las familias y variantes de peso sin uso añaden complejidad. Simplificar la tipografía puede ayudar, pero cambiar cómo se carga puede modificar los saltos de línea y desplazar contenido. Revisa títulos, navegación y botones, también en páginas traducidas y diseños de derecha a izquierda.
Revisa la caché sin mostrar una página incorrecta
La caché evita repetir trabajo, pero cada modalidad resuelve algo distinto. La caché del navegador reutiliza recursos descargados. La caché de página puede reutilizar HTML público ya generado. Una red de distribución de contenidos puede guardar recursos estáticos sin almacenar la página completa.
Averigua primero qué hace la configuración actual. Añadir otra capa de optimización sin entender la existente puede provocar conflictos o dificultar el diagnóstico. Pregunta al alojamiento o al desarrollador qué respuestas se almacenan y cómo se vacían cuando cambia el contenido.
Las páginas personalizadas necesitan un tratamiento especial. Las áreas privadas, los carritos y otras respuestas específicas de cada usuario no deben servirse desde una caché compartida inadecuada. Después de cambiar ajustes, verifica que las actualizaciones se vean y que los visitantes con sesión iniciada y sin ella reciban la experiencia prevista.
Reconoce cuándo hace falta un diagnóstico técnico
Una respuesta inicial lenta del servidor puede deberse a la aplicación, consultas a la base de datos, fallos de caché o limitaciones del alojamiento. No significa automáticamente que contratar otro plan lo resolverá. Un desarrollador puede examinar el recorrido de la petición y localizar dónde se consume el tiempo.
Las plantillas con mucho JavaScript requieren el mismo cuidado. Una página puede descargarse rápido y mantener al navegador ocupado ejecutando código y dibujando contenido. La solución puede consistir en reducir trabajo, cargar una función solo donde se necesita o cambiar su implementación. Retrasar todos los scripts no sustituye el análisis de dependencias.
Los saltos visuales pueden proceder de componentes compartidos: espacios publicitarios, avisos, inserciones o cambios de fuente. Corregir la plantilla puede beneficiar a muchas páginas. Editar cada artículo por separado puede dejar intacta la causa.
Los rediseños y las migraciones añaden riesgos. Una interfaz más rápida aún puede introducir redirecciones rotas, etiquetas canónicas incorrectas o restricciones de indexación involuntarias. Mantén conectadas las comprobaciones de rendimiento y SEO técnico, con una vía clara para volver atrás antes del lanzamiento.
Entrega al especialista pruebas y un encargo acotado
Una petición útil explica qué no pueden hacer cómodamente los visitantes, dónde ocurre y qué debe seguir funcionando. Incluye URL afectadas, capturas o informes guardados, contexto del dispositivo y pasos para reproducir la interacción. Anota cambios recientes de tema, plugins, alojamiento o contenido sin asumir que son la causa.
Antes de entregar el trabajo, utiliza esta lista:
- [ ] Identificar páginas importantes y las acciones de sus visitantes.
- [ ] Guardar informes iniciales y distinguir campo de laboratorio.
- [ ] Describir el retraso, bloqueo o desplazamiento visible.
- [ ] Enumerar integraciones y funciones esenciales.
- [ ] Confirmar copias de seguridad, entorno de ensayo y recuperación.
- [ ] Acordar cambios, alcance de las pruebas y criterios de aceptación.
- [ ] Asignar quién comprobará el resultado después de publicar.
Pide una explicación de la causa sospechada y de por qué la intervención la resolvería. La aceptación debe incluir formularios y navegación funcionales, contenido estable y pruebas comparables, no solo una captura con una puntuación mejor.
Cómo encaja Jonathan Santo
La página de servicios de SEO técnico y mejora de sitios de Jonathan Santo describe trabajo en webs existentes, incluidos estructura, contenido, indexación, velocidad y Core Web Vitals. Son áreas que coinciden con el momento en que un problema de rendimiento exige examinar el sitio de forma más amplia. Antes de acordar el encargo, concreta el problema, quién implementará los cambios y cómo se validarán; la descripción del servicio no acredita un resultado para tu web.
Comprueba la mejora donde la perciben los visitantes
Repite pruebas de laboratorio comparables y recorre las funciones afectadas. Deja que los informes de campo incorporen visitas posteriores antes de evaluar la tendencia. Conserva la referencia inicial y las notas de implementación para que otra persona entienda qué cambió y por qué.
Si la carga mejora pero un filtro sigue atascándose, queda trabajo de respuesta a interacciones. Si la página parece más rápida pero salta el contenido, queda trabajo de estabilidad visual. Una buena entrega deja una mejora funcional, una explicación y un hábito de mantenimiento que ayuda a evitar que el problema regrese.
Contenido de socios. Este artículo trata sobre Jonathan Santo y se publica por separado de la cobertura editorial de WebVitalsDev.
