Google dijo que nuestro sitio no era eficiente en móvil. La culpa fue de los contadores
Search Console marcó 102 URL no eficientes en móvil en nuestro propio sitio, y esas mismas 102 aparecían en verde en escritorio. La primera hipótesis, una animación de fondo, no resistió la medición. Los culpables fueron las etiquetas publicitarias, y el detalle más costoso, una segunda copia de la misma biblioteca de 189 KB. Un recorrido completo con números y una guía de seis pasos.
Search Console se encendió con alertas en nuestro propio sitio: 102 URL "no eficaces" en móvil, y esas mismas 102 en verde en escritorio. Un sitio, un diseño, dos veredictos. Investigamos, la primera hipótesis obvia resultó ser incorrecta, y el culpable era algo que está en casi todos los sitios y que sus dueños rara vez consideran parte del sitio. A continuación encontrarás toda la investigación con mediciones, y una guía para comprobar y corregir el tuyo.
Qué mide realmente Google
La métrica es INP (Interaction to Next Paint). Google la describe así:
"INP es una métrica que evalúa la capacidad de respuesta general de una página a las interacciones del usuario, observando la latencia de todos los clics, toques e interacciones con el teclado que ocurren durante toda la vida de una visita del usuario a la página."
Umbrales: bueno es 200 ms o menos, necesita mejorar es de 200 a 500 ms, deficiente es más de 500 ms.
web.dev, documentación de INPLo esencial que debe entender un propietario: INP no mide la velocidad de carga. Mide cuánto tarda la pantalla en responder visiblemente después de un toque. Una página puede abrirse en un segundo y aun así ser "no eficaz" si, una vez abierta, está ocupada consigo misma y no puede responder a un dedo.
Y lo segundo importante: es una métrica de campo. Google la recopila de visitantes reales, no de una prueba de laboratorio. Por eso el informe se actualiza con retraso y sobre una ventana móvil: no habrá un verde instantáneo después de una corrección.
Por qué móvil está en rojo y escritorio en verde
La respuesta es aburrida y explica del todo la diferencia: el procesador de un teléfono es de cuatro a ocho veces más lento que el de un equipo de escritorio. El mismo bloque de trabajo que toma 60 ms en una laptop y pasa desapercibido se estira a 300–500 ms en un teléfono, y la persona ya ve el botón "atascado". El diseño no tiene nada que ver: el código es idéntico, solo cambia la velocidad con la que se ejecuta.
La primera hipótesis era incorrecta
Nuestra página de inicio tiene una animación de fondo, y la sospecha recayó en ella de inmediato, como sucederá con la mayoría de los propietarios: "algo en el sitio se mueve, así que eso es lo que lo ralentiza". En lugar de desactivarla y esperar lo mejor, medimos tres variantes de la misma pantalla: tal cual, con la animación desactivada y con las etiquetas de terceros bloqueadas.
Lo que medimos no fue una sensación sino una cantidad concreta, el tiempo de bloqueo del hilo principal: la suma de cuánto exceden las tareas largas los 50 ms. Mientras se ejecuta una tarea así, el navegador no puede responder a un toque, y de eso se compone exactamente el INP.
El resultado zanjó la cuestión. Desactivar la animación no aportó nada: 1840 ms frente a 1782 ms tal cual, una diferencia dentro del ruido y formalmente incluso peor. En cambio, bloquear las etiquetas de terceros redujo el tiempo de bloqueo de 1782 a 378 ms. El 79% del tiempo en que la página no podía responder al toque de un dedo no lo generó ni nuestro código ni la animación.
El verdadero culpable
Había cuatro etiquetas en el <head>, las cuatro estándar, de las que un propietario instala y olvida: un contador de analítica, una etiqueta de una plataforma publicitaria y dos píxeles de redes sociales. Todas con el atributo async, todas "sin bloqueo". En total, unos 600 KB de JavaScript de terceros.
Y entonces viene lo que hace que valga la pena leer esta sección. Una biblioteca de contador de 189 KB se descargó y se ejecutó dos veces.
El motivo es mundano. Tenemos dos identificadores: analítica y publicidad. Para cada uno, la plataforma entrega un fragmento ya listo con su propia línea de carga, y el propietario pega ambos con toda diligencia. Pero la biblioteca que contienen es una y la misma: atiende cada identificador mediante llamadas de configuración separadas. La segunda copia no aporta nada: simplemente se descarga de nuevo, se analiza de nuevo y se ejecuta de nuevo en ese mismo procesador móvil lento.
Si tienes tanto analítica como una cuenta publicitaria de la misma plataforma, es muy probable que veas el mismo panorama. Comprobarlo lleva un minuto: el método está en el paso 3 más abajo.
Por qué "async" no te salva
Este es el segundo lugar donde la intuición engaña. El atributo async significa: "no retrases el análisis del HTML, descarga en paralelo". Cumple su función con honestidad: la página se renderiza sin esperar a la etiqueta.
Pero una vez que el archivo se ha descargado, todavía hay que ejecutarlo, y se ejecuta en el mismo hilo principal que responde a los toques. async elimina el bloqueo del análisis, pero no la ocupación del hilo, y eso es justo lo que mide INP. De ahí la situación habitual: la página apareció rápido, todos los contadores son "asíncronos" y la métrica está en rojo.
Una trampa más: aplazar la carga por sí solo no cambia nada
La solución obvia es aplazar las etiquetas hasta que el navegador esté libre. Eso fue lo que hicimos. Y lo medimos.
El tiempo de bloqueo solo con el aplazamiento fue de 2101 ms frente a 2026 ms antes, es decir, ligeramente peor. La lógica es simple: aplazar mueve el trabajo en el tiempo, no lo elimina. El trabajo no ha desaparecido, simplemente se ejecuta más tarde, a veces justo cuando la persona ya ha empezado a tocar la pantalla.
Lo que funcionó fue otra cosa: eliminar la segunda copia de la biblioteca. Después de eso, el tiempo de bloqueo bajó a 1775 ms y todo lo demás mejoró: el primer renderizado pasó de 1128 a 824 ms y la respuesta del servidor, de 669 a 335 ms.
Qué hacer con tu propio sitio: seis pasos
A continuación tienes un orden en el que cada paso tiene sentido después del anterior. Cada uno incluye una comprobación que te indica que lo has superado.
Confirma que el problema es tuyo
Abre la sección Core Web Vitals en Search Console y mira la pestaña de móvil por separado de la de escritorio. Por separado es la clave: "móvil en rojo, escritorio en verde" es la forma más común de este problema, y si solo miras el resumen es fácil pasarla por alto.
Si la pestaña de móvil está en verde, puedes dejar de leer: no tienes este problema.
Mide en lugar de adivinar
El error principal en este paso es empezar a apagar todo lo que parezca pesado. Estuvimos a punto de apagar una animación que no tenía nada que ver. Mide tres variantes de la misma página: tal cual, sin el sospechoso y sin etiquetas de terceros.
La forma más accesible es Chrome DevTools: la pestaña Performance, con CPU throttling a 4× y emulación móvil. Graba entre 10 y 15 segundos de vida de la página y revisa las tareas largas. Aparecen resaltadas y cada una indica qué archivo la generó.
Revisa si alguna biblioteca se carga dos veces
Es la victoria más barata de la lista. Abre la pestaña Network en DevTools, filtra por js y revisa la lista: ¿aparece dos veces el mismo nombre de archivo con distintos parámetros en la dirección?
El caso típico es un contador de analítica y una etiqueta de anuncios de la misma plataforma: distintos snippets, un solo archivo. Deja una única línea de carga y configura el segundo identificador como una llamada de configuración aparte. No se pierde nada: la biblioteca atiende ambos.
<!-- antes: dos snippets, la misma biblioteca dos veces -->
<script async src="…/tag.js?id=ID-1"></script>
<script async src="…/tag.js?id=ID-2"></script>
<!-- después: una biblioteca, tantos identificadores como necesites -->
<script async src="…/tag.js?id=ID-1"></script>
<script>
config('ID-1');
config('ID-2');
</script>
Difiere las etiquetas sin perder un solo evento
Solo después del paso 3, porque diferir por sí solo no ayuda, como medimos. En combinación, en cambio, libera los primeros segundos críticos.
La idea: saca los archivos externos de <head> y cárgalos con el primero de tres eventos: que el hilo principal quede libre, que pasen 3 segundos o el primer toque en la pantalla. El toque es obligatorio en esa lista: si la persona ya está interactuando con la página, la etiqueta se necesita de inmediato, de lo contrario pierdes justo la sesión activa.
En el proceso no se pierden eventos, y este es el detalle clave. Unas pequeñas funciones de relleno (stub) permanecen en <head> y ponen en cola cada llamada; cuando la biblioteca por fin se carga, reproduce la cola completa. Así están diseñados estos snippets: la cola está prevista por sus propios autores.
Vuelve a medir y no esperes el verde inmediato
Después del lanzamiento, repite la medición del paso 2: deberías ver que baja el tiempo de bloqueo. Sin embargo, el informe de Search Console no se pondrá verde de inmediato: se basa en datos de visitantes reales en una ventana móvil y se actualiza con un retraso de semanas.
Eso es normal y no es motivo para revertir la corrección ni para apilar una segunda encima. La medición de laboratorio dice que mejoró, así que los datos de campo lo confirmarán más tarde.
Si no ayudó: la reserva
Cuando las etiquetas de terceros están en orden y la métrica sigue mal, los siguientes movimientos, de mayor a menor beneficio, son: contadores redundantes que duplican el propósito de otros, CSS sin usar (en nuestra página principal el 92% de las reglas nunca se aplica) y caché de HTML, si la página se sirve sin ninguna caché.
Por separado, vale la pena preguntarse con honestidad si necesitas todos los contadores que tienes conectados. Cada uno es código ajeno que se ejecuta en el teléfono de tu visitante mientras espera a que se registre un toque.
Qué no hacer
En resumen
"No es eficaz en móvil mientras que en escritorio está en verde" casi siempre significa una sola cosa: la página está ocupada ejecutando código de terceros en el lento procesador de un teléfono. En nuestro caso, las etiquetas de terceros representaron el 79% del tiempo de bloqueo, y el detalle pequeño más costoso resultó ser una segunda copia de la misma biblioteca de 189 KB, cargada simplemente porque el snippet se copia una vez por cuenta.
Si haces una sola cosa ahora mismo: abre la pestaña Network en tu propio sitio y comprueba si algún archivo de contador se descarga dos veces. Es una revisión de un minuto y es gratis.
El rastreo informa de páginas pesadas, scripts bloqueantes y el resto de hallazgos técnicos, clasificados por gravedad.
Preguntas frecuentes
¿Qué es INP en palabras sencillas?
Es el tiempo que pasa desde que tocas la pantalla hasta que la página responde de forma visible. Google considera bueno un valor de 200 ms o menos y deficiente uno de más de 500 ms. La métrica evalúa la capacidad de respuesta, no la velocidad de carga: una página puede abrirse rápido y aun así tardar mucho en responder a un toque.
¿Por qué un sitio no es eficaz en móvil pero sí en escritorio?
Porque el procesador de un teléfono es entre cuatro y ocho veces más lento que el de un equipo de escritorio. El mismo script que pasa inadvertido con 60 ms en una computadora se alarga a 300–500 ms en un teléfono, y la persona nota el retraso. El código es idéntico: solo cambia la velocidad con la que se ejecuta.
¿Es cierto que la analítica ralentiza un sitio?
En nuestra medición, las etiquetas de terceros representaron el 79% del tiempo de bloqueo del hilo principal: 1782 ms con ellas frente a 378 ms sin ellas. Eso no es motivo para eliminar la analítica por completo, pero sí para revisar cuántas etiquetas tienes, si se duplican entre sí y cuándo exactamente se cargan.
¿Async ayuda en un script de analítica?
En parte. El atributo async elimina el bloqueo del análisis del HTML, por lo que la página se muestra antes. Pero el archivo descargado se sigue ejecutando en el hilo principal, y INP mide la ocupación de ese hilo. Un script async puede perjudicar la métrica igual que uno normal.
¿Se pueden diferir los contadores sin perder conversiones?
Sí, si dejas en el head funciones de reemplazo que pongan las llamadas en cola hasta que se cargue la biblioteca: así están diseñados estos snippets. Asegúrate de incluir el primer toque entre los eventos que activan la carga, de lo contrario podrías perder una sesión activa. Después de publicar, verifica que los eventos estén llegando.
¿Cuánto tarda en ponerse en verde el informe de Search Console después de una corrección?
No es inmediato. La métrica se recopila de visitantes reales durante una ventana móvil y se actualiza con un retraso de semanas. Apóyate en tu propia medición de laboratorio: si el tiempo de bloqueo ha bajado, el dato de campo lo confirmará más adelante.
Fuentes
Medición propia de PromoPilot, 28 de agosto de 2026: emulación de Pixel 5 con la CPU limitada 4×, observación de tareas largas y de la latencia de toque en el sitio en vivo.
web.dev, documentación de INP: la definición, los umbrales de bueno / necesita mejorar / deficiente y el carácter de campo de la medición.
Google Search Console, el informe de Core Web Vitals: pestañas separadas para dispositivos móviles y de escritorio.
