```
**Fuentes web sin `font-display: swap`:** Cuando el navegador carga una fuente web, puede mostrar el texto con la fuente de sistema (FOUT) o no mostrarlo hasta que la fuente esté disponible (FOIT). Ambos comportamientos pueden causar CLS. La solución es usar `font-display: swap` en las declaraciones `@font-face`:
```css
@font-face {
font-family: 'Inter';
src: url('/fonts/inter-regular.woff2') format('woff2');
font-weight: 400;
font-style: normal;
font-display: swap;
}
```
Para fuentes de Google Fonts cargadas desde `fields.json`, HubSpot gestiona automáticamente la carga de la fuente, pero no siempre aplica `font-display: swap`. Para forzarlo, se puede añadir el parámetro `display=swap` en el `` de Google Fonts en la plantilla:
```html
```
**Embeds de terceros sin dimensiones reservadas:** Los iframes de YouTube, Vimeo, formularios de HubSpot y otros embeds de terceros pueden causar CLS si no tienen dimensiones reservadas. La solución es usar el truco del aspect-ratio padding:
```css
.video-embed-wrapper {
position: relative;
padding-bottom: 56.25%; /* 16:9 */
height: 0;
overflow: hidden;
}
.video-embed-wrapper iframe {
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
}
```
**Banners de cookies y notificaciones:** Los banners de cookies que aparecen en la parte inferior de la pantalla pueden causar CLS si empujan el contenido hacia arriba al aparecer. La solución es posicionarlos de forma que no afecten al layout del contenido principal (usando `position: fixed` en lugar de `position: sticky` o añadiéndolos al flujo del documento).
### Herramienta de diagnóstico de CLS en Chrome DevTools
Chrome DevTools incluye una herramienta específica para diagnosticar el CLS: en la pestaña "Performance", después de grabar una carga de página, se puede activar la opción "Layout Shift Regions" para ver visualmente qué elementos del DOM están causando desplazamientos de layout. Esta herramienta es especialmente útil para identificar causas de CLS que no son obvias a simple vista.
---
## Optimización del INP en HubSpot CMS
### Qué causa un INP elevado
El INP elevado en sitios HubSpot CMS suele tener las siguientes causas:
**Scripts de terceros pesados:** Los scripts de analytics (Google Analytics 4, HubSpot Analytics), chatbots (Intercom, Drift, HubSpot Chat), herramientas de heatmaps (Hotjar, Microsoft Clarity) y plataformas de publicidad (Google Ads, LinkedIn Insight Tag) compiten por el hilo principal con el código de la página. Cada uno de estos scripts puede añadir decenas o cientos de milisegundos al INP.
**Event listeners síncronos en el hilo principal:** Los módulos de HubSpot que tienen JavaScript con event listeners síncronos que realizan operaciones costosas (manipulación del DOM, cálculos complejos, peticiones síncronas) pueden bloquear el hilo principal y aumentar el INP.
**Animaciones CSS costosas:** Las animaciones que modifican propiedades que desencadenan reflow (como `width`, `height`, `top`, `left`) son más costosas que las que solo modifican propiedades que se manejan en el compositor (como `transform` y `opacity`).
### Técnicas de optimización del INP
**1. Diferir scripts de terceros:**
```html
```
**2. Usar `requestIdleCallback` para tareas no críticas:**
```javascript
// En lugar de ejecutar tareas pesadas directamente
function initHeavyFeature() {
// ... código pesado ...
}
// Usar requestIdleCallback para ejecutarlas cuando el navegador esté inactivo
if ('requestIdleCallback' in window) {
requestIdleCallback(initHeavyFeature, { timeout: 2000 });
} else {
setTimeout(initHeavyFeature, 1000);
}
```
**3. Optimizar animaciones CSS:**
```css
/* MAL: animación que causa reflow */
.card:hover {
width: 110%;
height: 110%;
}
/* BIEN: animación que solo usa el compositor */
.card {
transition: transform 0.2s ease, box-shadow 0.2s ease;
will-change: transform;
}
.card:hover {
transform: scale(1.05);
box-shadow: 0 12px 40px rgba(0, 0, 0, 0.15);
}
```
**4. Fragmentar tareas largas con `scheduler.yield()`:**
En 2026, la API `scheduler.yield()` está disponible en todos los navegadores modernos y permite fragmentar tareas largas para ceder el control al navegador entre fragmentos:
```javascript
async function processLargeDataset(items) {
for (let i = 0; i < items.length; i++) {
processItem(items[i]);
// Ceder el control al navegador cada 50 elementos
if (i % 50 === 0) {
await scheduler.yield();
}
}
}
```
---
## Scripts de terceros y su impacto en el rendimiento
### El problema de los scripts de terceros en HubSpot
Los scripts de terceros son, en la mayoría de los casos, la principal causa de bajo rendimiento en sitios HubSpot CMS. A diferencia de WordPress, donde se pueden usar plugins como WP Rocket para gestionar la carga de scripts de terceros de forma centralizada, en HubSpot CMS la gestión de scripts de terceros requiere un enfoque más manual.
Los scripts de terceros más comunes en sitios HubSpot B2B y su impacto típico en el rendimiento son:
| Script | Impacto típico en LCP | Impacto en INP | Alternativa |
|---|---|---|---|
| HubSpot Analytics (hs-analytics) | Bajo (< 100 ms) | Bajo | No eliminable |
| Google Analytics 4 | Bajo-medio (100-300 ms) | Medio | Cargar diferido |
| Google Tag Manager | Medio (200-500 ms) | Alto | Auditar tags activos |
| Hotjar / Microsoft Clarity | Alto (300-800 ms) | Alto | Cargar diferido o eliminar |
| Intercom / Drift | Alto (500-1000 ms) | Alto | Cargar diferido, solo en páginas necesarias |
| LinkedIn Insight Tag | Bajo-medio | Bajo | Cargar diferido |
| Facebook Pixel | Bajo-medio | Bajo | Cargar diferido |
| Cookiebot / OneTrust | Medio (200-400 ms) | Medio | Optimizar configuración |
### Estrategia de carga diferida de scripts de terceros
La estrategia más efectiva para minimizar el impacto de los scripts de terceros en los Core Web Vitals es cargarlos de forma diferida, después de que el usuario haya interactuado con la página (estrategia "load on interaction") o después de que el evento `load` haya disparado.
En HubSpot CMS, los scripts de terceros se pueden añadir en la sección "Tracking & Analytics" de la configuración del portal, o directamente en las plantillas del theme. Para los scripts añadidos en la configuración del portal, HubSpot los inyecta automáticamente en el `` de todas las páginas, lo que puede impactar negativamente en el rendimiento.
La alternativa es añadir los scripts directamente en las plantillas del theme con carga diferida:
```html
```
### Google Tag Manager y el rendimiento
Google Tag Manager (GTM) es una de las principales causas de bajo rendimiento en sitios HubSpot CMS porque actúa como un contenedor de scripts de terceros: cada tag añadido a GTM es un script adicional que se carga en la página. En proyectos donde GTM gestiona 20-30 tags activos, el impacto en el rendimiento puede ser muy significativo.
Las mejores prácticas para minimizar el impacto de GTM en el rendimiento son:
1. **Auditar regularmente los tags activos:** Eliminar los tags que ya no se usan o que tienen duplicados.
2. **Usar triggers específicos:** En lugar de disparar todos los tags en "All Pages", usar triggers específicos que limiten la carga de scripts a las páginas donde son necesarios.
3. **Consolidar pixels:** Si se tienen pixels de Facebook, LinkedIn y Twitter, consolidarlos en GTM en lugar de añadirlos por separado.
4. **Usar Server-Side GTM:** Google Tag Manager Server-Side mueve el procesamiento de los scripts de terceros al servidor, reduciendo el impacto en el cliente. Esta opción requiere infraestructura adicional pero puede mejorar significativamente el rendimiento.
---
## Configuración del CDN y caché en HubSpot
### La infraestructura CDN de HubSpot en 2026
HubSpot CMS usa una red CDN global basada en Fastly para servir el contenido de los sitios web. En 2026, la infraestructura CDN de HubSpot incluye más de 200 puntos de presencia (PoPs) en todo el mundo, lo que garantiza tiempos de carga bajos para visitantes de cualquier región geográfica.
Los assets estáticos del theme (CSS, JavaScript, imágenes) se sirven directamente desde el CDN con cabeceras de caché de larga duración (generalmente 1 año). Esto significa que, una vez que un visitante ha cargado el CSS del theme, las visitas posteriores lo obtienen directamente desde la caché del CDN sin necesidad de hacer una petición al servidor de origen.
### Cabeceras de caché y versionado de assets
HubSpot gestiona automáticamente el versionado de los assets del theme: cuando se actualiza un archivo CSS o JavaScript, HubSpot genera una nueva URL con un hash de versión, lo que invalida la caché del CDN y garantiza que los visitantes reciben la versión actualizada.
Sin embargo, hay situaciones donde la caché puede causar problemas:
- **Cambios en el `fields.json` del theme:** Los cambios en los tokens de diseño pueden no reflejarse inmediatamente en todos los visitantes si sus navegadores tienen en caché la versión anterior del CSS.
- **Módulos con JavaScript que hacen peticiones a APIs externas:** Si el módulo cachea las respuestas de la API, los datos pueden quedar desactualizados.
Para forzar la invalidación de la caché en HubSpot, se puede usar la función "Purge CDN Cache" disponible en la configuración del portal (Configuración → Sitio web → Páginas → Purgar caché CDN).
### Optimización del TTFB mediante la caché de HubSpot
HubSpot CMS implementa caché a nivel de página para las páginas estáticas (páginas que no tienen Smart Content ni contenido dinámico). Cuando un visitante solicita una página cacheada, HubSpot la sirve directamente desde la caché del CDN sin procesar la plantilla HubL en el servidor, lo que reduce significativamente el TTFB.
Para maximizar el beneficio de la caché de páginas:
- **Minimizar el uso de Smart Content:** Cada variante de Smart Content requiere procesamiento en el servidor y puede impedir que la página se cachee completamente.
- **Evitar el uso de variables de sesión en las plantillas:** Las plantillas que acceden a datos de sesión (como el nombre del visitante logueado) no pueden cachearse.
- **Usar módulos globales para elementos comunes:** Los módulos globales (cabecera, pie de página) se cachean de forma independiente y se reutilizan en todas las páginas.
---
## Checklist de optimización para sitios HubSpot
La siguiente tabla resume las optimizaciones más importantes para cada métrica Core Web Vital en sitios HubSpot CMS:
| Optimización | Impacto en LCP | Impacto en CLS | Impacto en INP | Dificultad |
|---|---|---|---|---|
| Preload de imagen hero | Alto | Ninguno | Ninguno | Baja |
| `fetchpriority="high"` en imagen LCP | Alto | Ninguno | Ninguno | Baja |
| Dimensiones explícitas en imágenes | Ninguno | Alto | Ninguno | Baja |
| `font-display: swap` en fuentes | Medio | Medio | Ninguno | Baja |
| Preconnect a dominios de terceros | Medio | Ninguno | Ninguno | Baja |
| Carga diferida de scripts de terceros | Medio | Ninguno | Alto | Media |
| Eliminación de scripts no usados | Alto | Ninguno | Alto | Media |
| Optimización de animaciones CSS | Ninguno | Bajo | Medio | Media |
| CSS crítico inline | Alto | Ninguno | Ninguno | Media-Alta |
| Server-Side GTM | Medio | Ninguno | Alto | Alta |
| Auditoría de tags GTM | Medio | Ninguno | Medio | Media |
| Aspect-ratio para embeds | Ninguno | Alto | Ninguno | Baja |
---
## Preguntas Frecuentes
**¿Puede un sitio HubSpot CMS alcanzar una puntuación de 100 en PageSpeed Insights?**
Técnicamente es posible, pero en la práctica es muy difícil para sitios con contenido dinámico, scripts de analytics y módulos interactivos. La puntuación de PageSpeed Insights es una métrica de laboratorio que mide el rendimiento en condiciones controladas (dispositivo Moto G4 simulado, conexión 4G lenta), y está diseñada para identificar oportunidades de mejora, no para ser un objetivo absoluto. En Emovere, nuestro objetivo para sitios HubSpot CMS es alcanzar puntuaciones de 80-90 en móvil y 90-100 en escritorio, con todos los Core Web Vitals en el rango "Bueno" según los datos de campo. Una puntuación de 100 en móvil generalmente requiere eliminar todos los scripts de terceros (incluyendo HubSpot Analytics), lo que no es viable para la mayoría de los proyectos B2B.
**¿El script de HubSpot Analytics (hs-analytics) impacta significativamente en el rendimiento?**
El script `hs-analytics` de HubSpot tiene un impacto moderado en el rendimiento: típicamente añade entre 50 y 150 ms al TBT y puede retrasar ligeramente el LCP en conexiones lentas. Sin embargo, este script es necesario para el funcionamiento de las funcionalidades de HubSpot que dependen del seguimiento de visitantes (Smart Content, workflows basados en comportamiento, atribución de leads). No es posible eliminarlo completamente en sitios HubSpot CMS. Lo que sí se puede hacer es asegurarse de que se carga de forma asíncrona (lo hace por defecto) y no bloquea el renderizado de la página.
**¿Cómo afecta el Smart Content al rendimiento del sitio?**
El Smart Content tiene dos impactos en el rendimiento: un impacto en el TTFB (porque requiere procesamiento en el servidor para determinar qué variante mostrar) y un potencial impacto en el CLS (si las diferentes variantes tienen alturas diferentes y el navegador no reserva el espacio correcto). Para minimizar el impacto del Smart Content en el rendimiento, se recomienda: (1) usar Smart Content solo en módulos donde el beneficio de personalización justifique el coste en rendimiento, (2) asegurarse de que todas las variantes de Smart Content tienen dimensiones similares para evitar CLS, y (3) usar Smart Content basado en cookies (que se resuelve en el cliente) en lugar de Smart Content basado en propiedades del CRM (que requiere procesamiento en el servidor) cuando sea posible.
**¿Qué herramienta es más fiable para medir los Core Web Vitals de un sitio HubSpot: PageSpeed Insights o Google Search Console?**
Para la toma de decisiones de optimización, Google Search Console es más fiable porque muestra datos de campo reales de usuarios que han visitado el sitio, mientras que PageSpeed Insights muestra datos de laboratorio (simulados) que pueden no reflejar la experiencia real. Sin embargo, PageSpeed Insights es más útil para el diagnóstico técnico porque muestra recomendaciones específicas y permite analizar cualquier URL, no solo las que tienen suficiente tráfico para aparecer en Search Console. El flujo de trabajo recomendado es: usar Search Console para identificar las páginas con peores Core Web Vitals según datos de campo, y luego usar PageSpeed Insights y Chrome DevTools para diagnosticar las causas específicas y probar las optimizaciones.
**¿Es posible implementar lazy loading de módulos en HubSpot CMS para mejorar el INP?**
Sí, es posible implementar lazy loading de módulos en HubSpot CMS, aunque requiere trabajo técnico adicional. La técnica más efectiva es usar la Intersection Observer API para cargar el JavaScript de los módulos solo cuando entran en el viewport. Esto es especialmente útil para módulos pesados que están debajo del fold (como carruseles, mapas interactivos o vídeos). En el módulo, en lugar de ejecutar el código JavaScript directamente, se registra un observer que ejecuta el código cuando el módulo es visible:
```javascript
const moduleEl = document.querySelector('.mi-modulo-pesado');
if (moduleEl) {
const observer = new IntersectionObserver((entries) => {
if (entries[0].isIntersecting) {
initMiModuloPesado();
observer.disconnect();
}
}, { rootMargin: '200px' });
observer.observe(moduleEl);
}
```
---
## Conclusión
Optimizar los Core Web Vitals en HubSpot CMS en 2026 es una tarea que requiere un enfoque sistemático: identificar los elementos LCP, diagnosticar las causas de CLS e INP, y aplicar las optimizaciones en el orden correcto (primero las de mayor impacto y menor dificultad, luego las más complejas). La buena noticia es que HubSpot CMS ofrece una base sólida de rendimiento gracias a su CDN global y su infraestructura gestionada, lo que significa que el punto de partida es generalmente mejor que en WordPress sin optimizar.
Las optimizaciones con mayor retorno de inversión son, en orden de prioridad: el preload y la optimización de la imagen hero (LCP), las dimensiones explícitas en todas las imágenes (CLS), la carga diferida de scripts de terceros (INP y LCP), y la eliminación de scripts no utilizados. Aplicando estas cuatro optimizaciones, la mayoría de los sitios HubSpot CMS pueden alcanzar los umbrales de "Bueno" en todos los Core Web Vitals.
En Emovere realizamos auditorías de rendimiento para sitios HubSpot CMS y WordPress. Si tu sitio no está alcanzando los umbrales de Core Web Vitals, contacta con nuestro equipo para una auditoría técnica detallada.
---
## Referencias
[1] Google — Core Web Vitals. https://web.dev/vitals/ — Documentación oficial de Google sobre las métricas Core Web Vitals, sus umbrales y su impacto en el ranking de búsqueda.
[2] Google — Optimize Largest Contentful Paint. https://web.dev/optimize-lcp/ — Guía oficial de Google para la optimización del LCP, con técnicas específicas y ejemplos de código.
[3] Google — Optimize Cumulative Layout Shift. https://web.dev/optimize-cls/ — Guía oficial de Google para la optimización del CLS, incluyendo las causas más comunes y sus soluciones.
[4] Google — Optimize Interaction to Next Paint. https://web.dev/optimize-inp/ — Guía oficial de Google para la optimización del INP, con técnicas de fragmentación de tareas y gestión del hilo principal.
[5] HubSpot Developer Documentation — Performance. https://developers.hubspot.com/docs/cms/performance — Documentación de HubSpot sobre las herramientas y técnicas de optimización de rendimiento disponibles en CMS Hub/Content Hub.