Por qué tu sitio está lento en el celular y cómo arreglarlo

En tu laptop tu sitio carga bien. Ese es el problema.

Tú hiciste el sitio, o le pagaste a alguien. Lo abres en la oficina con Wi-Fi y aparece al instante. Se ve bien. Listo.

Tus clientes no lo ven así. Lo ven en el celular. Parados en un cuarto de lavado inundado en Fontana. Sentados en la troca, con calor, en Irvine, esperando un presupuesto de aire acondicionado. Una rayita de señal, un teléfono de hace dos años y cero paciencia.

Esa es la versión de tu sitio que importa. Y en ese celular, muchos sitios de contratistas se arrastran. Aquí te explico cómo revisar el tuyo en cinco minutos, qué significan los números y qué arreglos sí funcionan, del más barato al más caro.

Los celulares sí son más lentos. Los datos lo dicen.

HTTP Archive publica el Web Almanac, un estudio anual de millones de sitios con datos reales de usuarios de Chrome. Su capítulo de rendimiento de 2025, con datos de julio de 2025, encontró una diferencia clara entre celular y computadora:

Fíjate en la primera fila. Más de la mitad de los sitios no pasan las pruebas de velocidad y estabilidad de Google en celular. En 2024 era 44%, así que va mejorando. Despacito.

El mismo estudio midió cuánto pesan las páginas. La página de inicio típica en celular en 2025 pesaba como 2.56 MB. De eso, 911 KB eran imágenes y otros 632 KB eran JavaScript. Es mucho que mandar por una señal débil antes de que el cliente vea tu número de teléfono.

Los tres números que le importan a Google

Google agrupa la velocidad en tres medidas llamadas Core Web Vitals. Esto es lo que significa cada una, con la línea de "bueno" que da Google en web.dev:

Un detalle importante. Google mide esto en el percentil 75 de las visitas reales, separando celular y computadora. O sea, no cuenta tu mejor visita con el Wi-Fi de la oficina. Cuenta lo que le toca a la mayoría de tus visitantes, incluyendo los que tienen mala señal.

¿La velocidad afecta tu posición en Google?

Respuesta corta: cuenta, pero no lo es todo.

La documentación de Google Search Central dice que tener buenas Core Web Vitals va de acuerdo con lo que sus sistemas de ranking buscan premiar, y Google recomienda mucho que los dueños de sitios lleguen a calificaciones buenas para tener éxito en la búsqueda. Google no publica cuánto pesa la velocidad comparada con el contenido, las reseñas o tu Perfil de Negocio. Nadie fuera de Google sabe ese número, así que no le creas a quien te dé uno.

La forma práctica de verlo: la velocidad no salva un sitio sin páginas de servicios y sin reseñas. Pero un sitio lento desperdicia los clics que ya te ganaste. Si estás trabajando en salir en Google Maps (en inglés), un sitio rápido es parte de terminar el trabajo.

Revisa tu sitio en 5 minutos

1. Abre PageSpeed Insights (la herramienta gratis de Google) y pega la dirección de tu página de inicio.
2. Mira primero la pestaña Mobile (celular). Por algo es la que sale primero.
3. Arriba busca la sección de datos de usuarios reales. Si tu sitio tiene suficiente tráfico, vas a ver LCP, INP y CLS con aprobado o reprobado. Esos son los datos que usa Google.
4. Si no hay datos reales, solo vas a ver la calificación de prueba de laboratorio. Úsala como guía, no como calificación final.
5. Baja a los diagnósticos. Apunta los tres primeros. Casi siempre te dicen exactamente qué imagen o script te está frenando.
6. Ahora la prueba de verdad. Saca tu celular, apaga el Wi-Fi y abre tu sitio. Cuenta cuánto tarda en aparecer tu número de teléfono y poder marcarle.

Hazlo con tu página de inicio y con tu página de servicio principal. Esas son las páginas a donde llega la gente desde Google.

Los culpables de siempre en sitios de contratistas

La mayoría de los sitios lentos de oficios fallan por las mismas razones. Esto es lo que señalan las guías de web.dev de Google, aplicado a lo que se ve en un sitio típico de contratista.

1. Una foto gigante arriba

El Web Almanac encontró que el elemento principal que carga (el LCP) es una imagen en el 76% de las páginas en celular. En un sitio de contratista casi siempre es la foto grande de la troca o de un trabajo, tal como salió de la cámara. Si pesa varios megas y no está comprimida, ahí está tu problema de LCP.

2. Carga diferida en la imagen de arriba

La carga diferida (lazy loading) le dice al navegador "espérate con esta imagen hasta que se necesite". Sirve para las fotos de más abajo. Para la de arriba es mala idea. web.dev lo dice claro: nunca uses carga diferida en tu imagen LCP. En una prueba vieja de web.dev con una página de ejemplo, quitar la carga diferida de las imágenes de arriba bajó el LCP en celular como 18%.

3. Hosting lento

Antes de que se vea algo, tu servidor tiene que responder. Esa espera se llama TTFB. Solo el 44% de las páginas en celular la tenían buena en el Almanac 2025. El hosting compartido barato, demasiadas redirecciones y no tener CDN suman. El consejo de web.dev: menos redirecciones y usa un CDN.

4. Demasiados plugins y scripts

Ventanas de chat, carruseles de reseñas, píxeles de rastreo, constructores de páginas, animaciones. Cada uno agrega JavaScript. Algunos no dejan que la página se vea hasta que terminan de cargar. Solo el 15% de las páginas en celular pasó la prueba de Lighthouse de recursos que bloquean la carga en 2025.

5. Cosas que brincan

web.dev menciona las causas más comunes de que la página brinque: imágenes sin medidas, anuncios, videos incrustados e iframes sin medidas, contenido que se mete después de cargar, y las fuentes web. En un sitio de contratista muchas veces es el widget de reseñas o el mapa de Google que aparece tarde y empuja tu botón de "Llama ya" justo cuando alguien lo va a tocar.

Lista de arreglos, del más barato al más caro

Los primeros cinco los puedes hacer tú, o tu persona de web en una tarde. Vuelve a probar en PageSpeed Insights después de cada uno. Los datos de usuarios reales tardan unas semanas en actualizarse, así que revisa otra vez en un mes.

Una nota sobre fetchpriority: web.dev dice que se lo pongas a la imagen que más probablemente sea tu LCP, y solo a una o dos imágenes. Si se lo pones a todas, deja de servir.

Cuándo dejar de parchar y rehacer

Los parches funcionan cuando el sitio está bien hecho de base. Dejan de funcionar cuando:

• El tema o el constructor de páginas carga más código del que necesita toda tu página.
• Cada arreglo descompone otra cosa.
• Tu persona de web no puede (o no quiere) mover el hosting.
• El sitio está lento y además le falta lo básico: páginas de servicios, el teléfono bien visible arriba, un formulario de presupuesto. Eso es un problema más grande que la velocidad. Lo explicamos en errores comunes en sitios de contratistas (en inglés).

En ese punto, rehacer el sitio limpio muchas veces sale más barato que otra ronda de plugins que prometen acelerar los plugins que ya tienes.

Cómo lo hace NOCTURNE

Hacemos sitios web para contratistas (en inglés) pensando primero en el celular. Los probamos en un teléfono de verdad con el Wi-Fi apagado, no solo en un monitor grande. Las fotos se ajustan y se comprimen, la imagen de arriba carga primero, y el teléfono y el formulario de presupuesto aparecen antes que cualquier cosa elegante.

Si quieres ver cómo se vería para tu negocio, hacemos un demo gratis: una página real en un link en vivo en 24 horas, después de una llamada de 10 minutos. Si prefieres no hacer la llamada, son $50 y se te acreditan al lanzamiento. Launch empieza en $1,500: una página en tu dominio, en vivo en 5 días. El dominio, la cuenta y los archivos son tuyos. Los precios están en la página de precios (en inglés), o empieza con una auditoría gratis (en inglés).

Preguntas

Fuentes

• Web Vitals (web.dev, Google Chrome team)
• Understanding Core Web Vitals and Google search results (Google Search Central)
• Performance chapter, 2025 Web Almanac (HTTP Archive, July 2025 data)
• Page Weight chapter, 2025 Web Almanac (HTTP Archive)
• Optimize Largest Contentful Paint (web.dev)
• Optimize Cumulative Layout Shift (web.dev)
• The performance effects of too much lazy loading (web.dev, 2022)