A la hora de pensar en posicionamiento orgánico de sitios web, el motor de búsqueda de Google predefine una serie de parámetros a cumplir para obtener mayor puntaje y, lógicamente, alcanzar las primeras posiciones. Para poder lograrlo, existen una serie de herramientas que pueden ser utilizadas. Este es el caso de Page Speed Insights.
Conocer a fondo esta herramienta es, como podrás ver a continuación, una buena opción para comenzar a pensar en una estrategia de marketing digital perfecta.
El SEO, en sí, no es una tarea que demande cumplir con reglas taxativas, paso a paso y punto por punto. Desde luego que existen factores que, de no existir (o de hacerse de otra manera diferente a la solicitada), puede llegar a afectar al posicionamiento en contra. Pero hablar de posicionamiento orgánico más bien refiere a otra cosa. Estamos hablando, en realidad, de un conjunto de pautas preestablecidas a raíz de una estrategia de marketing. Estas pautas, a su vez , indefectiblemente, deben condecirse con los requerimientos indicados por los motores de búsqueda.
El núcleo de las herramientas de Google
Es en virtud a esto que Google, si bien ofrece cierta libertad a la hora de planear el posicionamiento de los sitios, establece métricas que deben ser tenidas en cuenta tanto por quienes desarrollen los sitios web, como por quienes estén dispuestos a trabajar para posicionarse en los lugares más altos de Google.
Para ello, ofrece un sinfín de herramientas. Todas ellas, como verás, suelen trabajar con un mismo núcleo, el cual, según la herramienta que se trate, reperfilará los factores a analizar para terminar por entregarlos en una suerte de análisis de auditoría.
Al final del día, gracias a esto, el trabajo se verá sumamente simplificado, puesto que cada herramienta seleccionará los ítems a analizar (desde ese núcleo que anteriormente mencionamos), y los agrupará en algunos parámetros superiores.
Page Speed Insights es una de estas herramientas. Su utilización es, como verás al final de este artículo, tan útil como sencilla. Pero es imprescindible comprenderla a fondo. Para esto, el día de hoy vamos a explicarte uno de los dos segmentos en los cuales la herramienta subdivide la información presentada en su análisis.
Como explicamos anteriormente, a los efectos de simplificar la comprensión de los análisis de auditoría que las herramientas ofrecen, veremos que nos encontramos con dos situaciones: por un lado, casi todas suelen basar sus parámetros en un núcleo principal que suele atenerse a métricas relacionadas con la experiencia de usuario o similares; por otra parte, el análisis presentado siempre se aglomera en un varios conjuntos de parámetros, los cuales reciben una puntuación, generalmente de cero a cien.
Page Speed Insights | Análisis de Datos
Page Speed Insights hace lo propio, pero a su vez presenta la información obtenida desde dos puntos de vista: los datos de campo y los datos de laboratorio. Hoy nos ocuparemos de comprender a fondo el primer conjunto.
Antes de continuar, es importante que conozcas un poco más acerca de cómo Google analiza los resultados obtenidos desde la ejecución del análisis para poder puntuar las métricas. Lógicamente, es en función a este puntaje el cómo será ponderada la URL en cuestión al momento de ser indexada en las páginas de resultados del motor de búsqueda.
Básicamente, al momento de analizar y poner un puntaje a la web indicada, Google establece tres umbrales: lento cuando es de 0 a 49, medio cuando es de 50 a 89, y rápido cuando se supera los 90 puntos. Para poder hacer esto, lo que se hace es evaluar el rendimiento de velocidad de la URL, definiéndolo desde la capacidad de percepción del ojo humano.
Ateniéndonos a esta capacidad de respuesta, diremos que existen tres límites de tiempo principales, los cuales deben ser contemplados seriamente al momento de pensar en posicionamiento orgánico en buscadores. Estos límites son los siguientes:
- 0.1 segundos: aquí el usuario interpretará que el sitio web está respondiendo de manera instantánea.
- 1 segundo: el usuario podrá notar que existe un leve retraso en la carga del sitio, pero su flujo de pensamiento permanecerá inmutable.
- 10 segundos: al llegar a este límite, será indispensable una retroalimentación por parte del sitio. Esto quiere decir que el usuario no esperará sentado a que la carga se complete, sino que querrá hacer otras actividades hasta que la demora termine. Será necesario darle un aviso estableciendo una comunicación que le indique que el proceso está por terminar.
CrUX | El Informe de Experiencia de Usuario de Google
En el año 2017, Google publicó un informe especial llamado Chrome User Experience Report. Básicamente, el objetivo del informe fue proporcionar las métricas de experiencia de usuario basadas en cómo aquellos que usaban Google Chrome (en el mundo real, a diferencia de los datos de laboratorio), experimentaban los destinos de la web.
En otras palabras, con él se podría llevar a cabo un análisis de datos aportados por usuarios reales que usaran el navegador en distintas condiciones (de hardware, de conexión, de software, etcétera) y así comprender cómo los cibernautas experimentaban los sitios web.
Los datos obtenidos se recopilaban a raíz de las sesiones de los usuarios siempre que se cumpliera alguna de estas condiciones:
- Si el usuario había habilitado la sincronización en su historial de búsqueda
- Cuando el usuario no había configurado alguna contraseña de sincronización
- En caso de que el usuario hubiera habilitado el informe estadístico de uso de la web
Esta información obtenida, al final del día, terminó por agruparse en las métricas que hoy conocemos, las cuales terminan por conformar el núcleo de análisis que mencionamos al inicio de este post.
Encontramos, entonces, varias que fueron de utilidad para todos los desarrolladores web y especialistas en posicionamiento orgánico. No obstante, a los efectos del análisis de los datos de campo de Page Speed Insights, nos centraremos en cuatro métricas específicas.
Datos de Campo | Métricas Analizadas y Cómo Mejorarlas
Una vez que se proporciona una URL para medir, la herramienta, en la sección de datos de campo, entrega el resultado de la auditoría efectuada basada en cuatro métricas. Las detallaremos a continuación.
Recuerda: es importante que sepas que cada URL puede tener decenas de oportunidades para mejorar el puntaje, aquí nos ocuparemos de las más significativas a nivel general.
FCP | First Contentful Paint
Esta métrica analiza el tiempo que transcurre entre que comienza a cargarse la página y el momento en que aparece el primer elemento con contenido, ya sea texto o imagen. Es importante aclarar este último punto.
Por una cuestión de carga de recursos, generalmente, lo que primero aparece en pantalla al momento de la carga, es el texto. Desde luego, puede que las imágenes sean súper livianas y que estén optimizadas al 100%, pero el texto siempre primará.
En virtud a esto es que debes tener en cuenta las fuentes que se utilicen en la web. Hay que aclarar que no constituyen uno de los recursos más pesados a la hora de pensar en la carga de la página. No obstante, sí representa uno de los puntos más importantes a la hora de ponderar el FCP.
Para solucionar este posible inconveniente, es muy recomendable bregar por que el texto siempre esté visible durante la carga. De hecho, debes tener en cuenta que algunos navegadores directamente ocultan el texto. Lo hacen hasta que la fuente está cargada, lo cual suele provocar lo que se conoce como el flash de texto invisible.
FID | First Input Delay
Esta métrica forma parte de las Web Core Vitals establecidas por Google en mayo de 2020. Básicamente su función consiste en medir el tiempo que transcurre desde que la página comienza a cargarse, hasta que un primer elemento permite interactuar con ella. Sobre ella, cabe mencionar que los elementos que causan su lentitud son, en principio (y respondiendo justamente a la interactividad), los scripts de Javascript. En segundo orden de importancia podríamos ubicar a las imágenes pesadas (no optimizadas) que, al cargarse hacen “mover” al sitio.
Al respecto de cómo mejorar esta métrica, encontramos un punto en cuestión contradictorio. Tomemos primero el caso de los scripts. Si en el HTML están ubicados en el lugar del head, al llegar el navegador a esa línea, terminará por tomarse el tiempo necesario hasta leerlo por completo (lo que ralentizará la carga), por lo cual, lo lógico sería ubicarlo al final del body, de forma que la carga no se vea interferida. Pero al estar hablando de interactividad, por lógica necesitaríamos que el sitio ofrezca una respuesta al ingreso de datos efectuado. Entonces, ubicándolos al final, estaríamos en la misma situación, puesto que al llegar a esa línea, la página ya se mostraría (aumentando la puntuación de la métrica anterior, por caso), pero la interactividad todavía estaría supeditada a que el navegador termine de leer el script, por lo cual, la carga sigue siendo lenta.
Es así que, lo conveniente para esta métrica, es simplemente tener un código sumamente limpio, evitando HTML y JS innecesarios. Respecto a este último caso, lo óptimo también es usar las instrucciones async y await, por un lado, y defer, por el otro.
LCP | Largest Contentful Paint
Largest Contentful Paint se encarga de medir el tiempo que transcurre desde que la página comienza a cargarse, hasta que el mayor elemento con contenido es renderizado. Al igual que FID, es una de las tres Web Core Vitals definidas por Google. Del mismo modo que en el apartado anterior, Page Speed Insights ofrece ciertas respuestas al momento de pensar en cómo optimizarla.
Encontramos que existen tres variables que podrían ser las causantes de un mal puntaje de esta métrica:
- Servidores web lentos (o mal configurados)
- CSS y/o Javascript asíncronos
- Recursos muy pesados
Como respuesta a ello, las opciones son muy claras. En primer lugar, encontramos como respuesta conveniente optimizar el servidor del sitio web analizado. Como segunda y tercera respuesta, salta a la vista la necesidad de optimizar el código fuente. Para ello, nuevamente es necesario recurrir a la optimización de imágenes y a la implementación de código asincrónico en el caso de Javascript.
CLS | Cumulative Layout Shift
Esta es la cuarta métrica incluída en el análisis de datos de campo de la plataforma. Es la tercera y última que encontramos conformando la triada de las Web Core Vitals definidas por Google. Su función es, básicamente, medir la estabilidad visual. Dicho de otra manera, mide la frecuencia con que aparecen elementos en el sitio que no pueden ser controlados por el usuario. Esto, como sabemos, perjudicará su experiencia.
Encontramos aquí que, en palabras de Google, el CLS puede verse perjudicado por cinco aspectos:
- Imágenes con dimensiones sin especificar
- Iframes o anuncios con dimensiones sin especificar
- Contenido añadido dinámicamente (por ejemplo, los chats)
- Fuentes web que provoquen flashes de texto invisible
- Acciones que esperen una respuesta de red antes de que se actualice el DOM
Con respecto a cómo mejorar esta métrica, diremos que CLS deja pasar por alto cualquier cambio que se produzca medio segundo después de cualquier input del usuario. Es así que la evaluación de la métrica se detendrá a los 500 milisegundos después de cada vez que el usuario interactúe con el sitio. Sabiendo esto, podrá solventar la mayor cantidad de problemas no relacionados con dimensiones no especificadas.
De esta manera es que funcionan las métricas aglomeradas en los datos de campo analizados por Page Speed Insights. Entendemos que pensar en mejorarlas puede sonar muy difícil al principio. Pero no es una tarea imposible, es todo cuestión de dar el primer paso.
