Velocidad del sitio web de un dispensario: Core Web Vitals en menús integrados, 2026

La velocidad del sitio web de un dispensario, en la página del menú, depende de tres cifras: Largest Contentful Paint (LCP) en 2,5 segundos o menos, Interaction to Next Paint (INP) en 200 milisegundos o menos y Cumulative Layout Shift (CLS) en 0,1 o menos. Un menú integrado suele incumplirlas por tres motivos: aparece después de ejecutarse JavaScript, entra en la página tarde y sus scripts mantienen ocupado el hilo principal. Esta guía explica cómo medir cada problema y arreglar la parte que usted controla. No cita cifras de ningún proveedor, porque no encontramos una fuente primaria para ninguna: mida su propia página.

Antes de empezar

Qué se mide

La página Web Vitals de web.dev, actualizada por última vez el 31 de octubre de 2024, fija los objetivos. En sus palabras: el LCP debe ocurrir en un plazo de 2,5 segundos desde que la página empieza a cargarse, las páginas deben tener un INP de 200 milisegundos o menos y deben mantener un CLS de 0,1 o menos.

Una página solo aprueba cuando cumple los objetivos en el percentil 75 de las cargas de página, en las tres métricas. Móvil y escritorio se segmentan por separado. Así que tres visitas rápidas de cada cuatro no bastan. El cuarto más lento de las visitas reales decide el resultado, y en el sitio de un dispensario muchas de esas visitas llegan desde un teléfono, con datos móviles, de pie frente a la tienda.

Dónde se va el tiempo en una página de menú

La guía de LCP de web.dev (actualizada el 31 de marzo de 2025) divide el LCP en cuatro partes:

Un menú integrado típico agranda varias de estas partes a la vez. La página carga, luego carga un script, luego el script solicita los datos de los productos y después se muestran los productos. Si el elemento más grande de la pantalla es una imagen de producto o el propio menú, cada uno de esos pasos queda dentro de su LCP. Es el patrón genérico de cualquier integración renderizada en el cliente. Cómo se comporta el marco de un proveedor concreto es algo que debe comprobar en el panel de red de su propia página.

Empiece con datos de campo

Abra PageSpeed Insights con la URL de su menú y lea la sección de datos de campo antes que la puntuación de laboratorio. Los datos de campo reflejan visitas reales en el percentil 75. Una prueba de laboratorio es una carga en un dispositivo simulado. Sirve para depurar y es mala para decidir si se aprueba o no. Si su sitio tiene poco tráfico para tener datos de campo, anótelo y use la puntuación de laboratorio solo como referencia aproximada.

Paso a paso

1. Haga que la primera pantalla no dependa de la integración (LCP)

Renderice en el servidor lo que no necesita datos del menú: el nombre de la tienda, el horario, la dirección, los enlaces de categorías y una introducción breve. web.dev recomienda el renderizado en el servidor o el prerenderizado para que el contenido no espere a JavaScript, y que el recurso LCP se pueda descubrir en el HTML inicial.

Dos reglas de la misma guía se aplican a las imágenes. No cargue nunca con carga diferida la imagen LCP. Y use fetchpriority="high" solo en una o dos imágenes, porque si todo tiene prioridad alta, nada la tiene. Sobre formatos y tamaños, consulte nuestro artículo sobre formatos de imagen y carga diferida que no perjudican el LCP.

Si el propio menú es el elemento LCP, no puede evitar esperarlo. Aun así, puede mover el elemento LCP: coloque un encabezado o una imagen principal renderizados en el servidor encima del menú, de modo que el pintado más grande sea algo que usted controla.

2. Reserve espacio para el menú (CLS)

Un iframe o un menú inyectado que llega tarde empuja hacia abajo todo lo que tiene debajo. La guía de CLS de web.dev (actualizada el 7 de febrero de 2025) indica que se reserve espacio para el contenido de carga tardía: una opción es añadir una regla CSS min-height, o usar aspect-ratio para contenido adaptable.

No colapse el espacio si no se carga nada. La guía aconseja mostrar un marcador de posición, porque quitar el espacio reservado desplaza la página tanto como insertar contenido. También señala que el contenido inyectado dinámicamente cerca de la parte superior de la ventana suele causar desplazamientos mayores, así que mantenga el contenido tardío más abajo en la página cuando pueda.

Una salvedad de la misma página: los desplazamientos de diseño de los iframes no se pueden medir con las API web, por lo que algunas herramientas de campo pueden subestimarlos, aunque el Chrome User Experience Report (CrUX) sí los incluye. Si un monitor basado en scripts dice que su CLS está bien y PageSpeed Insights dice otra cosa, confíe en CrUX.

3. Cargue la integración con intención

Si el menú está debajo del pliegue, añada loading="lazy" al iframe. La guía de iframes de web.dev (actualizada el 23 de septiembre de 2024) explica que aplaza la carga de los iframes fuera de pantalla hasta que el usuario se desplaza cerca de ellos, y que omitir el atributo equivale a loading="eager". La guía cita una investigación de Chrome con un ahorro mediano de datos del 2 al 3 % y reducciones medianas del First Contentful Paint del 1 al 2 %. Son cifras modestas y generales, no una promesa para su página.

Si el menú es el contenido principal de la página, no use carga diferida. Eso retrasa justo lo que el visitante vino a ver y, probablemente, también su LCP.

Para los scripts de terceros, la guía de JavaScript de terceros de web.dev indica cargarlos de forma asíncrona, salvo que deban ejecutarse antes del renderizado. Use async para los scripts necesarios pronto y defer para los menos críticos. Añade que una conexión temprana con un origen de terceros importante puede ahorrar de 100 a 500 ms.

Eso es lo que hace rel="preconnect". La guía de preconnect añade un límite: haga preconnect solo a los dominios críticos que vaya a usar pronto, porque los navegadores cierran las conexiones sin usar a los 10 segundos y demasiadas sugerencias provocan competencia por el ancho de banda. Haga preconnect al único origen del menú, no a todas las etiquetas de la página.

Tenga en cuenta las fechas. Tanto la guía de terceros como la de preconnect se actualizaron por última vez en 2019. Los principios siguen vigentes, pero pruebe el efecto en lugar de dar por hecho de 100 a 500 ms.

4. Proteja el hilo principal (INP)

La guía de INP de web.dev (actualizada el 2 de septiembre de 2025) explica que, según el tamaño de un script, ese trabajo puede introducir tareas largas en el hilo principal, que retrasan la respuesta a toques y clics. El retraso de entrada también viene de la carga, el análisis y la compilación de scripts, de los temporizadores y de las interacciones superpuestas.

Medidas prácticas en una página de menú:

• Quite las etiquetas que la página del menú no necesita. Cada script adicional compite con el menú por el hilo principal.
• Retrase los widgets de chat y complementos similares hasta que el visitante interactúe.
• Mantenga pequeños sus propios controladores de clic. La guía recomienda dividir el trabajo en tareas separadas y señala que ceder el control de forma indiscriminada es mejor que no cederlo nunca.
• Pruebe los filtros, las pestañas de categorías y los botones de añadir al carrito en un teléfono de gama media, no solo en un portátil.

Esa guía no da reglas separadas para los scripts de terceros, así que trate estas medidas como aplicaciones del consejo general y verifíquelas con mediciones.

5. Vuelva a medir

Cambie una sola cosa cada vez y lleve un registro breve con fechas. Los datos de campo en el percentil 75 se mueven despacio, porque cubren una ventana móvil de visitas reales. Compare antes y después en la misma métrica, el mismo tipo de dispositivo y la misma página. Si tras unas semanas mejoran los números de laboratorio y los de campo no, la solución ayudó a la prueba, no a sus visitantes.

Errores comunes

• Aplicar carga diferida a todo. La imagen de la primera pantalla y el menú principal deben cargarse sin demora. Solo las integraciones fuera de pantalla deben esperar.
• Perseguir la puntuación de laboratorio. Una prueba verde en un portátil rápido dice poco sobre el percentil 75 en un teléfono.
• Hacer preconnect a una lista larga de orígenes. Las conexiones sin usar se cierran a los 10 segundos y las sugerencias extra compiten por el ancho de banda.
• No reservar espacio. Si añade un banner o un aviso de edad sobre el menú después del lanzamiento, el CLS sube.
• Tratar el marco del proveedor como intocable. No puede cambiar el código de su interior, pero controla todo lo que lo rodea: la estructura, el marcador de posición, el momento de carga y las demás etiquetas de la página. Si el cuello de botella es el propio marco, mídalo y lleve las cifras al proveedor.

La velocidad también influye en la búsqueda. Si gestiona varias tiendas, primero está la cuestión de la estructura, que tratamos en SEO para dispensarios con varias sedes. Si la página de su menú necesita reconstruirse en torno al renderizado en el servidor, es el tipo de trabajo que hacemos en desarrollo web, o puede contactarnos con la URL de la página.

Preguntas frecuentes

¿Qué se considera una buena puntuación de Core Web Vitals para el sitio de un dispensario?

web.dev fija el LCP en 2,5 segundos o menos, el INP en 200 milisegundos o menos y el CLS en 0,1 o menos, medidos en el percentil 75 de las cargas de página. Una página aprueba solo cuando las tres métricas cumplen el objetivo.

¿Debo aplicar carga diferida al iframe de mi menú?

Solo si está debajo del pliegue. Si el menú es el elemento más grande de la primera pantalla, la carga diferida retrasa el LCP. web.dev indica que nunca se aplique carga diferida a la imagen LCP, y la misma lógica vale para el contenido principal de la página.

¿Por qué la puntuación de laboratorio es buena pero los datos de campo fallan?

Las herramientas de laboratorio ejecutan una carga en un dispositivo. Los datos de campo son el percentil 75 de visitas reales. web.dev también señala que los desplazamientos de los iframes no se pueden medir con las API web, por lo que algunas herramientas los subestiman mientras que CrUX sí los incluye.

¿Puedo arreglar un menú lento que no controlo?

En parte. Usted controla la página que lo rodea: la reserva de espacio, el momento de carga, las sugerencias de conexión y lo que más compite por el hilo principal. Lo que se ejecuta dentro del marco del proveedor es código del proveedor: mídalo y plantéeselo a él.