Creíamos que nuestro sitio era rápido.
Teníamos razones. En nuestra auditoría más reciente de qadigitalpartners.com con PageSpeed Insights de Google, el puntaje de escritorio era 89 de 100. Accesibilidad, 98. Buenas prácticas, 96. SEO, 92. Habíamos construido el sitio con cuidado, con herramientas modernas, código limpio y atención real al rendimiento.
Pero también sabemos cómo trabaja Google: revisa con frecuencia cómo mide los sitios, y lo que hoy se ve bien mañana puede quedarse atrás. Así que no esperamos a llevarnos una sorpresa. Volvemos a auditar nuestro propio sitio con los estándares actuales de Google, igual que lo hacemos con los clientes.
En esa nueva auditoría apareció el problema en el teléfono. El puntaje móvil era 54. El First Contentful Paint era de 9.6 segundos. El Largest Contentful Paint, de 10.3 segundos. En un teléfono de gama media con una conexión 4G, que es como PageSpeed Insights hace su prueba móvil, nuestro sitio tan cuidado hacía esperar a los visitantes casi diez segundos para ver algo importante en pantalla.
Esa diferencia, 89 en escritorio contra 54 en móvil, no es rara. La mayoría de los sitios se construyen, se prueban y se revisan en computadoras portátiles con procesadores rápidos y conexiones muy veloces. La emulación móvil que usa la prueba, un Moto G Power con 4G limitado, saca a la luz problemas que en ese entorno no se ven. El procesador es más lento. La red es más lenta. Los scripts que corren en milisegundos en una portátil tardan segundos en el teléfono. El resultado es un sitio que se siente rápido para quienes lo construyeron y lento para los clientes que quiere convertir.
Este es el relato completo de lo que encontramos, lo que hicimos y lo que mostraron los números después. Lo publicamos porque los problemas que encontramos en nuestro sitio son del mismo tipo que los que encontramos en los sitios de los clientes. Si quieres saber cómo se ve un proceso real de optimización de velocidad, este es el que hicimos con nosotros mismos.
El supuesto
Detrás de cada problema de velocidad hay un supuesto de que el sitio funciona razonablemente bien. Ese supuesto casi siempre se forma en escritorio.
Es fácil formarlo. Nuestra prueba de escritorio en PageSpeed Insights dio 89. La auditoría de Lighthouse en un entorno de desarrollo local dio un poco menos, 82, lo cual es normal porque los puntajes de Lighthouse local varían según tu equipo y tu red. Los dos puntajes apuntaban en la misma dirección: el sitio está bien, el rendimiento no es una crisis, probablemente hay algunas cosas para limpiar, pero nada urgente.
Ese supuesto era incorrecto. No porque el puntaje de escritorio fuera falso o estuviera inflado, sino porque el puntaje de escritorio y la experiencia en el teléfono miden cosas completamente distintas. En escritorio, nuestro sitio tenía un FCP de 1.9 segundos y un LCP de 1.9 segundos. Limpio. En el teléfono, esos mismos números eran 9.6 y 10.3 segundos en PageSpeed Insights.
La lección no es que los puntajes de escritorio no sirvan. Son una señal válida para los visitantes de escritorio. La lección es que un puntaje de escritorio no predice la experiencia en el teléfono. Google indexa principalmente la versión móvil de los sitios, y la experiencia que importa para muchos visitantes es la del teléfono. Un puntaje de laboratorio no equivale a una posición en Google, pero ayuda a encontrar lo que empeora esa experiencia.
Por eso la prueba móvil es una parte permanente de nuestras auditorías, para nuestro sitio y para cada sitio en el que trabajamos. Los estándares cambian. La auditoría tiene que cambiar con ellos.
Lo que mostró Google
La prueba móvil de PageSpeed Insights usa un perfil de emulación concreto: un Moto G Power con una conexión 4G lenta. No es el peor teléfono del mercado. Es un dispositivo de gama media representativo. Limitar la conexión 4G simula condiciones realistas para una parte grande de los usuarios de teléfono.
Nuestros números en ese entorno:
Rendimiento: 54 · Accesibilidad: 95 · Buenas prácticas: 92 · SEO: 92 · FCP: 9.6 segundos · LCP: 10.3 segundos
(Estos números son de PageSpeed Insights sobre qadigitalpartners.com antes de cualquier cambio, documentados con los PDF que guardó Alfonso. Los puntajes de PSI varían entre corridas por las condiciones de la red; los tomamos como el punto de partida documentado, no como una medición científica exacta.)
Un LCP de 10.3 segundos significa que, en la prueba, el contenido principal de la página tardaba más de diez segundos en aparecer. Es mucho tiempo para alguien que acaba de llegar.
Lo que hizo esto más útil que un solo puntaje malo fue la cascada de Lighthouse. La cascada muestra qué se carga, en qué orden y cuánto tarda cada recurso. Podíamos ver exactamente dónde se iba el tiempo. Una vez mirados los datos, los tres problemas más grandes no eran ambiguos. Eran problemas concretos, con nombre y corregibles. La siguiente sección explica cuáles eran.
El diagnóstico
La cascada contó la historia que el puntaje general apenas insinuaba.
El primer y mayor problema era reCAPTCHA. El script de reCAPTCHA v3 de Google se cargaba en cada página, completo, en el momento en que la página se abría. Transfería aproximadamente 1 MB de JavaScript y consumía unos 20 segundos de CPU en la emulación móvil. Lo que más pesaba era el tiempo de CPU: mientras ese script corría, el hilo principal del navegador quedaba bloqueado. Nada más podía dibujarse. El visitante veía una página en blanco o a medio cargar mientras el teléfono procesaba el script.
Era tan costoso porque reCAPTCHA se cargaba siempre, incluso en páginas sin ningún formulario visible. Un visitante que llegaba a la portada a leer sobre nuestros servicios activaba una tarea de CPU de 20 segundos en segundo plano, para un formulario que no había tocado y quizá nunca tocaría. Cuando revisamos el flujo de envío del formulario, encontramos que el token de reCAPTCHA ni siquiera se mandaba a nuestro backend. El script se cargaba, corría y generaba un token que no iba a ningún lado. 1 MB de script y 20 segundos de CPU sin ningún beneficio en la mayoría de las cargas.
El segundo problema eran las imágenes. Teníamos ocho miniaturas JPEG en la sección de clientes de la portada. Cada miniatura se mostraba a 46 por 56 píxeles en el diseño real. Los archivos pesaban unos 40 KB cada uno, con un tamaño pensado para un espacio mucho mayor. En total, esas ocho imágenes transferían unos 320 KB para mostrar algo que, a ese tamaño, casi no aprovechaba esos bytes extra. El navegador descargaba los archivos en resolución completa, los decodificaba y los achicaba al tamaño de miniatura.
El tercer problema era el CSS. La hoja de estilos principal pesaba 47 KB y bloqueaba el dibujo de la página. Con una conexión 4G lenta, el navegador tenía que descargar y procesar toda la hoja de estilos antes de empezar a dibujar. Lighthouse midió ese retraso en aproximadamente 2.1 segundos en la emulación móvil. El LCP, que es el tiempo hasta que aparece el elemento visible más grande, se retrasaba por eso, porque el texto que formaba el LCP no podía dibujarse hasta que terminaba de cargar el CSS.
También había problemas más chicos. Siete enlaces del sitio usaban “Learn More” como texto visible sin aria-labels descriptivos, lo que afectaba el puntaje de SEO. Varias imágenes no tenían width y height explícitos, un riesgo de desplazamiento del diseño (CLS) cuando las imágenes cargan en distintos momentos y empujan el contenido. Faltaba una conexión anticipada (preconnect) para un servicio externo de analítica que el sitio llama al cargar. Y al diseño principal le faltaba un elemento de referencia (landmark), lo que afectaba el puntaje de accesibilidad y el de navegación por agentes.
reCAPTCHA, las imágenes y el CSS explicaban la mayor parte de la diferencia en el teléfono. Los problemas más chicos afectaban los puntajes de accesibilidad y SEO, pero pesaban menos en la velocidad.
Qué corregimos y por qué
Aplicamos las correcciones en dos tandas, el mismo día del diagnóstico.
La primera tanda atacó el problema de las imágenes y varios temas de accesibilidad y SEO. Convertimos las ocho miniaturas de clientes a WebP con 120 px de ancho, el tamaño correcto para cómo se muestran. Los archivos WebP quedaron entre 2 y 5 KB cada uno, frente a unos 40 KB de los JPEG originales. También convertimos a WebP las versiones grandes de esas imágenes, y el peso de esa sección pasó de unos 330 KB a menos de 220 KB contando los dos tamaños. Agregamos width y height explícitos a las ocho miniaturas, lo que elimina el riesgo de desplazamiento al cargar.
También agregamos width y height a otras imágenes que no los tenían: el logo del encabezado, las estrellas de las reseñas, los avatares, los puntos decorativos y el mosaico de fotos. Agregamos aria-labels descriptivos a los siete enlaces “Learn More”, corrigiendo el aviso de la auditoría sin cambiar el texto visible. Agregamos un elemento de referencia al diseño principal, corrigiendo la auditoría de accesibilidad. Agregamos la conexión anticipada al servicio de analítica. Y le pusimos fetchpriority alto a la imagen del encabezado, que es el elemento LCP en escritorio, para que el navegador la cargue antes.
La segunda tanda atacó reCAPTCHA. Modificamos los cuatro formularios del sitio para cargar el script de reCAPTCHA de forma diferida, solo con la primera interacción con un campo de cada formulario. Antes, el script se cargaba al abrir la página aunque el visitante nunca llegara a un formulario. Después del cambio, un visitante que llega a la portada a leer no genera ninguna solicitud de reCAPTCHA. El script solo se carga cuando alguien empieza a usar un formulario. Lo verificamos abriendo el sitio en una sesión nueva del navegador y confirmando que no aparecía ninguna solicitud de reCAPTCHA en la pestaña de red hasta que un campo recibía el foco.
Como hallazgo lateral del trabajo con reCAPTCHA, también confirmamos que el token que generaba el script nunca se mandaba a nuestro backend para validarlo. El script hacía todo su trabajo y generaba un token que el envío del formulario no usaba. Es una decisión para resolver aparte: validar el token en el servidor o quitar reCAPTCHA de los formularios que no lo necesitan. Quedó documentado para ese trabajo. Lo que importaba para la velocidad era la carga diferida: cero script al abrir la página significa cero costo de CPU al abrirla.
Cada cambio tuvo una razón concreta. La carga diferida de reCAPTCHA elimina el bloqueo de 20 segundos de CPU en la mayoría de las cargas. Las miniaturas WebP al tamaño correcto reducen más de 90 por ciento el peso de esos ocho archivos. Los atributos width y height evitan el desplazamiento del diseño. La conexión anticipada reduce la latencia de DNS y de conexión con recursos externos. fetchpriority alto le dice al navegador qué cargar primero sin esperar a sus propias reglas.
El orden respondió al impacto. reCAPTCHA era el mayor contribuyente al tiempo de bloqueo y al tiempo total de CPU en el teléfono. Lo corregimos segundo solo porque la tanda de imágenes era más rápida de implementar y queríamos desplegar una primera tanda verificada antes de pasar a los scripts. Si hubiéramos tenido que hacer una sola cosa, habría sido reCAPTCHA.
Los números
Corrimos Lighthouse en el sitio en vivo después de desplegar las dos tandas. La herramienta, la versión y las condiciones fueron las mismas del punto de partida local que habíamos establecido antes de empezar.
Resultados antes y después (Lighthouse 13.4.1, qadigitalpartners.com, 9 de agosto de 2026):
Móvil: Rendimiento 59 antes, 68 después (+9) · Accesibilidad 95 antes, 100 después (+5) · Buenas prácticas 73 antes, 96 después (+23) · SEO 92 antes, 92 después (sin cambio) · FCP 5.6 s antes, 4.8 s después · LCP 5.6 s antes, 5.2 s después
Escritorio: Rendimiento 82 antes, 91 después (+9) · Accesibilidad 98 antes, 100 después (+2) · Buenas prácticas 100 antes, 100 después (sin cambio) · SEO 92 antes, 92 después (sin cambio) · FCP 1.9 s antes, 1.4 s después · LCP 1.9 s antes, 1.4 s después
Aclaración: todos estos puntajes son de Lighthouse 13.4.1 sobre el sitio en vivo qadigitalpartners.com el 9 de agosto de 2026. Usamos la misma herramienta, la misma versión y las mismas condiciones antes y después. Los puntajes de “antes” son el punto de partida de Lighthouse local; el punto de partida móvil de PageSpeed Insights (PSI, emulación Moto G) mostró 54, que es otro entorno de prueba y no se compara directamente con los puntajes de Lighthouse de después. Los resultados dependen de la arquitectura del sitio, la tecnología y las condiciones iniciales. No usamos estos resultados para prometer mejoras de puntaje en otros sitios.
PageSpeed Insights cerró el ciclo. La misma herramienta que mostró el 54 que empezó todo se corrió otra vez después de desplegar las dos tandas, con la misma emulación móvil. Mostró 73 en el teléfono, con un FCP de 4.1 segundos y un LCP de 4.2 segundos, frente a 10.3. Escritorio pasó de 89 a 97, con tiempo de bloqueo cero. Misma fuente, mismas condiciones, el mismo día: antes a las 3:05 p. m. y después a las 11:33 p. m. (hora del este). Son pruebas de laboratorio, no datos de usuarios reales ni posiciones en Google.
El puntaje de SEO se quedó en 92 después de agregar los aria-labels. Es porque la auditoría de SEO de Lighthouse evalúa el texto de los enlaces por su contenido visible, no por el aria-label. Los siete enlaces siguen mostrando “Learn More” como texto visible. Cambiarlos por textos visibles distintos es una decisión de diseño que corresponde a Alfonso. Los aria-labels corrigen la auditoría de accesibilidad, que subió a 100, pero no la de texto de enlaces de SEO.
El salto de buenas prácticas en el teléfono, de 73 a 96, refleja problemas que se resolvieron con los cambios de imágenes y scripts, incluido el uso de APIs obsoletas que Lighthouse marcaba en algunos scripts de terceros y que dejaron de aparecer de la misma forma con la carga diferida.
En los sitios que revisamos, unos pocos problemas suelen explicar la mayor parte de la diferencia entre el puntaje de escritorio y el del teléfono. El trabajo es encontrarlos y nombrar el mecanismo, no aceptar sin más el texto del aviso de Lighthouse. En nuestro sitio, el mecanismo era un token que cargaba un megabyte de script y bloqueaba el hilo principal en cada carga sin cumplir nunca su función. Eso es lo que saca a la luz un diagnóstico real.
Si quieres saber cómo se ve este proceso aplicado a tu sitio, la página del servicio en www.qadigitalpartners.com/es/optimizacion-velocidad-web explica paso a paso cómo funciona. Escríbenos con la URL de tu sitio y te hacemos una revisión rápida de velocidad gratis: tus puntajes actuales y el problema que más te frena, sin costo.
Preguntas frecuentes
¿Puedo correr PageSpeed Insights por mi cuenta para ver mi puntaje?
Sí. Entra a pagespeed.web.dev, escribe tu URL y corre la prueba móvil. El puntaje que ves es tu punto de partida. Lo que el puntaje no te dice es qué problemas corregir primero. El reporte de Lighthouse detrás del puntaje tiene el detalle, pero leer la cascada y conectar causas con efectos es donde está el trabajo del diagnóstico. Eso es lo que hace la auditoría de velocidad (https://www.qadigitalpartners.com/es/optimizacion-velocidad-web).
Mi sitio carga rápido para mí. ¿Significa que el puntaje está mal?
No. Probablemente lo pruebas desde una portátil con una conexión rápida, que no es lo que mide PageSpeed Insights. PSI emula un teléfono de gama media con 4G. Si tu sitio se construyó y se probó en escritorio, quizá nunca lo cargaste en esas condiciones. La diferencia entre la experiencia en escritorio y la emulación móvil es donde se esconden muchos problemas de velocidad.
¿reCAPTCHA siempre es un problema de velocidad?
Puede serlo, según cómo esté implementado. reCAPTCHA v3 carga un paquete completo de JavaScript al iniciarse. Si se carga al abrir la página, ese paquete corre antes de que la página termine de dibujarse. Si se carga de forma diferida, con la primera interacción con un formulario, la mayoría de los visitantes nunca paga ese costo. El problema en nuestro sitio era la carga incondicional, no reCAPTCHA en sí. La solución fue cambiar la forma de cargarlo, no quitar la herramienta.
¿Formatos de imagen como WebP de verdad hacen una diferencia medible?
Sí, cuando las imágenes también tienen el tamaño correcto para cómo se muestran. En nuestro sitio, las miniaturas eran JPEG pensados para pantallas grandes pero se mostraban a 46 por 56 píxeles. Pasarlas a WebP sin corregir las dimensiones habría ayudado un poco. Pasarlas a WebP con las dimensiones correctas redujo más de 90 por ciento el peso de esos ocho archivos. Importan el formato y las dimensiones.
