Portada del artículo: Velocidad web por plataforma: qué dicen los datos reales
SEO Técnico & GEO

Velocidad web por plataforma: qué dicen los datos reales

25 de octubre de 2026Camilo Andrés RodríguezREAD_TIME: 40_MIN

Cuando alguien pregunta qué plataforma es más rápida, las respuestas suelen ser opiniones: “Wix es lento”, “Elementor pesa mucho”, “con código a mano vuelas”. Este artículo intenta responder con datos: cuántos sitios reales de cada plataforma aprueban las Core Web Vitals, medido sobre millones de sitios públicos y no sobre una página de prueba.

Es para ti si tienes (o piensas montar) un sitio en WordPress, Wix, Shopify u otra plataforma y quieres saber qué esperar de su velocidad, o si dudas entre cambiar de herramienta o arreglar la que tienes. Te llevas un ranking con sus límites, qué métrica falla en cada grupo, si el resultado aguanta al comparar sitios de popularidad parecida y qué conviene tocar primero.

Antes, una distinción que evita muchos malentendidos. Hay datos de laboratorio, que salen de cargar una página en un entorno controlado (así funciona Lighthouse, la herramienta de pruebas de Google), y datos de campo, que salen de monitorear a las personas que realmente visitan el sitio. Es la diferencia entre probar un coche en un circuito cerrado y ver cómo se comporta en el tráfico real, con todo tipo de conductores. Según web.dev, miden cosas muy distintas, y los datos de campo son los que conviene usar para priorizar. Aquí todo el análisis se apoya en datos de campo. Las definiciones y umbrales de cada métrica están en la guía de SEO técnico, así que no las repito.

En corto

  • El ranking: en móvil (septiembre de 2026), las plataformas donde más sitios aprueban los Core Web Vitals son Wix (80,9 %), Hugo (78,2 %) y Shopify (76,2 %). WordPress queda en 48,3 %, Elementor en 36,3 % y Next.js en 35,7 %.

  • Qué falla en WordPress: casi todos sus sitios responden bien cuando tocas o haces clic (INP, más del 88 %), pero pocos muestran rápido el contenido principal (LCP) y pocos tienen un servidor que responda rápido (TTFB). El problema está en la carga, no en la interacción.

  • Qué falla en Next.js: además de cargar lento como WordPress, es la única de las 20 plataformas comparadas que también falla al responder cuando tocas: solo el 59,7 % de sus sitios tiene un INP bueno, cuando en todas las demás es 76 % o más.

  • Entre sitios con tráfico parecido, la brecha se achica: si se comparan solo sitios del millón más visitado (el grupo Top 1M), la ventaja de Webflow y Astro sobre WordPress casi desaparece. Elementor y Next.js siguen al final.

  • ¿Pesa más la plataforma o lo que le pones? Para averiguarlo se compararon 309 herramientas con las que se hacen sitios web: gestores de contenido como WordPress, constructores como Elementor, frameworks, tiendas online, temas y más. Salieron tres cosas:

    • Las herramientas cuyas páginas cargan más JavaScript tienden a tener menos sitios que responden bien al tocar. Es una relación moderada.
    • Las herramientas con servidores que responden rápido suelen tener también una carga rápida del contenido principal. Es la relación más fuerte de las tres.
    • El peso de las imágenes, por sí solo, no marca diferencia.

    Cada relación se mide con una correlación, un número entre -1 y 1 que indica si dos cosas suelen ir juntas (-0,35, 0,58 y 0,03, en ese orden). La sección “¿Pesan más los recursos que la plataforma?” lo explica paso a paso.

  • Lo que no demuestra: que si cambias de plataforma vas a conseguir el mismo resultado que su grupo. También influyen quién elige cada herramienta, el hosting que algunas traen incluido y el tamaño de cada muestra.

El experimento: de dónde salen los números

La fuente

Los datos vienen del Tech Report de HTTP Archive, que cruza dos cosas:

  1. Qué tecnología usa cada sitio. HTTP Archive es un proyecto público que visita cada mes millones de sitios y detecta sus tecnologías con una versión propia de Wappalyzer, una herramienta que reconoce con qué está hecho un sitio mirando su código (por ejemplo, que usa WordPress). Su lista de sitios sale del Chrome UX Report (CrUX), la base de datos pública de Google con medidas de visitas reales.
  2. Cómo les va a sus visitantes reales. CrUX recoge métricas de usuarios reales de Chrome, no de simulaciones.

Para consultar todo esto se usó la API pública del Tech Report: https://cdn.httparchive.org/v1. La documentación de CrUX define un origen como un sitio web completo, direccionable con una URL como https://www.example.com. Es decir, cada dato es “un sitio”, no “una página”: todas las páginas bajo esa dirección cuentan juntas como un solo origen. Ojo: un subdominio como https://blog.example.com es otro origen distinto. En el resto del artículo, “origen” y “sitio” significan lo mismo.

Las cuatro métricas, en palabras simples

Si nunca te has cruzado con estas siglas, esto es lo único que necesitas para seguir el artículo:

  • LCP (Largest Contentful Paint): cuánto tarda en aparecer el elemento más grande de la pantalla, normalmente la imagen principal o el titular. Es “¿cuándo veo la página?”. Bueno: 2,5 segundos o menos.
  • INP (Interaction to Next Paint): cuánto tarda la página en reaccionar cuando tocas, haces clic o escribes. Es “¿me responde?”. Bueno: 200 milisegundos o menos.
  • CLS (Cumulative Layout Shift): cuánto se mueve el contenido mientras carga, como un botón que salta justo cuando vas a tocarlo. Es “¿se queda quieta?”. Bueno: 0,1 o menos.
  • TTFB (Time to First Byte): cuánto tarda el servidor en empezar a responder. No es uno de los Core Web Vitals, pero todo lo demás espera por él, así que pesa en el LCP. Bueno: 0,8 segundos o menos.

Las tres primeras son los Core Web Vitals. Si quieres el detalle de cómo se mide y se mejora cada una, está en la guía de SEO técnico.

Qué significa “aprueba Core Web Vitals”

Un origen aprueba cuando el percentil 75 de sus visitas cumple los tres umbrales a la vez: LCP de 2,5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0,1 o menos, según web.dev. Que sea el percentil 75 significa que al menos tres de cada cuatro visitas deben ser buenas; un buen promedio no basta. Es como ordenar todas las visitas de la más rápida a la más lenta y mirar la que queda a tres cuartos del camino: si esa ya cumple, es que la gran mayoría tuvo una buena experiencia, y no solo las visitas con mejor conexión. Cada resultado se mide por separado en móvil y en escritorio.

Hay un matiz importante. Si un origen no tiene suficientes datos de INP, se evalúa solo con LCP y CLS (lo documentan PageSpeed Insights y el propio Tech Report). Por eso conviene mirar siempre cuántos orígenes se evaluaron en cada métrica.

Qué se midió, exactamente

Todo con geo=ALL (todos los países) y, salvo que se indique otra cosa, rank=ALL (todos los sitios elegibles):

  • Último mes disponible: septiembre de 2026 (2026-09-01). Porcentaje de orígenes con LCP, INP, CLS y TTFB “buenos”, más el porcentaje que aprueba en conjunto, en móvil y escritorio.
  • Control por popularidad: el mismo cálculo con rank en Top 10M, Top 1M y Top 100k, para ver si el orden se mantiene entre sitios de popularidad comparable.
  • Evolución: 24 meses (octubre de 2024 a septiembre de 2026).
  • Peso de página y Lighthouse: medianas del último mes, como evidencia de apoyo. La mediana es el valor del medio: la mitad de los sitios pesa menos que ella y la otra mitad, más. Así, unos pocos sitios gigantes no distorsionan el resultado.

Las peticiones tienen esta forma (la tecnología va codificada en la URL):

https://cdn.httparchive.org/v1/cwv?technology=Elementor&geo=ALL&rank=ALL
https://cdn.httparchive.org/v1/cwv?technology=Elementor&geo=ALL&rank=Top%201M
https://cdn.httparchive.org/v1/page-weight?technology=Elementor&geo=ALL&rank=ALL
https://cdn.httparchive.org/v1/lighthouse?technology=Elementor&geo=ALL&rank=ALL
https://cdn.httparchive.org/v1/technologies?technology=Elementor

Dónde y cómo usarlo: abre cualquiera de esas URLs en el navegador o con curl. Devuelve una lista de meses (sin ordenar) con good_number (orígenes con resultado bueno) y tested (orígenes evaluados); el porcentaje es good_number / tested. Cambia Elementor por otra tecnología para repetir el análisis. Si quieres automatizarlo, un script de unas 100 líneas con fetch de Node 20 recorre la lista, ordena por fecha y guarda un CSV.

El análisis incluyó 20 tecnologías: WordPress, el editor de bloques de WordPress, Elementor, Divi, Bricks, Beaver Builder, Oxygen, Astra, WooCommerce, Wix, Shopify, Squarespace, Webflow, Astro, Next.js, Hugo, Gatsby, Drupal, Joomla y Ghost. Todas devolvieron datos. Para el editor de bloques se usó la tecnología “WordPress Block Editor”, que el Tech Report describe como los sitios que usan el editor de bloques (Gutenberg). Existe también una tecnología llamada “Gutenberg”, pero es el plugin de pruebas de nuevas funciones y tiene muchos menos sitios.

Lo que este análisis no mide

  • No mide tu sitio. Mide grupos de sitios. Tu caso puede estar muy por encima o por debajo de su grupo.
  • No mide causa y efecto. Lo vemos con detalle más abajo.
  • No incluye sitios sin suficiente tráfico. CrUX solo informa de orígenes públicos y suficientemente populares, con un umbral que Google no publica. Tampoco incluye a quien navega con Chrome en iOS, con otros navegadores o sin haber aceptado compartir estadísticas.
  • No mezcla lo que no debe. Una tecnología no excluye a otra: un mismo sitio puede contar como WordPress, Elementor y WooCommerce a la vez.

Resultados: quién aprueba más

Tabla 1: Orígenes que aprueban Core Web Vitals, septiembre de 2026, rank = todos

TecnologíaGrupoAprueban móvilOrígenes evaluados (móvil)Aprueban escritorio
WixAlojada80,9 %177.70987,1 %
HugoFramework o generador78,2 %6.04383,5 %
ShopifyAlojada76,2 %445.29779,5 %
GhostCMS72,8 %2.93264,1 %
WebflowAlojada71,3 %59.48382,6 %
AstroFramework o generador71,1 %47.27784,6 %
SquarespaceAlojada71,0 %89.05276,1 %
DrupalCMS64,7 %93.19366,1 %
JoomlaCMS57,4 %83.02959,7 %
BricksWordPress54,8 %10.70162,4 %
Beaver BuilderWordPress53,4 %28.32758,6 %
Editor de bloques (WordPress)WordPress52,0 %543.83357,8 %
OxygenWordPress51,3 %11.30647,8 %
WordPress (todo)WordPress48,3 %2.658.17553,7 %
GatsbyFramework o generador43,7 %9.27859,5 %
DiviWordPress41,4 %150.14431,2 %
AstraWordPress40,0 %168.42345,4 %
WooCommerceWordPress39,3 %542.54139,3 %
ElementorWordPress36,3 %877.51343,6 %
Next.jsFramework o generador35,7 %395.34556,9 %

Cómo leerla: “Aprueban móvil” es el porcentaje de orígenes de esa tecnología que cumple LCP, INP y CLS a la vez en móvil (con 80,9 %, Wix tiene a unos cuatro de cada cinco de sus sitios aprobando); “Orígenes evaluados” es la muestra detrás de ese porcentaje. Hugo (6.043) y Ghost (2.932) tienen muestras pequeñas frente a WordPress (2.658.175), así que sus cifras se mueven más con pocos sitios: con una muestra chica, que cambien unos cuantos sitios altera mucho el porcentaje.

{
  "type": "bar-horizontal",
  "title": "¿QUÉ % DE SITIOS APRUEBA CORE WEB VITALS EN MÓVIL?",
  "subtitle": "Porcentaje de orígenes con LCP, INP y CLS buenos, septiembre de 2026",
  "unit": "%",
  "max": 100,
  "categories": [
    "Wix",
    "Hugo",
    "Shopify",
    "Ghost",
    "Webflow",
    "Astro",
    "Squarespace",
    "Drupal",
    "Joomla",
    "Bricks",
    "Beaver Builder",
    "Editor de bloques (WordPress)",
    "Oxygen",
    "WordPress (todo)",
    "Gatsby",
    "Divi",
    "Astra",
    "WooCommerce",
    "Elementor",
    "Next.js"
  ],
  "series": [
    {
      "name": "Aprueban en móvil",
      "data": [
        80.9,
        78.2,
        76.2,
        72.8,
        71.3,
        71.1,
        71,
        64.7,
        57.4,
        54.8,
        53.4,
        52,
        51.3,
        48.3,
        43.7,
        41.4,
        40,
        39.3,
        36.3,
        35.7
      ]
    }
  ],
  "colors": [
    "#00ff9d"
  ]
}

Cómo leerlo: cada barra es una tecnología y su largo, el porcentaje de sitios que aprueba en móvil. Las plataformas alojadas (Wix, Shopify, Squarespace, Webflow) y los generadores estáticos ocupan la parte alta; los constructores de WordPress y Next.js, la baja. “Alojada” quiere decir que la plataforma te da el sitio y el servidor en un solo paquete.

Por grupos:

  • Plataformas alojadas. Wix (80,9 %), Shopify (76,2 %), Webflow (71,3 %) y Squarespace (71,0 %). Es la mejor zona del ranking, con muestras grandes (Shopify, por ejemplo, con 445.297 orígenes).
  • Frameworks y generadores estáticos. Hugo (78,2 %) y Astro (71,1 %) arriba; Next.js (35,7 %) y Gatsby (43,7 %) abajo. No es un grupo homogéneo: generar HTML estático (páginas ya armadas de antemano) y renderizar en el navegador (armarlas en el momento, en el dispositivo de cada visitante) no se parecen.
  • Otros CMS. Ghost (72,8 %), Drupal (64,7 %) y Joomla (57,4 %), en el medio.
  • WordPress y su ecosistema. WordPress en conjunto, con 2.658.175 orígenes, aprueba en 48,3 % de los casos. Dentro de él hay una brecha grande: Bricks (54,8 %), Beaver Builder (53,4 %) y el editor de bloques (52,0 %) están por encima del promedio; Divi (41,4 %), Astra (40,0 %), WooCommerce (39,3 %) y Elementor (36,3 %) por debajo.

Dos datos importantes sobre la muestra. Elementor es la tecnología con más orígenes evaluados después de WordPress (877.513), así que su resultado no es una rareza estadística. Y Bricks, con 10.701 orígenes, es una muestra bastante menor: su 54,8 % es una buena señal, pero con más margen de error que el de WordPress.

¿Está mejorando la web?

Sí, en casi todas las plataformas. Estos son los puntos de partida y de llegada en 24 meses:

Tabla 2: Evolución del porcentaje que aprueba en móvil (entre paréntesis, orígenes evaluados)

TecnologíaOctubre 2024Septiembre 2026Cambio (puntos)
WordPress42,9 % (3.191.543)48,3 % (2.658.175)+5,4
Elementor31,1 % (897.164)36,3 % (877.513)+5,2
Divi34,8 % (180.172)41,4 % (150.144)+6,6
Bricks52,1 % (4.163)54,8 % (10.701)+2,7
Beaver Builder46,8 % (36.433)53,4 % (28.327)+6,6
Wix63,5 % (206.739)80,9 % (177.709)+17,4
Shopify72,9 % (359.591)76,2 % (445.297)+3,3
Astro65,0 % (8.903)71,1 % (47.277)+6,1
Next.js27,8 % (178.684)35,7 % (395.345)+7,9

Cómo leerla: cada fila compara octubre de 2024 con septiembre de 2026; “Cambio” es la diferencia en puntos porcentuales, es decir, la resta simple entre los dos porcentajes (en Elementor, de 31,1 % a 36,3 % son 5,2 puntos, no un 5,2 % de mejora). Todas las tecnologías de la tabla suben; Wix es la que más.

{
  "type": "line",
  "title": "EVOLUCIÓN EN WORDPRESS Y SUS CONSTRUCTORES (24 MESES)",
  "subtitle": "% de orígenes que aprueban Core Web Vitals en móvil, octubre de 2024 a septiembre de 2026",
  "unit": "%",
  "max": 100,
  "categories": [
    "oct 24",
    "nov 24",
    "dic 24",
    "ene 25",
    "feb 25",
    "mar 25",
    "abr 25",
    "may 25",
    "jun 25",
    "jul 25",
    "ago 25",
    "sep 25",
    "oct 25",
    "nov 25",
    "dic 25",
    "ene 26",
    "feb 26",
    "mar 26",
    "abr 26",
    "may 26",
    "jun 26",
    "jul 26",
    "ago 26",
    "sep 26"
  ],
  "series": [
    {
      "name": "WordPress",
      "data": [
        42.9,
        42.9,
        42.8,
        42.6,
        43.3,
        44.7,
        44.9,
        44.8,
        43.4,
        44.3,
        45,
        45,
        46.1,
        46.3,
        46.4,
        47.9,
        48.1,
        48.7,
        49.1,
        49.3,
        48.8,
        49.5,
        48.7,
        48.3
      ]
    },
    {
      "name": "Elementor",
      "data": [
        31.1,
        31.1,
        31.9,
        31.8,
        32.5,
        33.9,
        34,
        33.6,
        32.3,
        33.2,
        33.7,
        33.4,
        34.4,
        34.7,
        34.9,
        36,
        35.9,
        36.7,
        36.9,
        37.3,
        36.8,
        37.7,
        36.8,
        36.3
      ]
    },
    {
      "name": "Divi",
      "data": [
        34.8,
        34.7,
        35.7,
        35.7,
        36.4,
        38,
        38.1,
        37.7,
        36.3,
        38,
        39,
        38.7,
        40.5,
        40.8,
        40.8,
        42.1,
        42.2,
        42.5,
        43.1,
        43.1,
        42.7,
        42.7,
        41.7,
        41.4
      ]
    },
    {
      "name": "Bricks",
      "data": [
        52.1,
        50.8,
        50.8,
        50.9,
        50.7,
        51.1,
        51,
        50.9,
        49.1,
        50.9,
        52.2,
        52.1,
        52.7,
        51.9,
        51.7,
        54.3,
        54.2,
        55.1,
        55.5,
        55.5,
        54.3,
        55.3,
        55.7,
        54.8
      ]
    },
    {
      "name": "Beaver Builder",
      "data": [
        46.8,
        46.7,
        47.4,
        47.9,
        48.7,
        50.5,
        50.3,
        50.4,
        49.6,
        51.1,
        51.5,
        50.9,
        52.1,
        51.8,
        52,
        53.3,
        53.2,
        53.6,
        54,
        54,
        53.8,
        54.8,
        54,
        53.4
      ]
    }
  ],
  "colors": [
    "#fc4269",
    "#f59e0b",
    "#a78bfa",
    "#00ff9d",
    "#38bdf8"
  ]
}

Cómo leerlo: cada línea es una tecnología y su altura, el porcentaje de sitios que aprueba ese mes. Las cinco suben de forma casi paralela, y los constructores mantienen su orden durante los 24 meses.

{
  "type": "line",
  "title": "EVOLUCIÓN EN OTRAS PLATAFORMAS (24 MESES)",
  "subtitle": "% de orígenes que aprueban Core Web Vitals en móvil, octubre de 2024 a septiembre de 2026",
  "unit": "%",
  "max": 100,
  "categories": [
    "oct 24",
    "nov 24",
    "dic 24",
    "ene 25",
    "feb 25",
    "mar 25",
    "abr 25",
    "may 25",
    "jun 25",
    "jul 25",
    "ago 25",
    "sep 25",
    "oct 25",
    "nov 25",
    "dic 25",
    "ene 26",
    "feb 26",
    "mar 26",
    "abr 26",
    "may 26",
    "jun 26",
    "jul 26",
    "ago 26",
    "sep 26"
  ],
  "series": [
    {
      "name": "Wix",
      "data": [
        63.5,
        61.5,
        64.6,
        61.9,
        65.1,
        69.3,
        69.7,
        70.6,
        70.8,
        73.4,
        75.7,
        73.9,
        74.2,
        74.9,
        73.6,
        76.2,
        79.7,
        80.2,
        80.7,
        80.7,
        80.1,
        80.4,
        81.2,
        80.9
      ]
    },
    {
      "name": "Shopify",
      "data": [
        72.9,
        75.2,
        75.8,
        75.4,
        75.8,
        77.2,
        77,
        76.1,
        75.2,
        76.6,
        77.4,
        76.2,
        76.5,
        77.9,
        77.3,
        78.2,
        78.9,
        79.5,
        79.1,
        79.3,
        76.5,
        76.9,
        76.5,
        76.2
      ]
    },
    {
      "name": "Astro",
      "data": [
        65,
        64.5,
        64.6,
        61.7,
        60.5,
        62.8,
        62.2,
        61.1,
        59.7,
        62.8,
        63.4,
        61.6,
        62.7,
        62.1,
        62.5,
        65,
        66.9,
        67.7,
        67.8,
        67.7,
        67.2,
        69.8,
        71,
        71.1
      ]
    },
    {
      "name": "Next.js",
      "data": [
        27.8,
        27.8,
        28.3,
        27.4,
        27.3,
        27.8,
        27.6,
        27.1,
        26,
        27,
        27.9,
        28.1,
        29,
        29.7,
        29.8,
        31,
        30.9,
        31.6,
        32.8,
        32.9,
        32.5,
        33.9,
        35.1,
        35.7
      ]
    },
    {
      "name": "WordPress",
      "data": [
        42.9,
        42.9,
        42.8,
        42.6,
        43.3,
        44.7,
        44.9,
        44.8,
        43.4,
        44.3,
        45,
        45,
        46.1,
        46.3,
        46.4,
        47.9,
        48.1,
        48.7,
        49.1,
        49.3,
        48.8,
        49.5,
        48.7,
        48.3
      ]
    }
  ],
  "colors": [
    "#00ff9d",
    "#38bdf8",
    "#f59e0b",
    "#fc4269",
    "#a78bfa"
  ]
}

Cómo leerlo: igual que el gráfico anterior, con otras plataformas. WordPress aparece de nuevo como referencia. Shopify tiene su máximo en marzo de 2026 y baja un poco después; Astro tuvo un mínimo en junio de 2025 y remontó.

El orden entre grupos no cambia en dos años. Lo que sí cambia es el nivel: la web, en general, mejora.

¿Qué métrica falla en cada grupo?

Aprobar es un “y”: basta que una de las tres métricas falle para quedar fuera. Por eso importa ver cuál falla.

Tabla 3: Porcentaje de orígenes con resultado bueno en cada métrica, móvil, septiembre de 2026

TecnologíaLCP buenoINP buenoCLS buenoTTFB buenoAprueban en total
WordPress (todo)55,4 %90,3 %87,3 %22,9 %48,3 %
Elementor41,0 %88,3 %88,7 %15,2 %36,3 %
Divi48,5 %94,5 %81,0 %18,4 %41,4 %
Bricks59,3 %92,5 %93,9 %23,8 %54,8 %
Beaver Builder58,3 %95,3 %89,7 %22,9 %53,4 %
Editor de bloques (WordPress)60,4 %90,4 %86,6 %25,0 %52,0 %
Wix84,8 %92,6 %97,9 %74,3 %80,9 %
Shopify87,7 %86,7 %92,4 %83,8 %76,2 %
Squarespace78,0 %97,3 %89,5 %76,6 %71,0 %
Webflow78,6 %88,0 %93,6 %73,1 %71,3 %
Astro81,1 %85,0 %93,6 %63,1 %71,1 %
Hugo87,6 %89,6 %92,4 %65,5 %78,2 %
Next.js53,5 %59,7 %73,5 %45,6 %35,7 %
Gatsby64,4 %76,0 %71,4 %52,7 %43,7 %
Drupal76,1 %89,1 %88,6 %45,6 %64,7 %
Joomla68,6 %87,4 %86,4 %36,7 %57,4 %

Cómo leerla: cada celda es el porcentaje de orígenes con esa métrica en “bueno”. Por ejemplo, que WordPress tenga 90,3 % en INP significa que casi nueve de cada diez de sus sitios responden bien al tocar. La última columna es el resultado conjunto de la Tabla 1. El TTFB no entra en la evaluación de Core Web Vitals; se muestra porque llega antes que el LCP y ayuda a explicarlo.

WordPress y sus constructores: se pierde en la carga

En WordPress el INP es bueno en 90,3 % de los sitios y el CLS en 87,3 %. El LCP, en cambio, solo en 55,4 %, y el TTFB en 22,9 %. En Elementor el patrón es el mismo, más acusado: LCP 41,0 % y TTFB 15,2 %. Los constructores en general mantienen un INP alto (Divi 94,5 %, Beaver Builder 95,3 %, Bricks 92,5 %).

Esto contradice una creencia frecuente: que los constructores visuales arruinan la interactividad. En estos datos no es así. Lo que separa a los constructores es el LCP: Bricks (59,3 %) y Beaver Builder (58,3 %) frente a Divi (48,5 %) y Elementor (41,0 %).

Por qué importa el servidor

El LCP se compone de cuatro partes y la primera es el TTFB, el tiempo que tarda el servidor en empezar a responder. Web.dev da como referencia aproximada que el TTFB ocupe cerca del 40 % del tiempo total del LCP, y considera “bueno” un TTFB de 0,8 segundos o menos. Si el servidor tarda, todo lo demás empieza tarde.

Aquí los grupos se separan con claridad. En las plataformas alojadas, el TTFB bueno va del 73,1 % (Webflow) al 83,8 % (Shopify). En WordPress y sus constructores va del 12,1 % (WooCommerce) al 25,0 % (editor de bloques). Es una diferencia de unos 50 puntos o más.

Una explicación plausible, que estos datos sugieren pero no prueban: en una plataforma alojada el proveedor controla el servidor, la caché y la red de entrega (CDN); en WordPress cada persona elige su propio hosting, su configuración y su caché. Por eso en WordPress la variación entre sitios es enorme, y por eso el servidor es el primer sospechoso.

Next.js y Gatsby: también se pierde en la interactividad

Next.js suma un problema que WordPress no tiene. Su LCP bueno es de 53,5 %, parecido al de WordPress, pero además su INP bueno es de 59,7 %, el más bajo del análisis, y su CLS de 73,5 %; Gatsby tiene INP 76,0 % y CLS 71,4 %. Web.dev explica que la hidratación (el proceso con el que una página renderizada en el servidor llega ya dibujada, pero necesita que el navegador le “conecte” el JavaScript para responder a los clics) puede tener un impacto negativo importante en el TBT (una medida de laboratorio del tiempo que la página queda bloqueada) y el INP, y que la cantidad de JavaScript necesaria tiende a crecer con la aplicación. Es coherente con lo visto, pero los datos no permiten afirmar que sea la causa en cada sitio concreto.

Astro, cuya documentación presenta el “cero JavaScript por defecto” como una característica, tiene un INP de 85,0 %, algo por debajo del de WordPress (90,3 %). Su fortaleza está en el LCP (81,1 %) y el CLS (93,6 %).

Peso de página y Lighthouse: pistas que engañan

Tabla 4: Medianas de peso de página y puntaje de Lighthouse en móvil, septiembre de 2026

TecnologíaPeso total (KB)JavaScript (KB)Imágenes (KB)Puntaje LighthouseAprueban CWV móvil
WordPress (todo)2.719,9676,71.041,443,048,3 %
Elementor2.9407101.103,539,536,3 %
Bricks2.329,3578,3590,749,054,8 %
Wix2.767,71.756,7188,861,080,9 %
Shopify4.014,92.287,5749,547,576,2 %
Squarespace3.571,51.494,91.073,730,071,0 %
Webflow3.479,9925,781262,571,3 %
Astro1.357,6408,6354,770,071,1 %
Hugo1.426,9305,3489,770,078,2 %
Next.js2.169,7821,6408,753,035,7 %
Drupal2.412,2665,8846,347,564,7 %

Cómo leerla: los pesos son medianas en kilobytes (1 KB = 1.000 bytes) de la página rastreada; el puntaje de Lighthouse va de 0 a 100 y es una medición de laboratorio: una prueba simulada, hecha una vez y en condiciones fijas, no con visitantes reales. La última columna repite el resultado de campo para comparar.

La tabla desmonta una idea cómoda. Shopify tiene la página más pesada de la tabla (una mediana de más de 4.000 KB) y un puntaje de Lighthouse de 47,5, pero aprueba en 76,2 % de los casos. Squarespace tiene el Lighthouse más bajo (30) y aprueba en 71,0 %. Wix envía una mediana de más de 1.700 KB de JavaScript y aprueba en 80,9 %. En sentido contrario, Bricks tiene una página bastante más ligera que WordPress y un Lighthouse algo mejor, pero no aprueba tanto como Shopify.

El peso y la nota de laboratorio no predicen por sí solos el resultado de campo. Pesan más cosas que la tabla no ve: dónde están los archivos, qué se guarda en caché, cuánto tarda el servidor y cuánta gente visita desde móviles potentes.

¿Se mantiene entre sitios de popularidad parecida?

El ranking global compara sitios muy distintos: una tienda con millones de visitas y un blog personal con cien. El Tech Report permite filtrar por rangos de popularidad (Top 10M, Top 1M, Top 100k). Piensa en estos rangos como filtros de popularidad: cuanto menor es el número, más exclusivo el grupo. No se detalla en la documentación consultada cómo se calcula ese rango, así que sirve como aproximación de popularidad, no como medida exacta de tráfico.

Tabla 5: Porcentaje que aprueba en móvil por rango de popularidad, septiembre de 2026 (entre paréntesis, orígenes evaluados)

TecnologíaTodosTop 10MTop 1MTop 100k
WordPress (todo)48,3 % (2.658.175)49,9 % (1.941.100)50,1 % (110.537)52,9 % (7.552)
Editor de bloques (WordPress)52,0 % (543.833)52,9 % (396.145)51,5 % (25.207)51,3 % (1.665)
Elementor36,3 % (877.513)38,1 % (623.703)36,7 % (25.844)37,7 % (838) *
Divi41,4 % (150.144)42,5 % (103.456)40,4 % (2.315)39,6 % (53) *
Bricks54,8 % (10.701)55,3 % (8.464)46,3 % (410) *23,1 % (13) *
Shopify76,2 % (445.297)77,0 % (396.054)63,7 % (47.954)38,3 % (1.830)
Webflow71,3 % (59.483)70,9 % (45.726)49,8 % (2.635)26,9 % (156) *
Astro71,1 % (47.277)71,2 % (32.563)54,5 % (3.087)44,7 % (441) *
Wix80,9 % (177.709)77,6 % (78.498)52,5 % (823) *59,1 % (22) *
Next.js35,7 % (395.345)33,8 % (274.458)25,5 % (39.764)24,3 % (5.890)
Drupal64,7 % (93.193)65,1 % (80.303)58,6 % (11.658)47,3 % (967) *

Cómo leerla: cada columna es un subconjunto de sitios más populares. Un asterisco (*) marca una muestra de menos de 1.000 orígenes: son cifras poco fiables y no deben usarse para comparar. En Top 100k casi todas las muestras son pequeñas.

Lo que sí se ve con muestras fiables:

  • Top 10M (muestras grandes). El orden se mantiene prácticamente igual: WordPress 49,9 %, Elementor 38,1 %, Shopify 77,0 %, Next.js 33,8 %.
  • Top 1M. Aquí cambia la historia. Las plataformas alojadas y los generadores estáticos bajan mucho: Shopify pasa de 76,2 % a 63,7 % (47.954 orígenes), Webflow de 71,3 % a 49,8 % (2.635) y Astro de 71,1 % a 54,5 % (3.087). WordPress casi no se mueve (48,3 % a 50,1 %, con 110.537 orígenes). Con ello Webflow (49,8 %) queda en el mismo nivel que WordPress (50,1 %), y Astro (54,5 %) algo por encima.
  • Wix, Squarespace, Hugo y Bricks en Top 1M tienen menos de 1.000 orígenes cada uno: sus caídas (Wix pasa de 80,9 % a 52,5 %) sugieren lo mismo, pero con poca fiabilidad.
  • Elementor y Next.js siguen al final con muestras fiables: 36,7 % y 25,5 %.

Lectura honesta: parte de la ventaja de las plataformas alojadas en el ranking global viene de que hay muchísimos sitios pequeños y sencillos en ellas. Entre sitios más populares, la ventaja se reduce o desaparece, salvo en Shopify, que sigue por encima (63,7 % frente a 50,1 %). Lo que no cambia es que Elementor y Next.js quedan abajo.

Por qué esto no es causa y efecto

Que el grupo de Wix apruebe más que el de Elementor no significa que cambiarte a Wix te lleve al 80,9 %. Hay al menos cinco razones:

  1. Sesgo de selección. Quien elige Wix o Shopify suele querer un sitio sencillo y no tocar nada técnico; quien instala Elementor y plugins suele tener sitios más variados y a veces más cargados. Los grupos no son comparables entre sí.
  2. El hosting va incluido en las plataformas alojadas. En ellas servidor, caché y red vienen en el paquete. En WordPress son decisiones tuyas. Una parte de la brecha puede ser “hosting bueno frente a hosting variable”, no “plataforma frente a plataforma”. Es el mismo motivo por el que la elección del servidor pesa tanto, y de eso va el artículo sobre Hostinger.
  3. Muestras muy distintas. Hay 2.658.175 orígenes de WordPress y 6.043 de Hugo. Los porcentajes de las muestras pequeñas son más inestables, como una encuesta a muy pocas personas: un par de respuestas distintas cambian el resultado.
  4. La detección de tecnología tiene límites. HTTP Archive usa su propia versión de Wappalyzer y reconoce que toda herramienta de detección tiene limitaciones. Un sitio puede no detectarse o clasificarse mal. Además, el Web Almanac señala que HTTP Archive ya incluye páginas secundarias además de la portada, aunque algunos análisis siguen usando solo la portada.
  5. Solo cuentan los sitios elegibles en CrUX. Los sitios con poco tráfico no entran. Y como CrUX mide solo Chrome con estadísticas activadas, no incluye todo el tráfico real.

Y un matiz más: mismas métricas no significa mismo contexto. Un sitio de contenido y una tienda con carrito, pasarela de pago y decenas de scripts de terceros no tienen el mismo punto de partida.

Qué hacer según tu caso

Si estás en WordPress (con Elementor, Divi u otro constructor)

Los datos apuntan a que lo primero es la carga, no el constructor:

  1. Mide tu servidor. El TTFB es lo que más separa a WordPress de las plataformas alojadas. Web.dev da 0,8 segundos como referencia. Revisa tu plan de hosting (un plan compartido barato comparte recursos con otros sitios), activa caché de página y considera una CDN.
  2. Revisa la imagen principal. Web.dev advierte que el recurso del LCP debe ser descubrible en el HTML inicial, que nunca debe cargarse en diferido (lazy-load, es decir, esperar a que el visitante se acerque para cargarla) y que dar prioridad alta a más de una o dos imágenes deja de ayudar.
  3. Recorta scripts de terceros. Según web.dev, los recursos de terceros mal construidos pueden ralentizar mucho la carga; carga con async o defer (le dicen al navegador que no se detenga a esperar ese script) lo que puedas y difiere lo que no sea crítico. Cada widget de chat o píxel tiene un coste.
  4. Después, el constructor. Si ya arreglaste servidor, caché e imagen y el LCP sigue siendo el problema, ahí sí compara el peso y el resultado de tu constructor con alternativas más ligeras.

Cuándo cambiar de plataforma tiene sentido (y cuándo no)

Cambiar tiene sentido cuando tu sitio es sencillo, no necesitas lo que ofrece WordPress y no quieres encargarte del servidor. Tiene menos sentido si el problema es solo un servidor mediocre: eso se arregla sin migrar. Y ten presente el coste de salir: el contenido hecho con un constructor suele quedar atado a él, como cuento en Bricks Builder y otros constructores de WordPress.

¿Pesan más los recursos que la plataforma? Lo que dicen 309 tecnologías

Hasta ahora se compararon plataformas por su nombre. Esta sección hace otra pregunta: si miramos muchas tecnologías a la vez, ¿las que mandan páginas más pesadas aprueban menos? Es una forma de probar la idea de que importan más los recursos (lo que pesa y lo que ejecuta la página) que la plataforma. Aquí cada “dato” es una tecnología completa, no un sitio suelto: se compara, por ejemplo, el peso típico de las páginas de WordPress con el de las de Astro, y no un sitio con otro.

Qué tecnologías entraron

El Tech Report lista 3.577 tecnologías. De ellas, 1.496 tienen al menos 1.000 orígenes móviles. Para quedarse con plataformas y herramientas de construcción, y no con analítica, publicidad o chats, se filtró por estas categorías de HTTP Archive: CMS, Page builders, JavaScript frameworks, Web frameworks, Static site generator, Ecommerce, Blogs, WordPress themes y Ecommerce frontends. Quedaron 309 tecnologías, todas con datos de septiembre de 2026. Para cada una se consultaron /cwv y /page-weight con geo=ALL y rank=ALL: el porcentaje de orígenes con LCP, INP y TTFB buenos, el porcentaje que aprueba en conjunto y la mediana de bytes de imágenes, JavaScript y total, en móvil. Se exigió un mínimo de 500 orígenes evaluados en la métrica usada en cada comparación; ninguna tecnología quedó fuera por eso.

Cómo leer una correlación

Una correlación mide si dos cosas tienden a moverse juntas. Es un número entre -1 y 1. Cerca de 0 significa que no hay relación; cerca de 1, que cuando una cosa sube la otra también; cerca de -1, que cuando una sube la otra baja. Un ejemplo cotidiano: la estatura y el peso de las personas tienen correlación positiva (a medida que una sube, la otra tiende a subir), mientras que la talla de zapato y la nota en una prueba de cultura general no tienen ninguna. Y “tienden” es la palabra clave: no hay una regla exacta, solo una inclinación general con excepciones.

Se usaron dos versiones. La de Spearman solo mira el orden: ordena las tecnologías de menos a más pesadas, las ordena de peor a mejor resultado, y comprueba si los dos órdenes se parecen. La de Pearson se calculó sobre el logaritmo de los bytes, que mira cuánto cambia el resultado y hace que doblar el peso cuente igual en una página ligera que en una pesada. Si ambas dan algo parecido, la conclusión es más sólida.

Cada correlación va con un intervalo de confianza del 95 %, que es un rango razonable donde probablemente está el valor real. Se calculó por remuestreo (bootstrap): repetir el cálculo muchas veces con versiones al azar de la propia lista de tecnologías, para ver cuánto se mueve el resultado. Si el intervalo incluye el 0, el valor real podría ser perfectamente “sin relación”.

Tabla 6: Correlaciones entre tecnologías, móvil, septiembre de 2026

Relación entre tecnologíasSpearman (IC 95 %)Pearson con log de bytes (IC 95 %)Tecnologías
TTFB bueno y LCP bueno0,58 (0,48 a 0,67)0,52 (0,39 a 0,63)309
Peso mediano de JavaScript e INP bueno-0,35 (-0,46 a -0,24)-0,36 (-0,49 a -0,21)309
Peso mediano total y aprobación total-0,22 (-0,33 a -0,09)-0,23 (-0,34 a -0,10)309
Peso mediano de imágenes y LCP bueno0,03 (-0,09 a 0,15)0,11 (-0,02 a 0,25)309

Cómo leerla: cada fila compara dos números de las 309 tecnologías, y entre paréntesis va el intervalo de confianza. Un signo negativo en “peso e INP” significa que a más JavaScript, menos sitios con INP bueno. El resto se lee igual: un número positivo es “a medida que sube uno, tiende a subir el otro”. Un intervalo que cruza el 0, como el de las imágenes, indica que no hay relación detectable.

Lo que sale

  • JavaScript e INP: relación moderada. Spearman -0,35 (de -0,46 a -0,24). A medida que sube el peso del JavaScript, el porcentaje de sitios con INP bueno tiende a bajar. Todo el intervalo es negativo, así que es poco probable que la relación sea puro azar.
  • TTFB y LCP: la más fuerte. Spearman 0,58. A medida que sube el porcentaje de sitios con buen TTFB, el de sitios con buen LCP tiende a subir. Las tecnologías cuyos sitios responden rápido suelen tener también buen LCP. Parte de esta relación viene incorporada: el TTFB es una de las cuatro partes del LCP según web.dev, así que no prueba por sí sola que el servidor sea la causa.
  • Peso total y aprobación: débil. Spearman -0,22. La tendencia existe (más peso, algo menos de aprobados), pero con muchas excepciones.
  • Peso de imágenes y LCP: sin relación. Spearman 0,03, con un intervalo que incluye el 0. Es un resultado, no un hueco: con estos datos, que la página típica de una tecnología pese más en imágenes no va con un peor LCP. Saber cuánto pesan sus imágenes casi no ayuda a adivinar cuántos de sus sitios tienen buen LCP.
{
  "type": "column",
  "title": "MÁS JAVASCRIPT, MENOS SITIOS CON INP BUENO",
  "subtitle": "Promedio de % con INP bueno, por quintil de peso mediano de JavaScript (KB), móvil, sept. 2026",
  "unit": "%",
  "max": 100,
  "categories": [
    "1: hasta 542 KB",
    "2: 545 a 695 KB",
    "3: 695 a 935 KB",
    "4: 944 a 1.329 KB",
    "5: desde 1.330 KB"
  ],
  "series": [
    {
      "name": "Promedio de las tecnologías del grupo",
      "data": [
        86.9,
        87.1,
        86.8,
        80.1,
        73.6
      ]
    }
  ],
  "colors": [
    "#fc4269"
  ]
}

Cómo leerlo: las 309 tecnologías se ordenaron de menos a más JavaScript y se dividieron en cinco grupos del mismo tamaño (quintiles); cada columna es el porcentaje medio con INP bueno de su grupo. Los tres primeros grupos están igual (86,9 %, 87,1 % y 86,8 %) y la caída llega en los dos últimos (80,1 % y 73,6 %). No es una pendiente suave: el efecto aparece con medianas de JavaScript altas.

{
  "type": "column",
  "title": "IMÁGENES MÁS PESADAS, ¿PEOR LCP?",
  "subtitle": "Promedio de % con LCP bueno, por quintil de peso mediano de imágenes (KB), móvil, sept. 2026",
  "unit": "%",
  "max": 100,
  "categories": [
    "1: hasta 506 KB",
    "2: 508 a 785 KB",
    "3: 785 a 1.018 KB",
    "4: 1.018 a 1.284 KB",
    "5: desde 1.289 KB"
  ],
  "series": [
    {
      "name": "Promedio de las tecnologías del grupo",
      "data": [
        62.5,
        64.1,
        69.6,
        64.5,
        67.1
      ]
    }
  ],
  "colors": [
    "#38bdf8"
  ]
}

Cómo leerlo: igual que el anterior, pero con el peso de las imágenes y el LCP bueno. Las columnas (62,5 %, 64,1 %, 69,6 %, 64,5 % y 67,1 %) no suben ni bajan de forma ordenada: no hay patrón.

Qué no dice este resultado

  • Es una comparación entre tecnologías, no dentro de un sitio. Que las tecnologías con más JavaScript tengan peor INP no demuestra que quitarle JavaScript a tu sitio lo mejore. Para eso haría falta medir el mismo sitio antes y después.
  • El peso es una mediana por tecnología. Resume la página rastreada de muchos sitios distintos, y los bytes no son lo mismo que el trabajo del navegador: web.dev explica que el INP depende de tareas largas en el hilo principal (el único “carril” donde el navegador hace casi todo su trabajo) y del tamaño del DOM (la cantidad de elementos de la página), no solo de cuánto JavaScript se descarga. En las imágenes, además, el LCP depende de que la imagen se descubra pronto, no solo de cuánto pese, como indica web.dev.
  • Hay variables que se mezclan: el tipo de visitantes, el hosting y el tipo de sitio (tienda, blog, portal) influyen a la vez en el peso y en el resultado.
  • Cada tecnología cuenta igual, sea grande o pequeña.

Qué puntos respalda y cuáles no puede probar

Los datos respaldan con matices dos ideas: que el JavaScript pesado se asocia con peor INP y que el servidor (TTFB) va ligado al LCP. No encuentran relación entre el peso de las imágenes y el LCP. Y no pueden probar nada sobre las tipografías, las animaciones ni la carga progresiva, porque HTTP Archive no las mide en estas consultas.

Mi punto de vista: los recursos pesan más que la plataforma

Hasta aquí han hablado los datos. Esta sección es mi opinión y mi experiencia trabajando sitios, y conviene leerla como tal: no sale del análisis y el análisis no la demuestra.

Mi idea de fondo es que la velocidad depende menos del framework o la plataforma y más de los recursos con los que se arma la página. Hay frameworks que funcionan mejor que otros, pero igual hay que comprobarlo en cada proyecto. La velocidad no lo es todo, aunque sí es un factor.

Dónde suele perderse la velocidad

Los datos de este análisis encajan con parte de lo que veo: el grupo de WordPress falla sobre todo en LCP y TTFB, que son justo la imagen principal y el servidor. La comparación entre 309 tecnologías de la sección anterior apoya la relación del JavaScript con el INP y la del servidor con el LCP, pero no encuentra relación entre el peso de las imágenes y el LCP. Estos son los puntos en los que pongo la atención:

  • Imágenes. Formato, compresión y peso. Y pensarlas para escritorio y para móvil, no una sola para los dos. Muchos sitios no usan imágenes ligeras.
  • Tipografías. A menudo no se sirven desde el servidor del propio sitio, y eso perjudica. Alojar tú mismo los archivos de la fuente ayuda mucho.
  • Estilos y animaciones. Muchas páginas se construyen con librerías de animación o efectos 3D. Se ven espectaculares, pero si es lo primero que se carga, la página probablemente será más lenta.
  • Carga progresiva. Buscar estrategias para que la información aparezca poco a poco, en la medida de lo posible.
  • El servidor. Importa mucho: un hosting compartido afecta a la velocidad.
  • Los detalles pequeños. Cuidar los scripts, las fuentes y el manejo de las imágenes; un video corto, ligero y bien comprimido; animaciones ligeras y rápidas.

Lo que afecta a imágenes, servidor y scripts de terceros ya está respaldado por las recomendaciones de web.dev de la sección anterior. Lo de las tipografías, las animaciones y la carga progresiva es mi experiencia, sin una fuente en este artículo.

Hay otra conexión con los datos, más débil. En el Top 1M la brecha entre plataformas se reduce bastante, lo que es coherente con la idea de que importa menos la plataforma y más cómo está construido el sitio. Pero no la prueba: los datos no miden cómo se construyó cada sitio, y la reducción puede tener otras explicaciones, como las del apartado de causa y efecto.

Mis puntuaciones en PageSpeed Insights

Estas cifras son de mis proyectos y son puntuaciones de laboratorio de Lighthouse, una medida distinta del porcentaje de sitios que aprueban Core Web Vitals en datos de campo que usan las tablas. Ninguna sale de este análisis. Como se explicó al principio, los datos de laboratorio y los de campo miden cosas distintas.

  • Con Bricks he llegado a entre 70 y 80. Cuanta más carga le pones, más limita.
  • Con Elementor, resultados parecidos.
  • Con temas propios, las puntuaciones superan con holgura los 90, alrededor de 95.
  • Con Astro, también he obtenido puntajes alrededor de 95.

Alterno entre Bricks, Elementor y temas propios según el proyecto. Los temas propios los hago con Tailwind y a veces Vite, para no cargar lo que no hace falta. Este sitio, además, está hecho con Astro.

No persigas el 100 y prioriza según tu objetivo

No me obsesionaría con un 100 sobre 100 en PageSpeed Insights. El objetivo es una experiencia manejable: prueba el sitio en tus propios dispositivos y comprueba que funciona bien.

También depende de para qué sea el sitio. La mayoría de los sitios no tienen una marca consolidada, así que una página súper disruptiva puede no ser la prioridad. Yo pondría primero las llamadas a la acción, los textos y cómo te encuentra la gente y qué encuentra. Las marcas con peso y reconocimiento sí pueden apostar por estrategias más visuales.

La arquitectura también compensa

Que todo esté a pocos clics desde el inicio, con buen uso del pie de página, el menú y la navegación, y una buena forma de mostrar las secciones, mejora la experiencia y puede compensar no tener la página más rápida. Cómo organizarlo lo cuento en Arquitectura Web para SEO.

Tu primer paso

Pon tu dominio en PageSpeed Insights. Mira la sección de datos de campo (la de usuarios reales), no la nota de Lighthouse, y activa la vista de todo el origen si no hay datos de tu página. Si dice “Evaluación de Core Web Vitals: aprobada”, ya estás con el grupo que más aprueba; si no, mira qué métrica falla (LCP, INP o CLS) y empieza por la de este artículo que corresponda a tu plataforma. Si no aparecen datos de campo, tu sitio todavía no tiene suficientes visitas para entrar en CrUX.

Fuentes y lecturas recomendadas

Etiquetas#Velocidad web#Core Web Vitals#WordPress#Elementor#HTTP Archive#CrUX#Wix#Shopify
RUTA DE LECTURA RECOMENDADA

Más allá del código: estrategia, escalabilidad e impacto

Lecturas clave para conectar la arquitectura técnica con el valor de negocio y rentabilidad.

EXPLORAR CATEGORÍA COMPLETA→