Cómo mejorar el rendimiento de tu sitio: lo que aprendí pasando de 44 a 98
Una nota baja de rendimiento puede tener más de una causa — y a veces la corrección correcta solo aparece cuando mides de la manera correcta.
5 min de lectura
- kastavo
- rendimiento

La semana pasada decidí medir el rendimiento de Kastavo de verdad, en vez de fiarme solo de la sensación de que "parece rápido". Usé una herramienta de análisis de rendimiento que encontré por ahí, y el primer resultado fue peor de lo que esperaba: nota 44, en una escala de 0 a 100. LCP (el tiempo hasta que aparece el elemento visible más grande) de 7,2 segundos, TBT (tiempo total de bloqueo) de 3,6 segundos — los dos en la franja "mala".
Empecé a investigar con calma, una causa a la vez.
Hallazgo 1: cada página cargaba todo
El primer problema era estructural: la página de inicio — y, en realidad, cualquier página del sitio — cargaba las bibliotecas de las más de 100 herramientas, no solo la de la que la persona estaba usando. Eso significaba descargar código de procesamiento de PDF, vídeo y OCR incluso para quien solo quería usar el contador de palabras.
La corrección fue separar el catálogo de herramientas (metadatos, ligero) de la carga de cada herramienta en sí (pesada, solo cuando hace falta). El resultado: la página de inicio bajó de 2,3 MB de JavaScript a menos de 900 KB.
Hallazgo 2: una redirección escondida
El segundo problema era más sutil: toda visita a la raíz del sitio (kastavo.com/) pasaba por una redirección al idioma correcto (/en, /pt o /es), y ese paso extra costaba más de medio segundo en las mediciones simuladas. La corrección fue hacer que la raíz respondiera ya con el contenido, sin el salto, para quien usa el idioma predeterminado (inglés). Quien prefiere portugués o español sigue siendo llevado a la versión correcta, con el idioma detectado igual que antes.
Hallazgo 3: el aviso de cookies era el "elemento más grande" de la pantalla
Este fue el más inesperado. La métrica de rendimiento más importante (LCP) estaba frenada por el aviso de cookies, que solo se dibujaba cuando el JavaScript terminaba de cargar. La solución fue hacer que ese aviso viniera listo en el HTML desde el primer momento, sin esperar nada.
El giro: los números variaban según dónde medía
Después de esas correcciones, volví a ejecutar la prueba esperando verlo todo resuelto — y el resultado seguía siendo raro: a veces 65, a veces 68, sin coincidir con lo que yo medía en mi propio navegador. La ejecuté varias veces más y me di cuenta de que los números simplemente no eran coherentes entre sí.
Decidí dejar de fiarme de ese número aislado y contrastar con una fuente de referencia: PageSpeed Insights, del propio Google. Usa el mismo motor de medición que se ejecuta en el navegador (Lighthouse), pero en los servidores de Google, y además muestra datos de usuarios reales cuando el sitio tiene suficiente tráfico (Kastavo todavía no lo tiene, y el panel muestra "No Data").

El resultado fue muy distinto: 98 de rendimiento, 100 en accesibilidad, buenas prácticas y SEO; un LCP de 2,3 segundos y un TBT de 80 milisegundos. Era exactamente lo que las correcciones debían haber entregado — solo que la primera herramienta que usé para medir, por algún motivo, no lo reflejaba de forma fiable.
La lección que queda
Esto me enseñó algo que vale más allá del rendimiento: una herramienta de medición no es neutral — cada una simula condiciones distintas (tipo de conexión, velocidad del procesador, ubicación del servidor de prueba), y un número aislado puede engañar. Cuando el resultado no coincide con lo que observas en la práctica, conviene contrastar con más de una fuente antes de asumir que el problema es tuyo.
Hoy Kastavo carga rápido de verdad, no solo "parece" rápido — y ahora confío en ello porque medí de la manera correcta, no una sola vez.
Preguntas frecuentes
¿Qué son el LCP, el TBT y la nota de rendimiento?
El LCP (Largest Contentful Paint) es el tiempo hasta que aparece el elemento visible más grande de la pantalla, como una imagen grande o un bloque de texto; hasta 2,5 segundos se considera bueno, y más de 4 segundos, malo. El TBT (Total Blocking Time) suma los periodos en que la página estuvo bloqueada, sin responder al usuario, mientras cargaba; es una métrica de laboratorio, y hasta 200 milisegundos es bueno. La nota de rendimiento es la calificación de 0 a 100 de Lighthouse, que combina varias métricas con pesos distintos: de 90 a 100 es verde, de 50 a 89 es naranja y por debajo de 50 es roja.
¿Por qué distintas herramientas de prueba dan notas distintas para el mismo sitio?
Porque cada una mide en condiciones diferentes: la velocidad de conexión simulada, la potencia del procesador de la máquina de prueba, la ubicación del servidor, la versión de la herramienta e incluso la forma de aplicar la lentitud simulada. Además, la misma prueba repetida varía un poco de una ejecución a otra. Por eso conviene ejecutarla más de una vez, comparar siempre en la misma herramienta a lo largo del tiempo y contrastar con una fuente de referencia.
¿El rendimiento de un sitio afecta de verdad a la posición en Google?
En parte. Google usa los Core Web Vitals (LCP, INP y CLS), medidos con usuarios reales, como una de sus señales de posicionamiento, pero es una señal entre muchas, y la relevancia del contenido pesa más. La nota de Lighthouse en sí no es un factor de posicionamiento. Un sitio rápido con contenido flojo no subirá solo por eso, pero un sitio lento perjudica a quienes lo usan, y eso vale por sí mismo.
