Hemos analizado los tiempos de carga de 18,5 millones de dominios para saber más sobre la velocidad de sus páginas. En este artículo aprenderás por qué el nombre de Wix no es el único problema y cómo funciona WordPress.
- Resumen de las principales conclusiones:
- ¿Por qué es importante el tiempo de carga de los sitios web?
- ¿Cómo se mide el rendimiento de los sitios web?
- España: más del 33% de los sitios no son lo suficientemente rápidos
- Tendencia positiva: los sitios web se están volviendo un poco más rápidos cada mes
- Las tablets también son "malos escritorios"
- 27º lugar: España necesita mejorar
- CMS: Jimdo el más rápido, Wix incluso más lento que WordPress
- Sistemas de tienda: Shopify en el centro, WooCommerce en la parte inferior
- Tecnologías web: AMP más lento de lo esperado
- CDNs: usar las páginas rápidas rápidamente
- Antecedentes: qué (y cómo) hemos medido
- Conclusión
La velocidad de carga de los sitios web será un factor oficial de ranking en Google a partir del año que viene. La optimización de los tiempos de carga es un proceso largo, por lo tanto, ya deberías estar tratando el tema.
¿Tienes poco tiempo? Aquí nuestros resultados más importantes del análisis:
Resumen de las principales conclusiones:
- Los tiempos de carga en Alemania aún no cumplen las expectativas de Google: el 25% están por encima de los 2,5 segundos por defecto. España supera el 33% de sitios mejorables.
- Sin embargo, la tendencia apunta en la dirección correcta: la proporción de sitios web rápidos ha mejorado un 1% desde el año pasado.
- Internet en España ocupa la posición 27, Alemania en la posición 9, por delante de los EE.UU., Inglaterra e incluso Singapur.
- Jimdo muestra que los CMS basados en la nube pueden ofrecer muy buenos valores. Pero las tecnologías de código abierto también pueden hacerlo: Typo3 es solo un poco más lento.
- Ningún CMS es más lento que Wix: la linterna roja de la categoría CMS, aún detrás de WordPress, muestra de manera impresionante que la nube no es rápida en sí misma.
- Lightspeed ofrece un sistema de tienda extraordinariamente rápido. Shopify está solo en la mitad inferior. El AddOn de WordPress WooCommerce es el sistema de tienda más lento.
- El lenguaje de programación no es crucial para las tecnologías web: hay frameworks rápidos en Ruby on Rails, PHP (Yii & Laravel), Python (Django) y otros lenguajes. Solo Angular es realmente lento.
- AMP no conduce automáticamente a sitios web rápidos. Solo alrededor del 70% de las páginas de AMP cumplen con las métricas de Core Web Vitals.
Si dispones de un poco de tiempo, aquí está el análisis completo con todos los datos y muchos más resultados interesantes sobre los tiempos de carga, los sistemas rápidos y lentos y las conexiones detrás de ellos:
¿Por qué es importante el tiempo de carga de los sitios web?
La experiencia del usuario es uno de los factores más importantes para el éxito de los sitios web. Los tiempos de carga son la base de una buena experiencia de usuario: si el visitante tiene que esperar «demasiado» tiempo para que una página se cargue, salta y busca otra fuente.
Por ejemplo, Google ha determinado en un estudio que al aumentar el tiempo de carga de 1 a 3 segundos se obtiene un 32% más de tasa de rebote. Si el tiempo de carga aumenta a 5 segundos, la probabilidad de que el visitante salga de la página aumenta hasta en un 90%.
¿Cómo se mide el rendimiento de los sitios web?
Para que la experiencia de los usuarios en los sitios web sea medible existen diversos instrumentos y enfoques. Con Core Web Vitals Google proporciona 3 cifras clave uniformes y comparables. Estos Core Web Vitals serán un factor de ranking adicional el año que viene y, por lo tanto, tienen una influencia directa en la posición de una página en los resultados de Google.
Para los 3 Core Web Vitals, ya hemos detallado información, varios métodos de medición y posibilidades de mejora en otro artículo. Por lo tanto, solo un breve recordatorio:
- Largest Contentful Paint (LCP) – El tiempo hasta que se carga el mayor bloque de contenido. Apto = Menos de 2,5 segundos.
- First Input Delay (FID) – El tiempo hasta que el usuario puede interactuar con la página. Apo = Menos de 0,1 segundo.
- Cumulative Layout Shift (CLS) – Indicador de cuánto cambia la disposición durante la carga. Apto = Menos de 0,1 segundo.
En este análisis hemos utilizado el valor del contenido más grande (LCP), excepto para el primer diagrama, porque esta es la medida elemental de los 3 Core Web Vitals para medir el tiempo de carga de la página.
España: más del 33% de los sitios no son lo suficientemente rápidos
En el primer paso, analizamos cómo se comportan los accesos a sitios web desde España para los tres indicadores de Core Web Vitals. Google ha definido tres áreas para cada una:
- Bueno (verde) – Si el valor está dentro de las expectativas de Google.
- Mejorable (amarillo) – Si supera las expectativas pero no se desvía demasiado de ellas.
- Pobre (rojo) – Si el valor medido está claramente lejos de los objetivos.
En base a esto, los tres Google Core Web Vitals dan como resultado la siguiente distribución para España:
Con el Largest Contentful Paint (LCP) algo más del 66% de todos los accesos ya son buenos. Google califica el 15% de los resultados como malos. El LCP es el indicador clave del Core Web Vitals, ya que refleja más directamente el tiempo de carga real.
El First Input Delay (FID), es decir, el tiempo hasta la interacción, tiene los mejores valores: el 87% de los resultados ya son buenos y solo el 2% son calificados como malos por Google. Quien tenga que ponerse al día aquí debe darse prisa para no quedarse atrás.
Con el Cumulative Layout Shift (CLS), el desplazamiento del diseño durante el proceso de carga, se nota que las páginas web pasan esta prueba (verde) o la suspenden por completo (rojo) – solo hay unos pocos valores de mejora (amarillo).
Tendencia positiva: los sitios web se están volviendo un poco más rápidos cada mes
Para entender cómo se han desarrollado los tiempos de carga en los últimos meses:
Aunque los progresos no han sido rápidos se observa una tendencia ligeramente positiva: desde noviembre de 2019 el número de mediciones deficientes ya ha disminuido en algo más de 1 punto porcentual y las mediciones buenas se mueven entre el 66% y el 67%. La dirección es correcta: los sitios web se están volviendo un poco más rápidos cada mes.
Las tablets también son «malos escritorios»
Pasemos al siguiente análisis, la evaluación separada por tipo de dispositivo: ordenador de escritorio, teléfono móvil y tableta. Aquí están los resultados:
No es sorprendente que las páginas web se carguen más rápido en el dispositivo de escritorio que en el teléfono móvil. Una conexión a internet frecuentemente conectada por cable y más potencia de computación son factores decisivos aquí. Sin embargo, la diferencia entre el dispositivo de escritorio y el móvil es menor de lo que se esperaba.
Es interesante el pobre rendimiento de las tabletas. Una posible explicación es que las tabletas suelen mostrar la versión de escritorio de las páginas web debido a su pantalla más grande pero el hardware de las tabletas es más comparable al de los teléfonos móviles. Esto lleva a un rendimiento de tiempo de carga significativamente peor.
27º lugar: España necesita mejorar
Las métricas de Core Web Vitals medidos en los sitios webs solo dependen en parte del rendimiento del propio sitio web: la velocidad, el rendimiento y la latencia de la conexión a internet del usuario también influyen en el resultado.
Aunque el propietario de un sitio web no tiene medios para optimizar la conexión a internet de sus propios visitantes, un análisis de las métricas de Core Web Vitals por país muestra estas diferencias muy claramente. Aquí está el análisis de una selección de los países más importantes:
En China y Corea del Sur el 82% de las visitas a sitios web cumplen con las expectativas de rendimiento de Google, un valor máximo y el líder mundial. Le siguen los países nórdicos: Suecia, Noruega, Dinamarca, pero también Japón y Taiwán.
En este análisis España está en 27° lugar, detrás de grandes potencias como Inglaterra (posición 20) o Alemania (posición 9), casi 10 puntos porcentuales por detrás. Si nos fijamos en el otro lado, existe una mejora en el 40% de los sitios.
Los tiempos de carga en Rusia y Estados Unidos son aproximadamente comparables. Y el hecho de que Asia no siempre es sinónimo de internet rápido queda demostrado por las pobres cifras de Tailandia y Vietnam.
Kiribati, un estado insular en el Océano Pacífico, demuestra los efectos de una ubicación extremadamente remota y una conexión a internet vía satélite: solo alrededor de una cuarta parte de todos los accesos son buenos y casi el 60% de los accesos son calificados como pobres por Google.
CMS: Jimdo el más rápido, Wix incluso más lento que WordPress
Los sistemas de gestión de contenidos (CMS) son la columna vertebral de internet: la mayoría de los sitios web funcionan en base a esos programas informáticos. Desde la peluquería de al lado, a la empresa mediana, al sitio con muchos millones de visitantes cada día.
Hemos combinado nuestra base de datos de tecnologías web con las mediciones de Core Web Vitals para evaluar las velocidades de carga de los sistemas de gestión de contenidos más utilizados. Vayamos directamente al análisis:
Jimdo, el kit de construcción de la página web de Hamburgo, Alemania, ofrece el mejor rendimiento para mostrar el contenido más grande. Más del 82% de las visitas a los sitios web que funcionan en Jimdo cumplen con las expectativas de rendimiento de Google.
El hecho de que incluso el CMS autoalojado también puede ofrecer un muy buen rendimiento se muestra en Typo3 como la solución casi en segundo lugar en el análisis. Cualquiera que haya tenido que desarrollar con Typo3 a menudo recuerda la complejidad con horror. La velocidad de este CMS basado en PHP no se detiene ahí.
WordPress, de lejos el CMS más común, solo llega al penúltimo lugar. Alrededor de la mitad de los sitios web funcionan con WordPress – pero también hay muchos que dan poco valor a los buenos tiempos de carga. Google clasifica alrededor del 20% de los accesos a sitios web basados en WordPress como malos, otro 21% como mejorables.
En último lugar se encuentra Wix, esta solución de la nube tan solo puede ofrecer buen rendimiento en la mitad de todos los accesos. Casi una cuarta parte es calificada por Google como malo con Core Web Vitals.
Este pobre desempeño es particularmente notable considerando que tanto el ganador de este análisis (Jimdo) como el perdedor (Wix) tienen las mismas condiciones de partida: soluciones en la nube, donde el proveedor controla todo el sistema y puede optimizar cada parte (pero obviamente no siempre lo hace).
Sistemas de tienda: Shopify en el centro, WooCommerce en la parte inferior
Ya en 2006 Amazon determinó que un aumento de los tiempos de carga de 0,1 segundos provocaba una reducción del 1% en las ventas. Esto no ha mejorado en los últimos 14 años. Los buenos tiempos de carga son elementales para las tiendas online.
La combinación de nuestra base de datos de «Tecnologías» y los datos sobre los tiempos de carga da como resultado el siguiente análisis para todos los sistemas de tiendas que hemos visto con suficiente frecuencia en el desierto de internet libre:
Como ganador, Lightspeed hace honor a su nombre: los dominios con Lightspeed tienen un valor de casi el 93% para el Largest Contentful Paint (LCP), que Google califica como bueno. Solo el 2% está calificado como malo. Estas son las mejores cifras que hemos medido en este análisis en todas las evaluaciones.
Lightspeed tiene la ventaja inherente de ser una solución para la nube. Por lo tanto, el proveedor controla todo el sistema y puede optimizar la velocidad de todas las áreas. El hecho de que también se pueden lograr muy buenos tiempos de carga con las tiendas autoalojadas, lo demuestra la solución de código abierto osCommerce, que también tiene un muy buen 84%.
La actual estrella fugaz de la tienda, Shopify, solo entra en la mitad inferior del análisis. Aunque en principio las posibilidades son las mismas que con Lightspeed (totalmente alojado por el propio proveedor), esta ventaja no puede traducirse en tiempos de carga superiores a la media.
La extensión de WordPress WooCommerce está muy por detrás en el último lugar. Solo un poco menos de la mitad de las tiendas de WooCommerce cumplen actualmente con las especificaciones de Google. Un alarmante 26% son incluso malos. El alojamiento autogestionado de la solución por parte de proveedores de masa a menudo de bajo rendimiento, es muy claro aquí.
Tecnologías web: AMP más lento de lo esperado
Esta evaluación trata de una amplia gama de tecnologías web: desde tecnologías de Backend para crear páginas web, bibliotecas de JavaScript y CSS para el diseño y la interacción hasta AMP de Google.
En la siguiente tabla se enumeran solo las tecnologías con los usos más identificados en nuestros datos. Se clasificaron las tecnologías de la web utilizadas con menos frecuencia. Por supuesto, solo se podrían evaluar los sitios web de acceso público. Aquí el análisis:
Ruby on Rails, un esquema de trabajo (framework) basado en Ruby desarrollado por el fundador de Basecamp, es, con mucho, el líder: casi el 85% de todos los sitios web que utilizan esta tecnología ofrecen páginas web dentro de los límites establecidos por Google para una buena calificación de Largest Contentful Paint (LCP).
Pero los frameworks PHP como Yii (74%) o Laravel (73%) también dan buenos resultados. Para que nadie se sienta en desventaja: Python también está bien representado con el framework de Django (75%) y ASP.NET (77%) está incluso en segundo lugar. Hemos aprendido: La velocidad no se debe al lenguaje de programación sino a la implementación concreta.
Es notable que AMP no es una de las tecnologías más rápidas. Accelerated Mobile Pages (AMP) es un derivado del HTML promovido principalmente por Google. Se supone que numerosas restricciones hacen que las páginas AMP se carguen significativamente más rápido en el teléfono móvil que las páginas HTML clásicas.
Los resultados no son convincentes: menos del 70% de los dominios AMP cumplen con los requisitos de Google. Aparentemente Google ya ha reconocido esto y en el futuro relegará los privilegios de AMP en los bloques de Top Stories a aquellos sitios que puedan mostrar buenas métricas de Core Web Vitals..
AMP ya no será necesario para que esas URLs aparezcan en Top Stories en el móvil, sino que estará abierto a cualquier página.
Google Webmaster Central Blog, Evaluating page experience for a better web
La única tecnología web que no garantiza que más de la mitad de los dominios cumplan con los requisitos de Google es Angular. Irónicamente, un framework de trabajo para aplicaciones de frontend desarrollado y proporcionado por Google …
CDNs: usar las páginas rápidas rápidamente
Los Content Delivery Networks (CDN) proporcionan servidores distribuidos globalmente, de modo que el contenido puede ser transmitido al visitante del sitio web de manera más corta y, por lo tanto, más rápida. Además de especialistas como Akamai, los principales proveedores de nube también ofrecen CDNs.
En esencia, todos los CDNs funcionan de manera similar. Tampoco pueden cambiar los límites físicos. Por lo tanto, en la siguiente evaluación debe hacerse una distinción entre causalidad y correlación:
No puede suponerse que los CDN más rápidos sean la razón de la ventaja, pero sí se da el caso de que los operadores de sitios orientados al rendimiento recurren a estos CDN.
Los dominios que se basan en Fastly como CDN se cargan en promedio mucho más rápido que los que se basan en otros proveedores. Google se coloca en segundo lugar, pero Amazon y Microsoft (Azure) tampoco se quedan atrás.
El hecho de que Akamai esté más abajo en la línea está relacionado con los clientes típicos de la compañía: se trata de empresas transnacionales bastante grandes que a menudo operan con sistemas lentos heredados. Esta no es la mejor manera de ofrecer sitios web modernos y rápidos.
Fireblade, el final de este análisis, no ofrece un CDN clásico sino un cortafuegos de aplicación web: la aplicación filtra el tráfico de internet para las llamadas potencialmente peligrosas y las bloquea. Cualquiera que tenga que recurrir a esa oferta tenderá también, por lo general, a utilizar aplicaciones web más antiguas y no optimizadas y, por lo tanto, ya tiene desventajas estructurales en este análisis.
Antecedentes: qué (y cómo) hemos medido
La medición de las velocidades de carga tiene una larga historia: desde la medición original del comienzo de la entrega de HTML puro (TTFB, Time To First Byte) hasta el First Contentful Paint y las tres mediciones actuales del Core Web Vitals con el Largest Contentful Paint como métrica central, ha llovido mucho.
Para el análisis hemos utilizado las bases de cálculo oficiales del Google Core Web Vitals. Para ello existen dos métodos de medición diferentes: los datos de laboratorio, es decir los valores medidos por el usuario en las propias condiciones de laboratorio, y los datos de campo, que son medidos por un panel de usuario. Para este análisis hemos evaluado los datos de campo. En SISTRIX puedes acceder a los datos de laboratorio y datos de campo. En total, hemos analizado los tiempos de carga de 18,5 millones de dominios.
A excepción de las tres primeras evaluaciones, que se refieren exclusivamente a los valores medidos en España, el análisis restante incluye valores medidos de todo el mundo. Los valores de escritorio, móvil y tableta también se han evaluado.
Hemos combinado estos valores medidos con el reconocimiento de tecnología en SISTRIX para poder sacar conclusiones sobre soluciones de software y de tecnología. Para el reconocimiento de la tecnología, rastreamos regularmente grandes partes de internet y comparamos las características encontradas («huellas dactilares») con nuestra lista de más de 1.000 tecnologías de internet. Al hacerlo, solo hemos incluido en el análisis final las combinaciones de tecnología y Core Web Vitals que se producen en un número suficiente de dominios para lograr una estadística significativa.
Conclusión
Google pone la experiencia del usuario en el punto de mira con el nombramiento del Core Web Vitals como el factor de ranking oficial. En nuestro análisis pudimos mostrar cuán amplio es aún el rango de valores medidos. Dependiendo del software y la tecnología utilizada todo se representa entre «ya perfecto» y «mucho trabajo».
Como ocurre en otras acciones SEO, mejorar los tiempos de carga debe ser un proceso continuo: no una tarea de una sola vez, sino un proceso permanente y monitoreado. Requerirá una atención periódica e incluso los objetivos deberán ser ajustados de vez en cuando.
La optimización de los tiempos de carga no es una tarea esencial en SEO pero tendrá un impacto en el rendimiento orgánico de un sitio web en los resultados de búsqueda. Por lo tanto, el SEO es una vez más una función transversal que debe reunir muchas áreas de una empresa.
Nosotros mismos hemos descuidado durante mucho tiempo los tiempos de carga de nuestro sitio web. En las últimas semanas hemos abordado el tema y hemos notado el gran esfuerzo que requieren (muy) buenos valores. Y sin embargo vale la pena: no solo Google está contento con eso, especialmente los usuarios reales nos lo agradecen. Por lo tanto: no te duermas con este tema. Es mejor abordarlo este año que posponerlo para el próximo.