Google Core Web Vitals y PageSpeed ¿Es realmente nuestro problema?

Google está «encargando» a los usuarios y webmasters de software como WordPress y no a los desarrolladores que arreglen sus páginas para Core Web Vitals. ¿Es eso justo?. No está solo si está luchando por mejorar las puntuaciones de Core Web Vitals y se está quedando sin opciones ante la imposibilidad de mejorar. La evidencia anecdótica sugiere que lograr un alto rendimiento de Core Web Vitals es difícil. La razón es porque los editores y el SEO están tratando de arreglar algo que técnicamente no está roto.

¿Cambio en la forma en que se diseñan los sitios?

Estamos en las etapas iniciales de un gran cambio de paradigma sobre cómo se crean las páginas web. Un servidor web más rápido es útil, pero no solucionará los problemas de Core Web Vitals.

Los resultados de Core Web Vitals se calculan en sentido descendente en el dispositivo móvil que está absorbiendo sus páginas web en un teléfono móvil a velocidades 3G o 4G. De ahí es de donde provienen los datos de Core Web Vitals y un servidor web rápido es de poca utilidad en ese momento si la descarga está siendo limitada por una mala conexión a Internet en el teléfono.

Mejorar Core Web Vitals tiene menos que ver con el alojamiento web y más con corregir el código.

Core Web Vitals, un dolor de muelas

Los estándares básicos de Core Web Vitals no son algo que los desarrolladores de WordPress tengan en mente al crear este CMS. Es por eso que la incorporación de tweets en una publicación activará el cambio de diseño acumulativo.

WordPress y los temas no codifican para Google. Codifican para las necesidades de los editores que hasta mayo de 2020 no eran una necesidad imperiosa para estos. Tampoco es solo WordPress. La mayoría de los otros sistemas de administración de contenido no tienen las mejores prácticas de Core Web Vitals integradas. Y resulta aún peor, porque WordPress, al fin y al cabo, es un CMS ligero y con multitud de plugins para intentar solucionar o, en menor medida, minimizar el desastre, pero el resto de CMSs, comenzando por Joomla! están en paños menores. A ver qué pasa con la esperada versión 4.

Volviendo a WordPress, eso no significa que haya algo mal. No hay nada de malo con WordPress porque Google dice que algo no está funcionando como Google quiere.

Core Web Vitals es un conjunto de métricas desarrolladas de forma independiente por Google y enviadas al editor y a la comunidad de SEO para trabajar. WordPress no tuvo nada que ver con eso. Esta métrica apareció en mayo de 2020, aparentemente sin ninguna coordinación o consulta con el sector de desarrolladores.

En el lado de WordPress, el desarrollo avanza como si Core Web Vitals no existiera. Mientras que en el lado de los editores y del SEO, son los usuarios de WordPress los que tienen la carga de «arreglar» WordPress, Drupal, Joomla!, phpBB, etcétera.

En un mundo perfecto, el trabajo de crear un sistema que aborde las necesidades de los usuarios recae en el lado del desarrollador. Pero eso no está sucediendo. WordPress ni siquiera ve a Core Web Vitals como un problema propio. Cuando alguien inició un hilo de soporte en los foros de WordPress respecto a este tema, se le dijo que preguntara en el foro de soporte de Google. La respuesta: "You should ask on a Google forum, as WordPress has nothing to do with this" -"Debería preguntar en un foro de Google, ya que WordPress no tiene nada que ver con esto"-.

Editores y SEOs presionados

Los editores de WordPress están atascados tratando de hacer que los sitios web se ajusten a un estándar que esos sitios web nunca fueron diseñados para cumplir. Esta es la razón por la que tantos están luchando con Core Web Vitals. Los editores y los SEOs tienen la carga de intentar arreglar algo que, idealmente, debería arreglarse a nivel de código.

Mejorar las puntuaciones de Core Web Vitals puede parecer como intentar mejorar el rendimiento de un Opel Corsa a los estándares de un Ferrari. Los desarrolladores no construyeron un Ferrari, construyeron un Open Corsa. 

Pero Google exige que los conductores (no los fabricantes) mejoren el rendimiento a un nivel de Ferrari. ¿Es una broma? ¿Es razonable pedir a los usuarios de un software que lo mejoren en lugar de a los desarrolladores del software?

Entonces, ¿por qué los editores y la comunidad de SEO tienen la carga de arreglar algo de lo que solo son usuarios?. Realmente, esta forma de procedeer de Google no es nueva, es la que lleva haciendo 20 años. Deja ahí el problema y que venga otro y lo solucione.

Google y su postura de macho alfa

Google proporciona muchas herramientas para diagnosticar los problemas y ofrece artículos detallados que explican cómo solucionar esos problemas de codificación. Pero estos son problemas de codificación, no problemas de usuario.

Un ejemplo de la desconexión entre la comunidad de desarrolladores y Google es el problema del cambio de diseño acumulativo, donde la página web cambia y se reorganiza a medida que se descargan los elementos de la web.

Una razón común para el cambio de diseño acumulativo es que las imágenes no tienen un tamaño de alto y ancho declarado. Google recomienda soluciones exóticas como usar CSS para diseñar las imágenes usando cuadros de relación de aspecto. El editor promedio y el SEO probablemente no entenderán qué son los cuadros de relación de aspecto y cómo calcular las proporciones en todo el sitio de una manera que no rompa el diseño web.

Muchas plantillas web configuran rutinariamente los anchos de imagen a través de CSS para que sean automáticos (ancho: automático;) sin establecer la altura y el ancho de las imágenes para hacer que las imágenes como un logotipo escalen en tamaño para que entren correctamente en una plantilla, independientemente de si se ve en un dispositivo móvil o dispositivo de escritorio. Ésa es una práctica de codificación común que provoca un cambio de diseño acumulativo.

Estas son las razones por las que WP Rocket tuvo que profundizar y realizar cambios en CSS y JavaScript en todo el sitio. Por ejemplo, WordPress Gutenberg -nuevo editor de WordPress- carga todo el CSS que existe, independientemente de si es necesario o no. Entonces, el desarrollador de WP Rocket tuvo que implementar una solución para este problema. Y así lo explicó:

“… Desaprobamos varios bloques que no se usaron. Creamos un sistema de puesta en cola personalizado para que CSS y JS carguen bloques solo cuando sea necesario. Nos tomó solo unos minutos desarrollar este sistema.

También decidimos no utilizar el archivo CSS de Gutenberg. En su lugar, "migramos" el CSS que realmente necesitábamos a nuestra propia hoja de estilo, a un archivo CSS dedicado. Eso fue todo".

Replanteamiento de cómo se crean los sitios

Es importante comprender el problema de Core Web Vitals. Google exige que los editores y los SEO utilicen soluciones que la comunidad de desarrollo de CMS no muestra interés en abordar. Este es un ejemplo de los tipos de compromisos a los que nos enfrentamos y cómo Google está cambiando la forma en que desarrollamos sitios web.

Hablemos ahora de fuentes, de tipografía.

El bloqueo de procesamiento de recursos de terceros puede afectar negativamente a la pintura con contenido más grande -Largest Contenful Paint-. Un cuello de botella común es la descarga de fuentes de un sitio de terceros como Google Fonts. Sí, ¡de Google!.

Hay una serie de trucos para aplicar que son una combinación del uso del atributo de enlace de precarga y tal vez algo de JavaScript, que hace que el proceso de descarga de fuentes de terceros Core Web Vitals sea más fácil.

Una solución simple que ayudará a obtener una mejor puntuación es cambiar la fuente del sitio web a una fuente sans serif que los dispositivos Apple, Windows y Android ya han cargado en su sistema. Cambiar a una fuente atractiva que está integrada en el dispositivo significa que el sitio ya no tiene que esperar para descargar una fuente elegante.

Un enfoque correcto puede ser algo como esto:

familia de fuentes: Helvetica, Tahoma, sans-serif;

Si Android no tiene Helvetica o Tahoma ya cargados en el navegador, el dispositivo mostrará el sitio con la fuente Roboto. Para las personas acostumbradas a usar fuentes elegantes, el uso de tipografías del sistema puede parecer extremo. Pero es un ejemplo de los tipos de compromisos que un editor web puede necesitar hacer, en particular los editores que se encuentran en nichos altamente competitivos. Por ejemplo una web de afiliados cuya mayor preocupación es la velocidad y las conversiones. Tiene un serio problema, aunque cambiar la fuente no sea uno de ellos si consigue mantener sus visitas.

¿Y el futuro? 

Lo que está pasando hoy es que vivimos un momento de transición. Las cosas están cambiando desde cómo hicimos las cosas en el pasado hasta cómo los desarrolladores van a hacer las cosas (listas para usar) en el futuro. Los desarrolladores respondieron a la demanda de sitios optimizados para dispositivos móviles. Con el tiempo, es posible que comiencen a responder a la demanda de sitios que tengan una buena puntuación en Core Web Vitals.

La forma en que se diseñan los sistemas, las plantillas y los complementos de CMSs no se ha adaptado a las necesidades de los editores que requieren una buena puntuación en Core Web Vitals. Por el momento, los SEO tecnológicos y la comunidad de desarrolladores están atascados en tener que «arreglar» lo que no está roto para que se ajuste a la idea de Google de cómo debería verse la web.

Por supuesto, una página que se carga rápido y no se desplaza es algo bueno. Pero exigir a los usuarios de un software que mejoren dicho software es en sí ina carga. En este momento, la tarea de arreglar el código recae en los usuarios del software de publicación y no en los desarrolladores de ese software. Parece una inocentada, pero es la realidad.

Lo que puede suceder es que a algunos les resulte útil arreglar todo lo que puedan y dejar el resto para cuando WordPress y otros software CMSs se pongan al día. Desde aquí aconsejamos no dedicar demasiado tiempo a mejorar las puntuaciones de Core Web Vitals, entre otras cosas porque es imposible, como hemos dicho antes, a no ser que quiera presentar una página de los años 90, con texto, pocas imágenes y muy pequeñas y nada de CSS y JS.