Velocidad y móvil

Velocidad y móvil son la misma conversación. El 71% del tráfico de Google a un restaurante llega desde el teléfono, y el índice «mobile first» de Google es el canónico desde 2021 — la versión de escritorio del sitio es una cortesía, la versión móvil es el producto. La cuenta es simple y poco amable: cada segundo de LCP te cuesta aproximadamente el 7% de los visitantes potenciales que se van antes de que la página sea interactiva, y Google te baja en el local pack encima de eso.

La buena noticia: la velocidad es el lado más arreglable de un sitio de restaurante independiente. Tres números hacen casi todo el trabajo — LCP (largest contentful paint), CLS (cumulative layout shift), INP (interaction to next paint) — y tres patrones causan el 80% de las regresiones: hero photos pesadas, JavaScript que bloquea el render y fuentes que llegan después del primer paint. Arregla esos tres, corre Lighthouse, envía.

Las tres Core Web Vitals, en español llano

Core Web Vitals es el nombre que Google le da a sus tres métricas medibles de experiencia de usuario. Cada una tiene un umbral «bueno»; fallar cualquiera en el percentil 75 de tus visitantes reales te cuesta puntos de ranking en el local pack y en los SERPs regulares.

• LCP ≤ 2.5s. Largest contentful paint — cuánto tarda hasta que la cosa visible más grande de la página (normalmente tu hero) termina de renderizar. La meta del plan de lanzamiento es más estricta (≤2.0s) porque el sitio apunta al cuartil superior, pero la banda «buena» de Google empieza en 2.5. Por debajo de 2.5s estás en verde; por encima de 4.0s estás en rojo y perdiendo visitantes a la vista.
• CLS ≤ 0.1. Cumulative layout shift — cuánto se mueven las cosas en la página después del primer paint. Causa más común: imágenes sin atributos explícitos de width y height. Arreglo: configura width y height en cada img y usa aspect-ratio en CSS. La meta del plan es ≤0.05 porque el feel visual es la marca.
• INP ≤ 200ms. Interaction to next paint (reemplazó al FID en marzo de 2024) — cuánto tarda la página en responder a un tap. INP es el asesino para herramientas y widgets de reserva; si tu botón «Reservar» tarda 400ms en reaccionar, el visitante hace doble tap y arranca un flujo de reserva duplicado. Arreglo: defer en JS no crítico, code-splitting y evitar el bloqueo del main thread por widgets de terceros.

Puedes leer tus CWV en tres lugares: PageSpeed Insights (sintético más 28 días de field data de Chrome real), el reporte «Core Web Vitals» de Search Console (solo field data, pero reportada por grupo de URL) y Plausible si conectaste web-vitals del lado del cliente. La herramienta gratis Speed Test corre la versión sintética sobre cualquier URL.

Por qué el móvil es distinto

El móvil no es solo «el mismo sitio, pantalla más chica». La red móvil es más lenta, el CPU más débil, la batería es restricción y el contexto del visitante es «estoy caminando, tengo hambre, a tres cuadras». Tres implicaciones:

• La velocidad de red es la restricción. El preset móvil de Lighthouse simula Slow 4G — ~1.6 Mbps con 150ms de RTT y 4× de throttle de CPU. Eso es el techo, no el piso. La realidad móvil del DMV (entre las cuatro carriers principales) es aproximadamente Slow 4G en horarios de commute, casi LTE los fines de semana. Construye para el peor caso.
• Las hero images son la fuga. La foto de pasta de 4MB que carga en 200ms en el wifi de tu oficina tarda 6 segundos en Slow 4G. Cambiar a AVIF con fallback WebP la baja a 200KB sin perder calidad visible. La hoja de especificaciones de fotos cubre las metas de tamaño de archivo.
• El UX móvil es de una sola columna. Los layouts de hero a dos columnas que se ven elegantes en una laptop de 14 pulgadas se vuelven ilegibles apilándose en un teléfono de 360px. Construye el layout móvil primero, expande a escritorio. Bloque de horarios encima del hero. Botón de reserva como una banda en color primario. Secciones del menú colapsables.

El 80/20 del trabajo de velocidad

Los cinco arreglos que cargan el 80% de las ganancias típicas de velocidad en un sitio de restaurante, ordenados por hora-invertida-a-LCP-recuperado:

1. Comprime y reencodifica la hero image (15 minutos). AVIF primero, WebP de fallback, JPEG como último recurso. Meta: bajo 200KB en 1600×1067. Herramientas: Squoosh, ImageOptim o el soporte AVIF integrado en CDN de imágenes modernos (Cloudinary, ImageKit). La mejora individual más grande de LCP en la mayoría de sitios de restaurantes independientes.
2. Configura width y height en cada imagen (30 minutos). Elimina los saltos de CLS. Usa la relación de aspecto natural de la imagen fuente; CSS aspect-ratio en el padre si la imagen es responsiva. La hoja de especificaciones de fotos lista cada superficie de imagen y su relación de aspecto.
3. Defer al JavaScript no crítico (1 hora). Agrega defer a los script tags que no se necesitan para el primer paint. Widgets de reserva (OpenTable, Resy, Tock), analítica, embebidos de chat. Plausible ya es async, sin cookies y pequeño; la mayoría de tags de terceros no.
4. Self-host de fuentes con font-display: swap (1 hora). Las web fonts que bloquean el primer paint son la segunda causa más común de fallo de LCP. Hostea los archivos woff2 tú mismo, usa font-display: swap, precarga los dos pesos críticos del above-the-fold.
5. Lazy-load a las imágenes debajo del fold (15 minutos). Atributo loading="lazy" en cada img debajo del hero. Ahorra entre 40 y 60% del total de bytes en una página de menú típica donde el visitante nunca scrollea más allá del tercer plato.

Corre la Speed Test gratis en tu URL antes y después de cada arreglo. El puntaje se mueve de inmediato; la señal de field data en Search Console tarda 28 días en rolar.

Lo que ralentiza un sitio de restaurante y nada más

Tres patrones específicos de restaurantes independientes que no aplican a la mayoría de los sitios de pequeña empresa:

• Widgets de reserva. OpenTable, Resy, Tock y las plataformas menores envían bundles de JS de terceros pesados que cargan antes de que el visitante pueda reservar. Las APIs «direct» o «widgets v2» más nuevas de cada plataforma son más pequeñas y rápidas que el embed iframe legacy; cambiar de iframe a direct típicamente ahorra entre 200 y 500ms de LCP. Cómo recuperar reservas cubre los tradeoffs.
• PDFs de menú. Enlazar un PDF de 4MB como la «página» del menú significa que cada visitante que clickea espera a que se descargue todo el PDF antes de ver nada. El arreglo es HTML real — usa Menu Converter para convertir texto pegado del menú en HTML semántico en dos segundos. El menu drop-in de $1,500 entrega la versión estilizada armada por el estudio.
• Videos de fondo. El patrón del hero-video con autoplay que se puso de moda hacia 2018 carga entre 8 y 15MB de video decodificado por JS. En móvil, eso es un asesino de LCP de varios segundos por una pieza de decoración que el visitante nunca pidió. Reemplázalo con un solo AVIF estático y dalo por hecho.

Qué hacer esta semana

Tres acciones, en orden, alrededor de una hora en total:

1. Corre PageSpeed Insights en tu home y en tu página de menú. Lee la sección «Core Web Vitals». Si LCP está sobre 3 segundos o CLS sobre 0.1, tienes un problema accionable. Guarda el resultado.
2. Corre la Speed Test gratis sobre las mismas dos URLs. Los dos reportes se cross-validan; si difieren por más de 0.5s en LCP, suele ser porque tu hero image se está sirviendo desde un cache que una herramienta golpea y la otra no. Trata el peor número como verdad.
3. Elige la hero image más pesada que tengas. Reencodíficala como AVIF. Baja el archivo bajo 200KB. Reemplaza el src del <img>. Vuelve a correr ambas herramientas. El puntaje se mueve; la experiencia del visitante cambia de inmediato.

Operadores que quieren la versión del estudio: la auditoría de $499 incluye el walkthrough de velocidad por Loom; el menu drop-in de $1,500 entrega una página de menú rápida en móvil que cumple por defecto la meta del plan de LCP ≤2.0s; las tiers de build completo entregan cada página debajo de la meta.

Dónde este tema toca a los otros

• Conversiones y Contenido — porque una página rápida es precondición de una página que convierte. La mayoría de las ganancias de conversión se componen sobre las ganancias de velocidad.
• SEO local y descubrimiento — porque Google baja a los sitios móvil-lentos en el local pack. Cuanto más rápido tu sitio, más alto rankeas, más clics tienes para convertir.
• Marca y diseño — porque las decisiones de diseño (hero grande, web fonts, cursores custom) suelen jugar contra la velocidad. Los buenos diseñadores conocen el tradeoff explícitamente; los grandes hacen de la velocidad parte de la marca.

El compuesto a vigilar: el puntaje móvil de Lighthouse. Córrelo cada mes en tu home y en tu página de menú. La línea de tendencia es la única métrica que importa; los números absolutos fluctúan semana a semana.