Hemos llegado a una encrucijada en el desarrollo web. La proverbial bifurcación se encuentra entre la funcionalidad para las empresas en línea y la experiencia para los visitantes del sitio web.
Por un lado, las empresas, presionadas por el tiempo y el dinero, quieren incluir en sus sitios web todas las funciones de marketing posibles. Por otro, los visitantes quieren que la página se cargue rápidamente y que se pueda interactuar con ella sin tener que cambiar de ubicación o esperar a que los plugins se carguen en segundo plano.
Sin embargo, estos dos objetivos rara vez se alinean. Llega Core Web Vitals.
Las Core Web Vitals forman parte de los indicadores de experiencia utilizados por Google para determinar si una página ofrece una buena experiencia o no. El mes pasado, Searchmetrics realizó un estudio investigando más de 2 millones de URLs para averiguar si las páginas web eran útiles o no. Tuvimos que descubrir que solo el 4% o menos de las páginas obtienen una buena puntuación en las tres puntuaciones.
¿Pero, por qué este número es tan bajo?
Una de las razones principales es que el software, los plugins y las aplicaciones que son realmente útiles para los profesionales del marketing, como la segmentación automática del correo electrónico o el rastreo analítico, tienden a tener el gran inconveniente de ralentizar considerablemente los tiempos de carga de las páginas web. Se añaden a esto, los recursos externos que hay que buscar normalmente, antes de que una página pueda renderizarse.
Pero esta situación de la economía de los plugins se ha convertido en la norma para las empresas, desde las grandes plataformas de comercio electrónico hasta las nuevas empresas de MVP, la funcionalidad de las empresas está venciendo a la experiencia del usuario.
En una reciente entrevista con Martin Splitt, de Google, se le hizo la siguiente pregunta:
«¿La actualización de Core Web Vitals permitirá que a la gente le vaya mejor si su sitio tiene una puntuación más baja porque está usando una aplicación de terceros?»
Martin afirmó que las reglas son las mismas para todos: cualquier cosa que empeore la experiencia del usuario podría ser castigada por Google. Así que, aunque la funcionalidad ayude a los usuarios, si ralentiza la página, podría ser sancionada.
Pero como la mayoría de las empresas y editores no tienen acceso a programadores de CMS y plugins, la pregunta del millón es la siguiente: ¿cómo pueden las empresas acelerar su sitio web y pasar Core Web Vitals, manteniendo la funcionalidad que necesitan?
En este artículo se describe la situación actual que presentan los Core Web Vitals, se ofrecen datos específicos del sector y se ofrece orientación sobre cómo mejorar la velocidad de su sitio web.
Vamos a empezar!
En primer lugar, un vistazo a las principales razones por las que los sitios web no superan las pruebas de Core Web Vitals.
1) Los sitios utilizan más recursos de los que necesitan
¿Cómo lo sabemos? Hemos analizado más de 2 millones de URL en un estudio reciente de Core Web Vitals y sólo alrededor del 4% obtuvo una buena puntuación en las tres categorías. La mayoría de los sitios tienen muchos recursos que bloquean la renderización y son pesados en términos del tamaño total de la página.
2) Los recursos (aunque sean necesarios) no están optimizados
Para optimizar el rendimiento, es mejor renderizar solamente lo que necesita inmediatamente el usuario, es decir, lo que es visible. Esto incluye imágenes y vídeos, pero también recursos externos como CSS y JavaScript.
3) Muchas compañías y editores no tienen la capacidad de modificar las plantillas o el código del CMS
Modificar el código no es la norma. Las plantillas de sitios web y los plugins todavía se consideran soluciones de caja negra, una vez que están en funcionamiento, eso es todo. Aunque las plataformas CMS y los desarrolladores de plugins no han facilitado precisamente a los usuarios la modificación del código, es una parte esencial de la optimización SEO y, a menudo, donde pueden estar las mayores ganancias de rendimiento.
Información de interés: ¿Son todas las industrias iguales?
Searchmetrics ha llevado a cabo el mayor estudio de este tipo, analizando más de dos millones de URL en términos de rendimiento de Core Web Vitals. Profundizaron un poco más para ver si estos problemas son específicos del sector.
El contenido más grande de la página web (Largest Contentful Paint)
El LCP mide el tiempo que tarda en cargarse el elemento más grande de una página. Según Google, los sitios deberían aspirar a un LCP de 2,5 para obtener una buena calificación. Al observar los datos, hay dos valores atípicos: los sitios de viajes y los de tipo diccionario. El primero está más cerca de los 3,5 y el segundo de los 2,8 segundos, respectivamente.
Por qué es así: Los sitios de viajes tienden a utilizar en exceso las imágenes grandes, mientras que sitios como Wikipedia mantienen las imágenes pequeñas.
Respaldando esta afirmación, también podemos ver a continuación que las imágenes del sector de los viajes son las menos optimizadas y los sitios de tipo diccionario los mejores:
Tiempo total de bloqueo (Total Blocking Time)
El TBT es una métrica que empleamos como proxy fiable del Retraso de la Primera Entrada (explicado en detalle en el estudio), efectivamente, el tiempo que pasa antes de que un usuario pueda interactuar con una página web.
Un buen TBT es de unos 0,3 segundos. Mientras que la media del TBT en todos los sitios que analizamos fue de 0,7 segundos, los sitios del nicho B2B fueron los que obtuvieron los mejores resultados con un TBT de 0,5 segundos.
El motivo es este: Parece que los grandes sitios B2B con conocimientos de SEO son los que más han avanzado en la optimización de sus páginas.
Si se observa el tamaño medio de las páginas web (el tamaño total de todos los activos que carga la página), esta conclusión se ve respaldada por el hecho de que los sitios B2B son, por término medio, los más pequeños, con sólo 2,36 MB, frente a los 4,12 MB de los sitios de noticias:
Desplazamiento acumulativo de la disposición (Cumulative Layout Shift)
El desplazamiento de diseño acumulado mide la cantidad de desplazamientos o saltos de una página web durante la carga. Las causas típicas de los cambios de diseño son los banners emergentes, los banners de cookies, los formularios de consentimiento, los formularios de registro de correo electrónico y los anuncios.
No son estos elementos los que provocan el desplazamiento, sino el hecho de que no se tengan en cuenta en la maquetación de una página y luego se carguen por encima.
Hemos comprobado que la media de CLS se sitúa en torno a 0,38 para los sitios web estadounidenses. Este valor está muy por encima del punto de referencia para una buena puntuación de 0,1 y es donde la mayoría de los sitios web pierden en términos de Core Web Vitals, ya que alrededor del 95% no logran una buena puntuación.
Los sitios de noticias y medios de comunicación y los viajes fueron los sectores con peores resultados, con un CLS de 0,42. No es de extrañar, ya que estos segmentos tienden a ser muy publicitarios.
Los sitios de tipo diccionario obtuvieron los mejores resultados, con un CLS medio de 0,32, significativamente menor, pero aún muy alejado de la referencia.
El motivo es que los sitios como Wikipedia tienden a utilizar un diseño muy básico y uniforme, imágenes mínimas y menos anuncios que los sitios de viajes y noticias.
3 correcciones básicas de Web Vitals
Ahora que ya hemos visto los datos, pasemos a las posibles soluciones:
1) Pregúntate si realmente necesitas esa aplicación, plugin o bloque de código
La forma más fácil de acelerar tu sitio es hacerlo más eficiente. Esto significa eliminar los plugins que no necesitas. Para sopesar esto, ejecuta una auditoría de Lighthouse y comprueba cuánto tiempo te están costando esos plugins.
Si observamos bbc.com, podemos ver que la página de inicio del sitio de noticias podría ahorrar 1,28 segundos sólo con esperar a que la página se haya renderizado para cargar los archivos JavaScript y CSS (ver más abajo cómo hacerlo). Además, en la pestaña de JavaScript no utilizado, el sitio podría ahorrar 1,25 segundos eliminando el código JavaScript que ni siquiera se utiliza.
Esto está respaldado por nuestros hallazgos, que en promedio los sitios de noticias podrían ahorrar más de un segundo eliminando el JavaScript no utilizado:
2) Identifica los elementos críticos de la página y optimice lo que realmente necesita
Tenga en cuenta que para algunas de estas soluciones puede ser necesario trabajar con un desarrollador.
- Comprimir imágenes/vídeos – Prueba a utilizar plugins de compresión de png como Squoosh para reducir el tamaño de las imágenes sin perder calidad.
- Los formatos de imagen de próxima generación WebP de Google pueden reducir el tamaño de la imagen en más de un 25% sin perder calidad.
- Inline critical JS and CSS – Efectivamente, el código se divide en crítico y no crítico, cargándose primero el crítico.
- Carga perezosa (Lazy Load): significa que los elementos como las imágenes y los vídeos que no son visibles de inmediato (por debajo del pliegue) se cargan sólo cuando se necesitan, es decir, cuando el usuario se desplaza hacia abajo. Aquí tienes una guía para principiantes sobre la carga lenta de imágenes.
3) Comunicar los problemas a los desarrolladores de plugins y aplicaciones
El espacio de plugins y aplicaciones es un mercado altamente competitivo. Como tal, tienes influencia como usuario. Abra un diálogo con los problemas específicos que tiene. Si es posible, pida a sus desarrolladores web que examinen de cerca los plugins que se utilizan en su sitio web. Esto puede hacerse ejecutando una auditoría Lighthouse. Preste atención al tiempo que tarda su página en cargarse y a la cantidad de tiempo que podría ahorrar eliminando los recursos que bloquean la renderización.
Perspectiva de Core Web Vitals
Está claro que existe una gran división entre el rendimiento del sitio y la experiencia del usuario. Sin embargo, nunca se ha ganado tanto con la optimización de su sitio web. Con la actualización de Core Web Vitals, la experiencia del usuario seguirá siendo el centro de atención. Actúe ahora y podrá obtener grandes beneficios en términos de rendimiento del sitio.
Source link
