La página lenta que importa no es la página de inicio

Resumen

Cuando tu jefe dice que el sitio web es lento, el instinto es empezar a comprimir imágenes y disculparte con la página de inicio. La medida más útil es decidir qué página merece realmente acelerarse primero. Este artículo recorre un escenario concreto: un pequeño equipo de marketing al que se le pide "arreglar la velocidad" de un sitio B2B de tamaño medio. Cubre la medición de los Core Web Vitals con datos de campo, la elección de páginas según su impacto en el negocio y la incorporación de datos estructurados solo después de los arreglos baratos. La recompensa es un plan corto y defendible que tenga sentido para un jefe no técnico.

La página más lenta de tu sitio web no es la que señala PageSpeed Insights. Es la página que tu jefe nunca ha abierto: la vinculada a una campaña de pago, o enterrada en una sección de producto olvidada, y es la que realmente determina si el presupuesto de este mes produce algo. Cuando alguien de alto nivel dice "el sitio es lento, arréglalo", no necesita un proyecto de velocidad web. Necesita un ejercicio de priorización.

Toma un escenario que muchos hemos vivido. Eres todo el equipo de marketing de una empresa de software B2B de tamaño medio. El sitio tiene una página de inicio, un blog, un centro de ayuda y cinco páginas de aterrizaje vinculadas a campañas publicitarias específicas. Tu jefe leyó un artículo sobre Core Web Vitals o escuchó una queja de un cliente. La instrucción es clara: hazlo más rápido.

Cómo respondas en la próxima hora decide si pasas el próximo mes comprimiendo imágenes o haciendo un trabajo que cambie los números que importan.

Empieza con la página que genera ingresos, no con la que avergüenza

El principio: el trabajo de velocidad tiene un retorno, y ese retorno depende del tráfico y del valor de conversión. Una página de poco tráfico pero alta conversión puede importar más al negocio que la página de inicio, incluso si es más lenta.

Así que el primer paso es hacer una lista de páginas a partir de los análisis, no del mapa del sitio. ¿Qué páginas reciben dinero en forma de clics de anuncios? ¿Qué páginas no se han tocado desde el lanzamiento? En este escenario, la página de aterrizaje más importante (la que está detrás de un anuncio de búsqueda de pago que lleva dos meses activo) se construyó con capturas de pantalla grandes y sin optimizar. La página de inicio, en comparación, ya fue optimizada por una agencia hace un año.

No arreglas la página de inicio primero. Arreglas la página que genera dinero. Esa no es una decisión técnica, es una decisión de negocio. Si una auditoría técnica completa suena como la respuesta correcta, resístete un momento. Las auditorías producen una lista; no te dicen con qué elemento empezar. Una auditoría técnica de SEO bien delimitada es una herramienta de decisión, no una respuesta de pánico.

A menudo encontrarás que un pequeño número de páginas genera la mayor parte del tráfico y las conversiones; el resto son informativas o vestigiales. Eso no es una razón para ignorar para siempre las páginas informativas lentas. Es una razón para secuenciarlas después de las páginas que tienen una línea directa con los ingresos. La página de inicio puede ser la más lenta de todas, pero si el objetivo del negocio son los clientes potenciales, una visita a la página de inicio es solo un punto de partida: la página de aterrizaje es donde alguien realmente convierte.

Divide "rápido" en "medido" y "percibido"

El segundo paso es separar lo que las pruebas de rendimiento dicen sobre tu página de lo que los usuarios reales experimentan. La documentación de Core Web Vitals de Google nombra tres métricas que cuentan para el posicionamiento en los motores de búsqueda: Largest Contentful Paint (carga), Interaction to Next Paint (capacidad de respuesta) y Cumulative Layout Shift (estabilidad visual). Importan porque rastrean momentos que afectan si alguien realmente puede usar la página.

En el escenario, abres la página de aterrizaje en un probador de rendimiento y obtienes una puntuación razonable. Pero cuando la comparas con los datos de campo en Google Search Console (que reflejan las experiencias reales de los visitantes), resulta que la página es lenta con frecuencia. Esa es la señal que importa. Las pruebas de laboratorio siguen siendo útiles después de un cambio, para comparar antes y después. Pero los datos de campo son la verdad definitiva para las personas que hicieron clic en tu anuncio desde una variedad de dispositivos y conexiones.

En lugar de esto	Empieza con esto	Por qué
Puntuación de PageSpeed como un solo número	Datos de campo de Core Web Vitals	Los datos de campo provienen de usuarios reales, no de un servidor de prueba
"El sitio es lento"	Qué páginas respaldan los objetivos del negocio	Las páginas rápidas e inútiles no generan clientes potenciales
Reconstruir el CMS	Comprimir imágenes y limpiar scripts	Los arreglos de bajo riesgo aportan la mayor parte del beneficio

Si quieres una referencia más profunda para más adelante, una guía de Core Web Vitals puede explicarte cada métrica. Pero por ahora, solo necesitas lo suficiente para construir el plan. La clave es nombrar cuál de las tres métricas está causando realmente el problema en esa página específica. Si el texto aparece tarde, mira las imágenes y la respuesta del servidor. Si los botones se sienten entrecortados, mira las tareas largas de JavaScript. Si el diseño salta, mira los espacios reservados para anuncios y elementos incrustados. Ese matiz es lo que separa un arreglo específico de una optimización aleatoria.

Arregla lo barato antes de lo caro

El tercer principio: no dejes que un proyecto de rendimiento se convierta en un rediseño. La mayoría de las mejoras que realmente mueven la experiencia del usuario son poco glamurosas y baratas.

Mira la página de aterrizaje y nombra a los culpables obvios. Las imágenes son capturas de pantalla a resolución completa. Hay un script de terceros en la página que ya nadie puede identificar. Una fuente web está bloqueando la renderización del texto. Estos son problemas familiares.

En un mundo perfecto, pasarías una semana reescribiendo la página con un framework moderno. En la práctica, empiezas con tareas de medio día: comprimir imágenes, diferir el script no utilizado, precargar la imagen principal. Puedes probar estos cambios en una tarde, y no requieren un comité de aprobación.

Advertencia: la velocidad no siempre es tan simple. Algunas páginas son lentas por un servidor, una base de datos o una dependencia de terceros que no controlas. Pero si no has comprobado los arreglos baratos, aún no puedes justificar el caro. Muchos equipos desperdician un presupuesto en una reconstrucción porque nunca comprimieron las capturas de pantalla. Hay una humildad aquí que vale la pena mantener: una puntuación de rendimiento es un síntoma, no un diagnóstico. Los arreglos baratos son en sí mismos diagnósticos. Después de comprimir las imágenes, aprendes si el cuello de botella era tu contenido o tu infraestructura.

Añade datos estructurados mientras ya estás en el código

Esta es la capa que sorprende al jefe. Después de hacer los arreglos baratos, ya estás dentro de la página. Es el momento adecuado para añadir algo que no es velocidad en absoluto: datos estructurados.

Los datos estructurados son marcado que ayuda a los motores de búsqueda a entender qué contiene una página. Es el mismo HTML que puede llevar a resultados de búsqueda más ricos y mejor visibilidad, y se está volviendo más relevante a medida que la búsqueda se orienta hacia respuestas generadas por IA. Para un equipo pequeño, esta es una palanca infrautilizada porque no requiere escribir contenido nuevo. Estás etiquetando lo que ya existe.

En el escenario, añades un esquema orientado a servicios a la página de aterrizaje. El tipo exacto depende de de qué trate la página: una página de servicios, un artículo, un producto. No necesitas añadir todos los tipos a la vez. Añadir uno con cuidado es mejor que añadir diez descuidadamente. No se garantiza ningún resultado; Google decide qué mostrar. Pero el riesgo es bajo y el potencial positivo es real. Si decides profundizar, una guía de implementación de datos estructurados cubre los pasos prácticos.

Traduce los arreglos a "¿generó dinero?"

La parte difícil no es el trabajo técnico. Es la forma en que lo presentas a un jefe no técnico.

Tu jefe pidió una cosa: hacer el sitio más rápido. Si dices "mejoramos el LCP en la página de aterrizaje", podrías recibir una mirada vacía. En su lugar, traduce el trabajo a consecuencias de negocio.

En este escenario, la página de aterrizaje es el destino de una campaña de pago. Cada segundo que espera es un segundo en el que un visitante podría irse antes de que aparezca la llamada a la acción. Entonces explicas: eliminamos fricciones obvias en la página donde el dinero cambia de manos. No puedes prometer un salto de posicionamiento específico (cualquiera que lo haga está adivinando), pero puedes hacer un argumento razonable y honesto. También puedes conectar esto con el presupuesto que tu jefe ya entiende. La misma inversión publicitaria compra una visita; la diferencia es si esa visita tiene la oportunidad de convertirse en un cliente potencial.

Un informe mensual simple funciona mejor que un panel lleno de jerga. Muestra tres cosas: qué página elegiste, qué métrica mediste y qué cambiaste. Si la métrica mejora, eso es una validación. Si no, aún tienes un experimento claro para reevaluar. No persigas una sola puntuación mes a mes; los Core Web Vitals fluctúan con la mezcla de tráfico, los tipos de dispositivo e incluso la región geográfica. Informa la tendencia, no el número.

Qué hacer el próximo lunes

La lección del escenario: no arreglas "el sitio web". Arreglas una página específica, basándote en datos, y terminas con un proceso repetible en lugar de un proyecto único. Cuando alguien con poder dice "hazlo más rápido", la respuesta más útil es una sola pregunta aclaratoria: ¿qué página, y para quién?

Luego mide los datos de campo, arregla lo barato, añade datos estructurados si ya estás en el código, e informa en lenguaje sencillo. Los resultados pueden no ser dramáticos. Pero sabrás exactamente qué página se volvió más rápida, por qué la elegiste y qué hacer después. Ese es un mejor resultado que un proyecto vago que comenzó con una puntuación de velocidad y terminó en un rediseño que nadie entendió.