Velocidad y Core Web Vitals
Arreglo la causa de un sitio lento. No el síntoma.
La mayor parte del trabajo de velocidad consiste en un plugin de caché, un minificador y una nueva prueba con la esperanza de que mejore. Eso mueve la puntuación de laboratorio y deja el problema real donde estaba. Yo mido en qué se va realmente el tiempo, corrijo eso y te entrego un antes y un después que puedes reproducir en tu propio equipo.
01DemostraciónEn vivo desde tu navegador
Esta página, medida mientras la lees.
Cualquiera que venda trabajo de velocidad puede mostrarte la captura de una buena prueba. Estos son los números que tu propio navegador registró al cargar esta página, comparados con los umbrales que usa Google. Abre la pestaña de red y compruébalos.
Marcado, estilos, script y tres tipografías: todo lo necesario para mostrar lo que estás leyendo.
El peso medio de una página web según el HTTP Archive.
02DiagnósticoEn qué se va realmente el tiempo
La lentitud es un síntoma. Estas son las causas.
Casi todos los sitios lentos que me envían son lentos por dos o tres de las siguientes razones. El objetivo del diagnóstico es descubrir cuáles, porque la solución para cada una es completamente distinta, y comprar la solución equivocada es la forma en que la gente termina pagando dos veces por trabajo de velocidad.
El servidor piensa demasiado
Un Time to First Byte alto significa que el trabajo ocurre antes de que un solo byte llegue al navegador. En WordPress suelen ser consultas sin caché dentro del bucle de una plantilla, una tabla de opciones con autoload que creció hasta varios megabytes o un plugin que llama a una API externa mientras se genera la página. Ninguna optimización del front end toca esto.
Lo más grande de la pantalla es enorme
Una imagen principal exportada a 4000 píxeles de ancho y servida como PNG hace fallar Largest Contentful Paint por sí sola. La solución es poco glamorosa: dimensiones correctas, formatos modernos, un srcset para que los teléfonos no descarguen la versión de escritorio, ancho y alto explícitos y fetchpriority en la única imagen que importa.
Los scripts bloquean el renderizado
Cada script síncrono en el head es una señal de alto antes de que el navegador pueda pintar. Los gestores de etiquetas, los widgets de chat, las herramientas de pruebas A/B y los cargadores de fuentes son los sospechosos habituales, y a menudo se cargan en todas las páginas para una función que se usa en una sola.
La página se mueve mientras carga
El Cumulative Layout Shift lo causan elementos que llegan tarde sin espacio reservado: imágenes sin dimensiones, fuentes web que cambian a otro tamaño, avisos de cookies y anuncios insertados encima del contenido existente. Suele ser el más barato de los tres de arreglar y el más molesto de vivir.
Las interacciones se sienten pesadas
Interaction to Next Paint reemplazó a First Input Delay en marzo de 2024, y es una métrica mucho más exigente. Mide cuánto tarda una interacción en producir una respuesta visible, durante toda la visita, no solo la primera. Los sitios la reprueban porque hay demasiado JavaScript compitiendo por el hilo principal.
03ProcesoDe verdad, una secuencia
Cómo avanza el trabajo.
- 01
Diagnóstico, antes de cualquier cotización
- Mido el sitio y te envío por escrito un desglose de en qué se va el tiempo, ordenado por cuánto te cuesta y qué tan difícil es de arreglar. Ese documento es tuyo me contrates o no.
- 02
Una línea base con datos de campo
- Las puntuaciones de laboratorio varían entre una prueba y otra. Primero registro los datos de campo del Chrome UX Report, para que al final comparemos lo que vivieron los visitantes reales, no dos pruebas de laboratorio en tardes distintas.
- 03
Corregir las causas, de la mayor a la menor
- El trabajo se hace en staging, un cambio a la vez, y cada uno se mide por separado. Juntar diez cambios no te dice nada sobre cuál funcionó, y te deja sin poder revertir el que empeoró las cosas.
- 04
Verificar y luego entregarte el método
- Recibes el antes y el después, los pasos para reproducir ambos y una nota sobre lo que irá deshaciendo el trabajo poco a poco: normalmente, el próximo plugin que alguien instale.
04PreguntasFrecuentes, respondidas sin rodeos
Lo que la gente pregunta antes de contratarme.
¿Un plugin de caché arreglará mis Core Web Vitals?
En parte, en el mejor de los casos. La caché mejora el tiempo de respuesta del servidor, lo que ayuda al Time to First Byte. Hace muy poco por un Largest Contentful Paint causado por una imagen principal demasiado grande, nada por el desplazamiento de diseño causado por elementos sin tamaño y nada por un Interaction to Next Paint causado por JavaScript pesado. La mayoría de los sitios me llegan con un plugin de caché ya instalado y aun así reprobando.
¿Por qué cambia todo el tiempo mi puntuación de PageSpeed Insights?
El número grande de arriba es una prueba de laboratorio en un dispositivo lento simulado, y varía de una prueba a otra. La sección de abajo, los datos de campo del Chrome UX Report, es lo que Google realmente usa, y es un promedio móvil de 28 días de visitantes reales. Persigue los datos de campo e ignora los pequeños movimientos de la puntuación de laboratorio.
¿Cuánto tarda la mejora en verse en Google?
Como los datos de campo son una ventana móvil de 28 días, espera unas cuatro semanas para que el cambio se refleje por completo, y más en sitios con poco tráfico que tardan en reunir suficientes muestras. Quien te promete un cambio inmediato en el posicionamiento está hablando de la puntuación de laboratorio, no de la que cuenta.
¿Qué mejora puedes prometer?
Ninguna antes de haber mirado, y por eso primero va el diagnóstico y después la cotización. Un sitio cargado de plugins con una imagen principal sin optimizar tiene mucho margen fácil. Un sitio que ya es ligero en el front end pero lento en la base de datos es otro trabajo, a otro precio. Prefiero darte un número real después de una hora de análisis que uno impresionante ahora.
¿Necesito reconstruir el sitio?
Normalmente no. La mayoría de los problemas de velocidad son un puñado de causas concretas y no un defecto de fondo, y corregirlas es mucho más barato que reconstruir. Si creo que llegaste al techo de lo que el desarrollo actual puede dar, te lo diré, pero es la excepción, y no te conviene que yo recurra a eso primero.
¿Qué es INP y reemplazó a FID?
Interaction to Next Paint reemplazó a First Input Delay como Core Web Vital en marzo de 2024. FID solo medía la demora antes de que el navegador empezara a atender tu primera interacción. INP mide cuánto tardó toda la interacción en producir una respuesta visible, durante toda la visita. Es bastante más difícil de aprobar, y casi siempre se reprueba por una razón: demasiado JavaScript en el hilo principal.
Mi sitio andaba bien y se volvió lento. ¿Qué cambió?
En mi experiencia, casi siempre una de tres cosas: un plugin o script de seguimiento agregado después, un equipo de contenido que sube imágenes a resolución completa directamente de la cámara, o una base de datos que creció en silencio (revisiones de entradas, transients vencidos, una tabla de opciones con autoload). Las tres son baratas de arreglar una vez identificadas.
Siguiente paso
Envíame la URL. Te diré qué le pasa.
Lo primero que recibes es un diagnóstico por escrito que es tuyo en cualquier caso. Si la respuesta honesta es que tu sitio ya está bien, eso es lo que dirá el documento.