Cómo leer el informe de tu auditoría de velocidad web sin ser programador

Pediste una auditoría de velocidad web gratuita, y ahora tienes un PDF o un enlace lleno de siglas — LCP, CLS, TBT, un puntaje del 0 al 100 en rojo, amarillo o verde, y una lista de “oportunidades” con nombres que suenan a otro idioma. Es información real y útil, pero está escrita para desarrolladores, no para el dueño del negocio que la pidió. Esto es lo que significa, en términos simples.

El puntaje general (0-100) no te dice todo

Es lo primero que se ve, y lo que más ansiedad genera si sale en rojo. Pero un puntaje de 45 no significa “tu sitio está roto” — significa que hay margen de mejora medible, y el informe existe justamente para mostrar dónde. Un puntaje bajo con un plan claro de qué arreglar vale más que preocuparse por el número en sí.

Los tres términos que realmente importan

Detrás del puntaje general están las métricas que Google usa de verdad para evaluar la experiencia de tu sitio — los Core Web Vitals:

• LCP (Largest Contentful Paint): cuánto tarda en aparecer el elemento principal de la página — normalmente una imagen grande o un titular. Si tarda más de 2.5 segundos, el visitante siente que el sitio “no carga”.
• INP (Interaction to Next Paint): cuánto tarda el sitio en responder cuando alguien hace clic o toca algo. Por encima de 200 milisegundos, empieza a sentirse “trabado” aunque técnicamente esté funcionando.
• CLS (Cumulative Layout Shift): si los elementos de la página se mueven mientras carga — el botón que se corre justo cuando ibas a tocarlo. Es una de las quejas más comunes de los usuarios, aunque casi nadie sepa nombrarla.

Si tu informe marca estas tres en verde, el resto del puntaje suele acomodarse solo. Si alguna está en rojo, es el primer lugar donde mirar.

Qué significan las “oportunidades de mejora”

Debajo del puntaje, la mayoría de los informes lista una serie de recomendaciones ordenadas por impacto potencial — cosas como “elimina recursos que bloquean el renderizado” o “usa formatos de imagen de próxima generación”. No necesitas entender el detalle técnico de cada una; necesitas entender el tamaño del impacto que indica el informe (normalmente en segundos ahorrados o puntos de mejora) para saber cuáles priorizar primero.

Qué puedes arreglar tú mismo vs. qué necesita un desarrollador

Tú probablemente puedes:

• Reemplazar imágenes pesadas por versiones comprimidas antes de subirlas.
• Eliminar plugins, widgets o botones de terceros que ya no usas.
• Revisar si tienes videos que se reproducen automáticamente sin necesidad.

Casi siempre necesita un desarrollador:

• Cambios de código que afectan cómo carga la página (orden de carga de scripts, lazy loading).
• Migrar de un hosting insuficiente a uno con mejor capacidad.
• Reestructurar cómo está armado el sitio si el problema es de arquitectura, no de contenido.

Cómo priorizar si el informe trae 15 recomendaciones

No las ataques en el orden en que aparecen. Prioriza por dos criterios: impacto estimado (lo que indica el propio informe) y facilidad de implementación. Las mejoras de “impacto alto, esfuerzo bajo” — casi siempre relacionadas con imágenes y scripts innecesarios — van primero, porque generan resultado visible rápido. Los cambios estructurales más profundos se planifican aparte, porque suelen tomar más tiempo y justifican involucrar a alguien técnico.

Si el informe te dejó con más preguntas que respuestas

Es normal. Un informe automático te dice qué está pasando, pero no siempre por qué pasa en tu caso específico ni qué orden tiene más sentido para tu situación. Esa lectura la hacemos como parte de nuestro servicio de Desarrollo Web — no solo entregamos el reporte, lo explicamos línea por línea y armamos el plan de qué resolver primero.

Foto de portada: Steve A Johnson / Pexels