1 ▷ Es Google Core Web Vitals tu problema⁉️

google core web vitals no es tu problema

Es Google Core Web Vitals tu problema?

Google hace recaer en los usuarios de software como WordPress, y no en los desarrolladores, la responsabilidad de solucionar el problema de Core Web Vitals. ¿Es eso justo?

No eres el único que lucha por mejorar tu puntuación en Core Web Vitals. La evidencia anecdótica sugiere que puede ser difícil lograr un alto rendimiento de Core Web Vitals. La razón es que los editores y los SEO están tratando de arreglar algo que no está técnicamente roto.

Un cambio de paradigma en el desarrollo de sitios

Estamos en las primeras etapas de un importante cambio de paradigma en la forma de construir sitios web. Los alojamientos web más rápidos son útiles, pero no resuelven el problema de la vitalidad del núcleo de la web.

Las Core Web Vitals se calculan en sentido descendente en un dispositivo móvil que sorbe sus páginas web a velocidades 3G o 4G en su teléfono. Aquí es donde entran en juego los datos de Core Web Vitals. Si la descarga se ve limitada por una mala conexión a Internet en el móvil, de poco sirve un servidor web rápido en este punto.

La mejora de los aspectos vitales de la web tiene que ver más con la fijación del código que con el alojamiento web.

Arreglar lo que no está roto

WP Rocket ha rediseñado recientemente su sitio web utilizando Gutenberg. Este fue un movimiento audaz y atrevido, ya que Gutenberg no tenía la capacidad de editar el sitio en ese momento.

Para mejorar la puntuación de experiencia de página de Google, tuvieron que ajustar la forma en que WordPress maneja el CSS y el JavaScript.

En otras palabras, al rediseñar el sitio para aumentar la puntuación de Core Web Vitals, WP Rocket tuvo que convertir el propio WordPress en algo para lo que no fue diseñado.

El núcleo de Web Vitals es poco amigable

Los estándares de Core Web Vitals no son lo que los desarrolladores de WordPress tienen en mente cuando lo crean. Por eso, al incrustar un tuit en una entrada se produce el cambio de diseño acumulativo.

WordPress y sus temas no están programados para Google. Codifican para las necesidades de los editores, que hasta mayo de 2020 no lo eran.

Y esto no sólo se aplica a WordPress. La mayoría de los otros sistemas de gestión de contenidos no tienen incorporadas las mejores prácticas de Core Web Vitals.

Eso no significa que haya algo malo en WordPress, porque Google te dirá que hay algo malo en WordPress.

El Core Web Vitals no es un problema de WordPress

Core Web Vitals es un conjunto de métricas que Google ha desarrollado y ha puesto a disposición de los editores y de la comunidad SEO para que trabajen con ellas.

WordPress no tiene nada que ver con esto. Core Web Vitals vió la luz en mayo de 2020, pero aparentemente no hubo coordinación ni colusión con el ecosistema de desarrolladores.

En cuanto a WordPress, el desarrollo continúa como si Core Web Vitals nunca hubiera existido. En el lado de los editores y del SEO, son los usuarios de WordPress los que soportan la carga de “arreglar” WordPress, Drupal, phpBB, etc.

En un mundo perfecto, la tarea de adaptar el sistema a las necesidades de los usuarios estaría en manos de los desarrolladores. Pero eso no es realista.

WordPress no considera que Core Web Vitals sea un problema de WordPress.

Alguien inició un hilo de soporte en los foros de WordPress sobre el tema y fue dirigido a preguntar en los foros de soporte de Google.

WordPress no tiene nada que ver con esto, deberías preguntar en los foros de Google“.

La carga del cumplimiento para los editores y la comunidad de SEO

Los editores de WordPress están atrapados tratando de hacer que sus sitios cumplan con los estándares para los que nunca fueron diseñados.

Por eso, muchos se ven acosados por el Core Web Vitals. Los editores y los SEO se encuentran con la carga de intentar arreglar cosas que idealmente deberían arreglarse a nivel de código.

Mejorar su puntuación de Core Web Vitals puede ser como intentar que el rendimiento de un Smart alcance el nivel de un Ferrari.

Los desarrolladores no construyeron el Ferrari. Construyeron un Smart.

Pero Google exige a los conductores (no a los fabricantes) que mejoren las prestaciones al nivel del Ferrari. ¿Te parece justo?

¿Es justo exigir mejoras a los usuarios del software y no a los desarrolladores del mismo?

El problema de la conformidad del software Core Web Vitals está en el nivel del código, no en el del usuario.

Entonces, ¿por qué los editores y la comunidad de SEO deben soportar la carga de arreglar algo que es sólo del usuario?

¿Es útil Google?

Google ofrece muchas herramientas para diagnosticar problemas y proporciona artículos detallados que explican cómo solucionar estos problemas de codificación.

Sin embargo, se trata de problemas de codificación, no de problemas de los usuarios.

Un ejemplo del desacuerdo entre la comunidad de desarrolladores y Google es el problema del cambio de diseño acumulativo, en el que una página web se desplaza y reposiciona cuando se descargan los elementos de la página.

Una de las causas más comunes del desplazamiento del diseño acumulado es que las imágenes no tienen dimensiones declaradas de altura y anchura; Google recomienda soluciones exóticas como el uso de CSS para estilizar las imágenes con cuadros de relación de aspecto.

El editor y el SEO promedio probablemente no entenderán lo que es una caja de relación de aspecto y cómo calcular la relación para todo el sitio de una manera que no rompa el sitio.

Echa un vistazo a esta descripción del cuadro de relación de aspecto que enlaza Google y mira si tiene sentido para ti.

“Cuadrados perfectos” y “16:9” están muy bien, pero los valores que se utilizan para ellos son simples matemáticas. Las relaciones de aspecto pueden ser cualquier cosa, pero generalmente son completamente arbitrarias. Un vídeo o una imagen pueden recortarse a cualquier tamaño.

Entonces, ¿cómo encontramos el relleno superior del SVG de 1127,34 x 591,44 de arriba?

Una forma es utilizar calc(), algo así.

padding-top: calc(591.44 / 1127.34 * 100%);”

Oh, Dios mío!

He aquí otro ejemplo. Muchas plantillas web utilizan CSS para establecer automáticamente la anchura de una imagen sin establecer la altura o la anchura de la misma (width: auto;), con el fin de ampliar una imagen como un logotipo para que quepa en la plantilla tanto en dispositivos móviles como de escritorio. Se trata de una práctica de codificación común que provoca Cumulative Layout Shift.

Debido a esto, WP Rocket tuvo que intervenir y cambiar el CSS y el JavaScript en todo el sitio.

Por ejemplo, WordPress Gutenberg carga todo el CSS que hay, sea necesario o no. Así que los desarrolladores de WP Rocket tuvieron que codificar a mano una solución para esto.

Así es como WP Rocket describe lo que hicieron como parte del rediseño

… Hemos eliminado algunos bloques que no se utilizaban. Hemos creado un sistema de cola de espera personalizado para que los bloques con CSS y JS sólo se carguen cuando sean necesarios. Sólo nos llevó unos minutos desarrollar este sistema.

También decidimos no utilizar los archivos CSS de Gutenberg. En su lugar, “migramos” el CSS que realmente necesitábamos a nuestras propias hojas de estilo y a archivos CSS dedicados. Esto ha funcionado bien.

Why WP Rocket Chose Gutenberg and How Performance Improved

Repensar cómo construir un sitio web

Es importante entender el problema central de la vitalidad de la web: Google está pidiendo a los editores y a los SEOs que se atornillen con soluciones que no interesan a la comunidad de desarrollo de CMS.

Estos son algunos ejemplos de los tipos de compensaciones a los que nos enfrentamos y de cómo Google está cambiando la forma de desarrollar los sitios web.

Hablemos de los tipos de letra

El bloqueo de recursos de terceros puede tener un impacto negativo en la pintura de mayor contenido. Un cuello de botella común es la descarga de fuentes de sitios de terceros como Google Fonts.

Hay una serie de trucos que son una combinación de uso de atributos de enlace de precarga y tal vez un poco de JavaScript, etc que hace que el proceso de descarga de fuentes de terceros núcleo web vital.

Pero, ¿se romperá tu sitio web si dejas de lado ese tipo de letra tan elegante?

Una solución sencilla que te ayudará a obtener mejores resultados es cambiar la fuente de su sitio web por una fuente sans-serif que ya esté cargada en los dispositivos Apple, Windows y Android.

El cambio a una fuente atractiva que está integrada en el dispositivo significa que el sitio web no tiene que esperar a descargar una fuente elegante.

Un enfoque podría ser algo así

font-family: Helvetica, Tahoma, sans-serif;

En Android, si la Helvetica o la Tahoma no están cargadas en el navegador, el dispositivo utilizará la fuente Roboto para mostrar el sitio web.

Para las personas que están acostumbradas a utilizar fuentes de fantasía, el uso de una fuente del sistema puede parecer extremo. Sin embargo, este es sólo un ejemplo de los compromisos que tienen que hacer los editores web, especialmente en nichos muy competitivos.

Para los sitios web de afiliados que se centran en la velocidad de la página y en las tasas de conversión, esta decisión es una obviedad.

Un momento de transición

Lo que ocurre hoy es que estamos viviendo un momento de transición. Estamos pasando de la forma en que siempre hemos hecho las cosas a la forma en que los desarrolladores harán las cosas en el futuro.

Los desarrolladores han respondido a la demanda de sitios web aptos para móviles. Es posible que los desarrolladores estén respondiendo a la demanda de sitios web con un alto nivel de Core Web Vitals.

La forma en que se desarrollan los sistemas CMS, las plantillas y los plugins no ha seguido el ritmo de las necesidades de los editores que necesitan tener en cuenta los aspectos vitales de la web.

En el futuro inmediato, los SEOs tecnológicos y la comunidad de desarrolladores tendrán que “arreglar” lo que no está roto para alinearse con la idea de Google de cómo debe ser la web.

Por supuesto, una página que se carga rápidamente y no se desplaza es algo bueno. Pero pedir a los usuarios del software que mejoren el propio software es una pesada carga.

Ahora mismo, la carga de arreglar el código recae en los usuarios del software de publicación, no en los desarrolladores del software. ¿Te parece bien?

Algunas personas pueden pensar que tiene sentido arreglar todo lo posible y dejar el resto para cuando WordPress u otro software CMS se ponga al día.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *