15 formas en que tu sitio se carga desde Google Search y cómo medirlas
Cuando encuentras una página en Google, rara vez piensas en todo lo que sucede antes del clic. Sin embargo, Google puede usar 5 o más métodos distintos para cargar una página, cada uno con características de rendimiento muy diferentes. Este artículo reinterpreta y traduce al español una investigación práctica sobre cómo distinguir y medir esos tipos de carga, con especial foco en Signed Exchanges SXG, y añade recomendaciones aplicadas por Q2BSTUDIO para ingeniería de rendimiento web, aplicaciones a medida y software a medida.
Categorías principales de carga de página
Carga bajo demanda tradicional. Es el modelo clásico del principio de la web: al hacer clic el navegador descarga el HTML y luego los recursos CSS, JS, imágenes y fuentes. Funciona, pero si el servidor está lento u ocupado, aparecerá un retraso visible para el usuario.
Prefetch del documento con Speculation Rules. El concepto es descargar el HTML antes de que el usuario haga clic. En los resultados de Google, Chrome y otros navegadores basados en Chromium usan Speculation Rules más un proxy privado. La experiencia mejora mucho, pero el prefetch se limita al documento y no adelanta subrecursos como CSS, imágenes o fuentes.
Prefetch de la página completa con Signed Exchanges. Es posible que Google prefetchee el HTML y todos los subrecursos desde sus resultados para sitios que implementan SXG. Al hacer clic, el navegador puede empezar a renderizar casi al instante. SXG está disponible en navegadores basados en Chromium y requiere implementación en el sitio de destino. En Q2BSTUDIO integramos SXG en arquitecturas modernas y lo alineamos con pipelines de rendimiento, tanto en backends como en frontends creados como software a medida y aplicaciones a medida; si buscas un partner técnico, explora cómo diseñamos plataformas robustas en desarrollo de aplicaciones y software multiplataforma.
Prerendering con AMP. Quizá la forma más veloz de mostrar una página es AMP, ya que Google prerenderiza páginas AMP: al hacer clic, no solo está prefetcheado, también prerenderizado. A cambio, impone restricciones fuertes: HTML limitado, JavaScript acotado y un ecosistema muy centralizado con caché controlada por Google. En muchos casos la URL efectiva se sirve dentro de google.com y, aunque existe la posibilidad de combinar AMP con SXG para mejorar la URL visible, es poco habitual.
Carga bajo demanda con redirección del lado del servidor anuncios. Al hacer clic en un anuncio, suele haber una redirección HTTP 302 para registrar el clic y eso añade latencia. No hay prefetch. Si inviertes en Ads, asegúrate de que tu página esté extremadamente optimizada para contrarrestar ese retraso; una alternativa en móvil es usar AMP en la landing, aunque no es común en la práctica.
Condiciones, bordes y particularidades
Signed Exchanges SXG. El escenario ideal es cuando se prefetchean HTML y subrecursos. En la realidad, puedes ver combinaciones distintas que impactan el LCP:
1 Prefetch con subrecursos. El mejor caso. Si la mayoría de vistas SXG llegan así, has optimizado muy bien tu sitio.
2 Prefetch sin subrecursos. SXG funciona con una regla todo o nada: si un subrecurso falla en el prefetch, al llegar el usuario se re-descargan todos los subrecursos. Causas típicas: errores de implementación, incidencias raras en la caché global SXG, limpieza regular de la caché y errores temporales, el usuario no permanece lo suficiente en la SERP para completar el prefetch, o abre en nueva pestaña.
3 Carga bajo demanda con redirección cliente fallback SXG. Si la página no está en la caché SXG de Google, es posible que, al clicar, el navegador reciba un documento mínimo con una redirección JavaScript al destino. Ese paso extra suma latencia por otra petición y el tiempo de parseo y ejecución.
4 Carga bajo demanda desde caché SXG. En ocasiones no hay prefetch previo, pero al clicar se sirve la versión SXG directamente desde la caché. Puede ocurrir porque Google solo prefetchea 1 resultado SXG por SERP o porque el intento de prefetch falló inicialmente y, mientras el usuario decidía, la caché se pobló. Este modo tiene un sobrecoste criptográfico leve por verificación de firmas y descarga de certificados, pero en hardware actual el coste de CPU es reducido.
Speculation Rules. A día de hoy, Google prefetch con Speculation Rules si se cumplen condiciones como: el resultado está en el top 2 o el usuario pasa el ratón por el enlace en escritorio; no existen cookies previas del sitio destino; el dispositivo tiene memoria, red y batería suficientes sin modo ahorro; ninguna extensión bloquea el prefetch; y el sitio no lo desautoriza. Estas condiciones no aplican a SXG.
AMP prerendering. De forma similar a SXG, solo uno de los resultados AMP se prerenderiza en la SERP. El AMP viewer se reutiliza entre resultados, por lo que el viewer aparece de inmediato, pero las páginas que no fueron prerenderizadas deben cargarse on demand dentro del viewer.
Abrir en una nueva pestaña. Cuando el usuario abre en nueva pestaña, la carga ocurre en segundo plano y el impacto subjetivo del rendimiento suele ser menor. Aun así, hay degradaciones: los subrecursos prefetcheados con SXG no se reutilizan; el HTML SXG prefetcheado se descarta salvo en escritorio con Ctrl clic; y en AMP no hay prerender ni prefetch, se carga on demand. En cambio, el prefetch de Speculation Rules maneja las nuevas pestañas con gran fiabilidad en escritorio y móvil.
Prefetch duplicado. Si una página implementa SXG, Google puede prefetchear SXG y a la vez usar Speculation Rules para la versión normal especialmente en escritorio. Es más ancho de banda, pero tiene un lado positivo: si el usuario abre en nueva pestaña mediante menú contextual y se descarta SXG, el documento normal prefetcheado sigue estando listo, aunque los subrecursos deban cargarse de cero.
Técnicas genéricas para acelerar la carga
Early Hints. Permiten que el navegador comience a descargar subrecursos incluso antes de que el documento principal empiece a llegar. Beneficia especialmente a páginas con render del lado del servidor costoso.
Caché en el edge. Si sirves HTML desde el edge por ejemplo con CDNs, conviene medirlo como categoría aparte porque cambia la ruta crítica: los subrecursos comienzan antes si se anuncian en el encabezado Link, el HTML llega antes que desde el origen y, aunque puedas combinarlo con Early Hints, el beneficio marginal puede ser menor si el edge ya es rápido. En Q2BSTUDIO diseñamos arquitecturas multi CDN y edge computing con foco en latencia baja y observabilidad, integradas con servicios cloud AWS y Azure; si quieres auditar o modernizar tu plataforma, revisa nuestros servicios cloud en Azure y AWS.
Sin impacto en prefetch. Cuando hay prefetch efectivo, ya sea Speculation Rules o SXG, da igual si el documento original se sirvió con Early Hints o desde el edge: el beneficio se materializó durante el prefetch.
Caché del navegador. Usuarios recurrentes pueden tener subrecursos en caché e incluso HTML si haces caching del lado del cliente, lo que reduce mucho el tiempo de segunda visita. Para medir, separa primeras visitas de visitas cacheadas.
Lista práctica de tipos de carga desde Google sin pestaña nueva ni usuario recurrente
1 Server Load 2 Server Load con Early Hints 3 Edge Cache Load 4 Speculation Rules Prefetch 5 SXG Prefetch con subrecursos 6 SXG Prefetch sin subrecursos 7 SXG On Demand 8 Server Load vía redirección SXG cliente 9 Server Load con Early Hints vía redirección SXG cliente 10 Edge Cache Load vía redirección SXG cliente 11 AMP Prerender 12 AMP On Demand 13 Server Load vía redirección de Ads 14 Server Load con Early Hints vía redirección de Ads 15 Edge Cache Load vía redirección de Ads.
Comparación resumida
Prefetch y prerender más rápidos. Top teórico: 1 AMP prerender más veloz 2 SXG con subrecursos 3 Speculation Rules prefetch 4 SXG sin subrecursos más lento de estos. AMP on demand es difícil de clasificar porque la página AMP es distinta y puede ser muy ligera.
En cargas bajo demanda: 1 Edge cache más rápido 2 Server con Early Hints 3 Server normal más lento. SXG on demand depende del sobrecoste de SXG frente a tu latencia de red y rendimiento de origen.
Por redirección: 1 Sin redirección más rápido 2 Redirección server side Ads 3 Redirección client side fallback SXG más lenta.
Cómo medir en la vida real
1 Distingue tipos de carga. Implementa lógica para identificar si la visita viene de Google recuerda que en fallback SXG el referrer puede ser tu dominio en webpkgcache, si es primera visita sin caché local, si se abrió en pestaña nueva historial con longitud 1 y si el navegador soporta SXG. Para SXG, la forma fiable es inspeccionar en el servidor el encabezado Accept que incluya application/signed-exchange.
2 Ten en cuenta el edge caching. Si sirves HTML cacheado, usa un worker en el edge para reescribir una variable de soporte SXG justo antes de devolver el HTML en función del Accept de cada petición, evitando valores incorrectos para navegadores sin SXG.
3 Etiqueta tus métricas. Registra el tipo de carga junto a LCP, FCP y TTFB en tu herramienta RUM. Puedes enviar un evento a tu analítica por ejemplo a Google Analytics como dimensión personalizada para comparar engagement y conversión por tipo de carga.
4 Segmenta. No mezcles primeras visitas con visitas cacheadas ni aperturas en nueva pestaña al evaluar el impacto de prefetch o prerender.
Recomendaciones accionables
Implementa SXG para usuarios de Chromium, usa Speculation Rules donde aplique, activa Early Hints y optimiza la ruta crítica de subrecursos. Aprovecha caché en edge, prioriza LCP con imágenes optimizadas y fuentes pre-cargadas, y revisa redirecciones de Ads para reducir saltos innecesarios. Si tu negocio necesita una plataforma escalable con rendimiento extremo, Q2BSTUDIO puede ayudarte a diseñar e implementar aplicaciones a medida y software a medida con pipelines de observabilidad, automatización y pruebas de rendimiento de punta a punta.
Quiénes somos
Q2BSTUDIO es una empresa de desarrollo de software, especializada en aplicaciones a medida, inteligencia artificial IA para empresas y agentes IA, ciberseguridad y pentesting, automatización de procesos, servicios cloud AWS y Azure, y servicios de inteligencia de negocio con Power BI. Combinamos arquitectura cloud, data y MLOps para acelerar tu time to value y proteger tu operación. Descubre cómo creamos productos digitales de alto rendimiento en soluciones de software y aplicaciones a medida.
Palabras clave para ayudarte a encontrar este contenido: aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio, ia para empresas, agentes IA, power bi.
Conclusión
Google puede cargar tu página de muchas maneras y cada una altera la experiencia percibida. Medir, etiquetar y comparar estos tipos de carga en condiciones reales te permitirá priorizar inversiones con mayor retorno. Si quieres llevar tu experiencia de usuario al siguiente nivel, optimizando desde la SERP hasta el LCP, en Q2BSTUDIO unimos rendimiento, seguridad y escalabilidad para que tu sitio y tus productos brillen en cada clic.