Nuestro sitio tardaba 9,3 segundos en cargar. Esto es lo que realmente arreglamos

La velocidad de carga web es de esas cosas que se notan demasiado tarde: el visitante abre la página, espera unos segundos y cierra la pestaña. Algo parecido nos pasó con nuestro propio sitio — y la causa real no estaba donde la buscábamos.

Lo que mostró la primera auditoria web

Un test de velocidad web con Google PageSpeed Insights nos dio una puntuación móvil de 50 sobre 100. El problema principal era el LCP (Largest Contentful Paint) — el momento en que el elemento visible más grande de la pantalla finalmente aparece para una persona real. LCP que es, en pocas palabras: una de las tres Core Web Vitals con las que Google mide qué tan rápida se siente una página. El nuestro era de 9,3 segundos; Google considera aceptable cualquier valor por debajo de 2,5.

Cómo leer un informe de PageSpeed

El informe de PageSpeed Insights tiene dos partes y es fácil confundirlas. Arriba aparecen los datos de visitantes reales de los últimos 28 días, si el sitio tiene tráfico suficiente. Debajo está la prueba de laboratorio: Google carga la página una vez en un teléfono lento simulado y le pone una nota de 0 a 100.

La nota sirve para comparar el antes y el después, pero importan más las métricas que hay debajo. Hoy las Core Web Vitals son tres mediciones:

• LCP. Cuándo aparece el elemento más grande de la primera pantalla. Un buen resultado está por debajo de 2,5 segundos.
• INP. Qué tan rápido responde la página a toques y clics. Un buen resultado está por debajo de 200 milisegundos. En 2024 sustituyó a la métrica anterior, FID.
• CLS. Cuánto salta la página mientras carga. Un buen resultado está por debajo de 0,1.

Móvil y escritorio se miden por separado. Empieza por la versión móvil: casi siempre sale peor.

Buscábamos en el lugar equivocado

Durante dos días optimizamos nuestro propio código — comprimimos imágenes, limpiamos el CSS, movimos scripts al final de la página. En local, el LCP bajaba a menos de un segundo. En producción, seguía en 9,3.

La respuesta estaba en el informe detallado: 1.253 de 2.880 kilobytes de la página, y más de 5 segundos de tiempo de procesador, los consumía un script llamado recaptcha__en.js — un widget de reCAPTCHA que la propia Netlify (el hosting donde está alojada nuestra web) insertaba sin async ni defer, sin una sola línea en nuestro propio repositorio.

Por qué en local todo parecía rápido

Netlify añade ese script por su cuenta cuando ve en un formulario un atributo especial, data-netlify-recaptcha. O sea, el script solo aparece en el sitio en vivo. En la computadora del desarrollador la página se abría sin él, las mediciones locales daban menos de un segundo y dimos el problema por resuelto.

Nos ayudó el diagnóstico al final del informe. Ahí aparece cada script con su peso y su tiempo de procesador. Si el más pesado no está en tus archivos, otra cosa lo está añadiendo a la página: el hosting, un plugin, un gestor de etiquetas o el widget de otra empresa.

Lo que realmente cambió el resultado

La solución fue un widget de reCAPTCHA propio con claves propias en vez del que trae el hosting por defecto — la verificación del servidor sigue exactamente igual. En paralelo pasamos las tipografías a self-host (antes se cargaban desde Google Fonts, lo que costaba casi 3 segundos más con la caché fría) y eliminamos una fuente que estaba enlazada en el código pero nunca se usaba en el CSS.

Cómo se carga ahora el captcha

Las claves propias eran la mitad de la solución. La otra mitad fue el momento de carga: reCAPTCHA ya no se carga junto con la página. Se descarga cuando el visitante se acerca al formulario al hacer scroll, o en cuanto toca un campo. Si el formulario ya se ve en la primera pantalla, el script espera a que el navegador termine de dibujar la página.

Por el camino fallaron dos detalles. Reservar solo la altura del widget no bastó: tiene un ancho fijo de 304 píxeles, y la página seguía saltando 25 píxeles hasta que reservamos la caja completa. Y mientras el widget se cargaba solo al tocar el formulario, la gente veía un rectángulo vacío y pensaba que el captcha estaba roto. Ahora aparece un poco antes de que el visitante llegue al formulario.

El resultado

El PageSpeed móvil pasó de 50 a 74, el LCP bajó de 9,3 segundos a aproximadamente uno. El Total Blocking Time cayó de 630 a 70 milisegundos, y el peso de la página de 2.880 a 1.307 kilobytes. Ahora medir la velocidad de carga web toma unos segundos, y lo revisamos con regularidad para que la cifra no vuelva a subir sin que nos demos cuenta. No es solo una cifra de informe: la velocidad es uno de los factores del posicionamiento SEO, y Google posiciona peor un sitio lento.

Por qué 74 y no 100

Otra cifra cambió bastante. El Speed Index, que muestra lo rápido que la página se llena de contenido, bajó de 9,0 a 3,1 segundos. Aun así, la nota no llegó a la zona verde, y esta vez la causa es nuestra. Lo que más la frena es nuestra propia pantalla de introducción en la página principal.

La intro se muestra una vez por sesión, así que quien vuelve ve un sitio rápido. La prueba de Google llega siempre como visitante nuevo y la ve cada vez. De momento dejamos la intro y volveremos al tema cuando crezca el tráfico. Más tarde encontramos otra causa: el título y la imagen de la primera pantalla aparecen con una animación, y hasta que termina, Google los considera invisibles. Sabemos cómo arreglarlo y está planeado para más adelante. Así que, por ahora, aceptamos el 74 a sabiendas.

Cómo comprobar tú mismo la velocidad de tu sitio

Una revisión básica lleva unos minutos y no necesitas a un desarrollador:

• Abre PageSpeed Insights (pagespeed.web.dev), pega la dirección de tu página principal y pasa a la pestaña «Móvil».
• Si arriba hay datos de visitantes reales, empieza por ahí. Esos datos muestran lo que vive la gente; la prueba de laboratorio sirve para buscar la causa.
• Repite la prueba dos o tres veces. La primera suele salir peor porque el servidor o la red todavía no se han «calentado». A nosotros la primera medición de respuesta del servidor nos dio más de 1,5 segundos, y una serie de cinco, alrededor de 0,1.
• Mide el sitio en vivo, no una copia en la computadora del desarrollador. Nuestro caso muestra lo distintos que pueden ser.

Qué revisar en los scripts de terceros

Un script de terceros es código que la página carga desde el servidor de otra empresa. No lo vas a ver en tus archivos, pero tu visitante lo espera igual. Hazle unas cuantas preguntas a cada uno:

• ¿Hace falta en todas las páginas? Un captcha solo tiene sentido donde hay un formulario.
• ¿Se carga con async o defer? Sin ellos, el navegador detiene el procesamiento de la página hasta que el script se descarga y se ejecuta.
• ¿Quién lo añadió? El hosting, un plugin, un gestor de etiquetas o un proveedor con el que dejaste de trabajar hace tiempo. De eso depende dónde se desactiva.
• ¿Cuánto le cuesta a la página? El diagnóstico de PageSpeed muestra el peso de cada script y su tiempo de procesador.

Si prefieres no meterte en esto, un equipo de soporte web puede vigilarlo por ti con regularidad.

Lo que nos llevamos de este caso

La conclusión real de este caso: antes de lanzarte a optimizar tu propio código, revisa primero qué está cargando realmente el sitio en vivo — a veces el script más caro ni siquiera es tuyo. Después hicimos el mismo tipo de desmontaje con la accesibilidad desde el teclado de nuestro sitio, y allí también apareció algo que las revisiones automáticas no mostraban. Si tu sitio se siente lento y no sabes por qué, escríbenos — haremos una auditoria web técnica y te daremos el panorama honesto.

La forma más simple: escríbenos por Telegram o contáctanos.

← Volver al blog