Rendimiento
Web rápida en el móvil: cómo medirla y qué la hace lenta
Quien busca un negocio local suele hacerlo desde el móvil, muchas veces de camino y con datos. Si la web tarda, vuelve atrás y toca el siguiente resultado. Que una web «se vea» en el móvil no es lo mismo que funcione en el móvil. Esta guía explica cómo mide Google la velocidad, cómo comprobarla tú en cinco minutos, qué la hace lenta y qué arreglar primero.
Por qué importa en un negocio local
Una web de negocio local tiene un trabajo muy concreto: que quien la abre sepa en pocos segundos qué haces, dónde estás, si estás abierto y cómo contactarte. Esa persona no está navegando por gusto; suele estar comparando dos o tres opciones con el móvil en la mano. Si tu página tarda en mostrar algo, el botón de volver está más cerca que tu teléfono.
Además, el móvil es el peor escenario técnico: procesadores más lentos que un ordenador, conexión variable y pantalla pequeña. Una web que en el ordenador de la oficina va bien puede tardar el triple en un móvil de gama media con cobertura justa.
Google también lo tiene en cuenta. Indexa las webs a partir de su versión móvil y usa las Core Web Vitals como una de las señales de experiencia de página. No son lo que más pesa para aparecer arriba —el contenido y la relevancia importan más, como se explica en la guía de SEO local—, pero entre dos resultados parecidos, una mala experiencia no ayuda.
Cómo mide Google la velocidad: las Core Web Vitals
Google resume la experiencia de carga en tres métricas, las Core Web Vitals. Las mide con visitas reales de usuarios de Chrome que comparten estadísticas de uso, y para cada una toma el percentil 75: es decir, la página aprueba si al menos tres de cada cuatro visitas cumplen el umbral.
| Métrica | Qué mide | Bueno | Mejorable | Malo |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Lo que tarda en aparecer el elemento más grande de la pantalla, normalmente la foto o el titular principal | ≤ 2,5 s | 2,5–4 s | > 4 s |
| INP (Interaction to Next Paint) | Lo que tarda la página en reaccionar cuando tocas un botón, un menú o un campo | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Cuánto se desplaza el contenido mientras carga | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Qué significan en la práctica
El LCP es la sensación de «ya ha cargado». El INP sustituyó en marzo de 2024 a una métrica anterior (FID) y mide si la web responde con agilidad o se queda congelada un instante cada vez que tocas algo, típico de páginas con mucho código. El CLS es lo que pasa cuando vas a tocar un botón y se desplaza porque ha cargado un anuncio o una imagen encima: molesto y causa toques equivocados.
Hay una cuarta métrica útil para diagnosticar, aunque no forma parte de las tres principales: el TTFB, lo que tarda el servidor en empezar a responder. Si pasa de unos 0,8 segundos, el problema empieza en el hosting antes que en la página.
Cómo comprobarlo tú
No hace falta saber programar para saber si tu web va bien. Hay tres herramientas gratuitas de Google y una prueba manual.
PageSpeed Insights
Abre pagespeed.web.dev, pega la dirección de tu web y mira la pestaña de móvil. Verás dos bloques que conviene no confundir:
- Arriba, los datos de campo («lo que experimentan tus usuarios reales»): vienen de visitas reales de los últimos 28 días. Son los que cuentan para Google. Si tu web tiene poco tráfico, no habrá suficientes datos y no aparecerán.
- Abajo, los datos de laboratorio (Lighthouse): una prueba simulada en ese momento, con un móvil de gama media y una conexión lenta. La puntuación de 0 a 100 sale de aquí. Sirve para encontrar problemas aunque no tengas tráfico, pero varía de una prueba a otra.
- Debajo de la puntuación, la lista de «diagnósticos» señala qué archivos pesan más y qué bloquea la carga. Es el punto de partida para arreglar.
Search Console
Si tienes tu web dada de alta en Google Search Console, el informe «Métricas web principales» agrupa tus páginas en buenas, mejorables y malas, por separado en móvil y ordenador, con datos reales. Es útil para ver si un problema afecta a toda la web o sólo a un tipo de página, y para confirmar que un arreglo ha funcionado (tarda unas semanas en reflejarse, porque los datos son de 28 días).
La prueba del móvil con datos
Apaga el wifi, abre tu web en tu propio móvil con datos, desde una pestaña privada para que no tire de la caché, y cuenta. Si a los tres segundos no sabes qué negocio es y cómo llamar, el cliente tampoco. Después intenta hacer lo que haría un cliente: llamar, ver el horario, abrir la ruta, reservar. Cada cosa que cueste encontrar es un cliente que se pierde.
No te obsesiones con sacar 100 en la puntuación de laboratorio. Lo que importa es que los datos reales estén en verde y que la web se use bien en un móvil corriente.
Lo que suele hacerla lenta
En la mayoría de webs de negocios pequeños, la lentitud viene de unas pocas causas repetidas:
- Imágenes enormes: una foto sacada del móvil pesa entre 3 y 8 megas y mide 4.000 píxeles de ancho. En una pantalla de móvil se muestra a unos 400 o 800 píxeles, y debería pesar decenas o pocos cientos de kilobytes.
- Carruseles de portada: cargan cinco imágenes grandes para enseñar una, añaden código para moverlas y casi nadie pasa de la primera.
- Vídeo de fondo: pesa mucho, gasta datos del cliente y en muchos móviles ni se reproduce o se ve como una imagen fija.
- Demasiados plugins: en webs hechas con WordPress y similares, cada plugin puede añadir sus propios archivos en todas las páginas, se use o no.
- Widgets de terceros: chat en vivo, botones de redes, contadores, píxeles de publicidad y avisos de cookies pesados. Cada uno descarga y ejecuta su propio código, y suelen ser lo que estropea el INP.
- Mapas y vídeos incrustados: un mapa de Google o un vídeo de YouTube incrustado descargan cientos de kilobytes de código aunque nadie los toque.
- Tipografías: cargar cuatro familias con seis grosores cada una se nota. Dos familias con un par de grosores bastan.
- Hosting barato y saturado: si el servidor tarda un segundo en empezar a responder, nada de lo demás lo compensa.
Cómo arreglarlo, por orden de impacto
No hace falta rehacer la web para mejorar mucho. Este orden suele dar más resultado con menos esfuerzo:
1. Las imágenes
Es casi siempre lo primero y lo que más se nota.
- Formato moderno: WebP o AVIF pesan mucho menos que JPG o PNG con la misma calidad, y todos los navegadores actuales los admiten.
- Tamaño real: redimensiona a lo que se muestra. Una foto a ancho completo en el móvil rara vez necesita más de 1.200 a 1.600 píxeles de ancho, y la web puede servir varias versiones para que cada pantalla descargue la suya (atributos srcset y sizes).
- Ancho y alto declarados: cada imagen debe indicar sus dimensiones para que el navegador le reserve el hueco. Es la forma más simple de evitar saltos (CLS).
- Carga diferida: las imágenes que están más abajo deben cargar sólo cuando el usuario se acerca (loading="lazy"). La imagen principal de arriba, al contrario, no debe ser diferida: es la que marca el LCP y conviene darle prioridad.
2. Los terceros
Haz inventario de todo lo que carga la web desde otros servicios y pregúntate si cada cosa se usa:
- Mapa: en lugar del mapa incrustado, una imagen estática del plano con un enlace que abra Google Maps o la app de mapas. Al cliente le sirve más, porque abre la ruta directamente.
- Vídeo: muestra una miniatura con botón de reproducir y carga el reproductor sólo cuando se toca.
- Chat: si no lo atiendes en el momento, un botón de WhatsApp o un enlace de contacto hace lo mismo sin cargar código en cada visita.
- Píxeles y etiquetas: quita los de campañas que ya no haces.
3. El servidor y la caché
Que el servidor responda rápido y que el navegador no vuelva a descargar lo que ya tiene:
- Caché de página: si la web se genera en cada visita (como un WordPress sin caché), un sistema de caché o páginas generadas de antemano reducen el tiempo de respuesta a una fracción.
- Caché del navegador: imágenes, estilos y tipografías deben enviarse con una caducidad larga para que la segunda visita sea casi instantánea.
- Compresión: el servidor debe comprimir el texto (gzip o Brotli) y usar HTTP/2 o HTTP/3.
- CDN: una red de distribución sirve los archivos desde un punto cercano al visitante. Para un negocio con clientes en una sola ciudad y un servidor en Europa, ayuda pero no es imprescindible.
4. Tipografías y código
Aloja las tipografías en tu propio servidor, carga sólo los grosores que usas y asegúrate de que el texto se muestra con una fuente de sistema mientras llega la definitiva (font-display: swap). Quita los plugins que no usas y evita los constructores visuales que generan mucho código para cosas simples.
Lo que necesita ver quien te busca desde el móvil
La velocidad es la mitad. La otra mitad es que lo importante esté a un toque y se pueda usar con el pulgar:
- Un botón para llamar que marque directamente (un enlace tel:), visible sin desplazarse, y otro para escribir si atiendes por WhatsApp o correo.
- La dirección enlazada a Maps, para que abra la ruta, y una indicación de cómo llegar o dónde aparcar si es útil.
- El horario, con el de hoy fácil de ver, y los festivos o cierres especiales.
- La carta, los precios o los servicios en texto, no en un PDF que hay que descargar y ampliar, ni en una foto de la carta de papel.
- Texto de al menos 16 píxeles y con buen contraste, legible al sol sin hacer zoom.
- Botones y enlaces grandes y separados. La norma de accesibilidad WCAG 2.2 pide un mínimo de 24 por 24 píxeles; para botones principales es mejor rondar los 44 a 48 píxeles.
- Nada que tape la pantalla al entrar: ventanas emergentes de suscripción o banners enormes de cookies que obligan a buscar la «x».
Formularios que se rellenan en el móvil
Un formulario de contacto o de reserva es donde más clientes se pierden en el móvil. Algunas reglas sencillas:
- Pide lo mínimo: nombre, teléfono o correo y el mensaje. Cada campo de más reduce los envíos.
- Usa el tipo de campo correcto para que el móvil muestre el teclado adecuado: numérico para el teléfono, con arroba para el correo.
- Activa el autocompletado para que el móvil rellene nombre, teléfono y correo con un toque.
- Etiquetas visibles encima de cada campo, no sólo un texto gris dentro que desaparece al escribir.
- Campos con letra de 16 píxeles o más: en iPhone, si es menor, la página se amplía sola al tocar el campo y descoloca la vista.
- Un mensaje claro al enviar, que confirme que ha llegado y cuándo vas a responder.
Si el formulario es para reservar, la guía de reservas online explica qué sistema elegir y cómo evitar que te hagan reservas que no puedes atender.
Lista de comprobación
Repasa esto con tu web en un móvil, con datos, y con PageSpeed Insights abierto:
- Los datos reales de PageSpeed Insights o Search Console están en verde en móvil (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1).
- Ninguna imagen pesa más de unos 200 a 300 KB, y están en WebP o AVIF.
- Las imágenes tienen ancho y alto definidos, y las de abajo cargan de forma diferida.
- No hay carrusel ni vídeo de fondo en la portada.
- El mapa y los vídeos no se cargan hasta que se tocan.
- Sólo quedan los plugins, widgets y píxeles que usas.
- El servidor responde en menos de un segundo y los archivos se sirven con caché.
- Llamar, abrir la ruta y ver el horario se hace con un toque desde la primera pantalla.
- El texto se lee sin hacer zoom y los botones se tocan con el pulgar sin fallar.
- El formulario se rellena con autocompletado y confirma el envío.
Es mucho más fácil hacer una web rápida que acelerar una lenta. Las webs de AMG Design parten de páginas generadas de antemano, sin plugins y con las imágenes optimizadas al publicar, y se comprueban con estas métricas antes de entregarlas.
Preguntas frecuentes
¿Qué puntuación de PageSpeed debería tener mi web?
La puntuación de 0 a 100 es una prueba de laboratorio y varía de una ejecución a otra. Lo que importa a Google son los datos reales de campo: que LCP, INP y CLS estén en verde. Por encima de 90 en móvil está muy bien, pero una web en 75 con datos reales en verde no tiene un problema.
¿Por qué PageSpeed Insights no muestra datos reales de mi web?
Porque los datos de campo salen de visitas reales de Chrome y hacen falta suficientes en los últimos 28 días. Las webs con poco tráfico no los tienen. En ese caso, guíate por la prueba de laboratorio y por la prueba con tu propio móvil.
¿La velocidad de la web influye en el posicionamiento en Google?
Sí, pero poco comparado con el contenido y la relevancia. Las Core Web Vitals son una de las señales de experiencia de página. Donde más se nota la velocidad es en los clientes que se van antes de que cargue.
¿Cuánto debería pesar una imagen en la web?
Una foto grande de portada, entre 100 y 300 KB en WebP o AVIF; las miniaturas, decenas de KB. Si una imagen pesa más de 1 MB, casi seguro que se puede reducir sin que se note la diferencia.
¿El mapa de Google incrustado ralentiza la web?
Sí: descarga bastante código aunque nadie lo use. Una imagen del plano con un enlace a Google Maps es más ligera y más útil, porque abre la ruta en la app de mapas del móvil.
¿Mi web hecha con WordPress puede ser rápida?
Puede, con un buen hosting, un sistema de caché, pocos plugins, un tema ligero y las imágenes optimizadas. Lo que la hace lenta no suele ser WordPress en sí sino la acumulación de plugins y constructores visuales.