Categories
SEO

Cómo auditar los vitales web principales

En mayo de 2020, Google anunció que Los vitales web del núcleo se convertirían en parte de los algoritmos de Google en 2021 , pero dijo a los propietarios del sitio que “no hay necesidad inmediata de tomar medidas”. Para noviembre de 2020, Google reveló que esta actualización entraría en vigencia en mayo de 2021, por lo que para los propietarios de sitios y SEO en todo el mundo, el tiempo para tomar medidas en la actualización de la experiencia de la página con nombre es ahora.

¿Qué son los vitales web centrales?

Los vitales web de núcleo son un conjunto de métricas que se utilizan para medir la carga, interactividad y estabilidad visual de un sitio web. Los tres están relacionados con la velocidad del sitio de una forma u otra, que es algo que sabemos que ha sido importante para los motores de búsqueda y los usuarios durante mucho tiempo.

Lo que es realmente interesante acerca de los vitales web básicos y la experiencia de la páginaActualización de NCE En particular, es que Google no suele estar muy lejos con los detalles específicos de sus actualizaciones de algoritmos. Pero en este caso, hemos recibido las métricas exactas que necesitamos para medir y mejorar, y la fecha en que entrará en vigencia esta actualización. Esto indica que la experiencia de la página ciertamente será una actualización importante, pero también a la que podemos prepararnos, siempre que el proceso de auditoría sea detallado y preciso. Aquí están las métricas que deben analizarse en un núcleo de auditoría de vitalización web:

Google's core web vitals metrics
Las vitales web principales de Google. Fuente: Google.

La pintura contenta más grande (LCP)

mide el rendimiento de carga (es decir, cuánto tiempo tarda el artículo más grande de la ventana que se carga). Para proporcionar una buena experiencia de usuario, LCP debe ocurrir dentro de 2.5 segundos de cuandoLa página primero comienza la carga o un máximo de 4 segundos para evitar una puntuación “pobre” (aunque entre 2.5 y 4 segundos aún “necesita” mejora “).

Primer retardo de entrada (FID)

Medidas de interactividad (es decir, cuánto tiempo tarda el sitio web que responda cuando un usuario hace clic en algo). Para proporcionar una buena experiencia de usuario, las páginas deben tener un FID de menos de 100 milisegundos o un máximo de 300 milisegundos para evitar una puntuación “pobre” (aunque entre 100 y 300 milisegundos aún “se necesita mejoras”). Dentro del proceso de auditoría detallado en este artículo, se usa una métrica similar, “Tiempo de bloqueo total (TBT),” porque el primer retraso en la entrada requiere datos de campo, pero esta auditoría utiliza datos de laboratorio porque los datos de campo pueden no estar siempre disponibles para el sitio web. auditoría.

Cumulative Cambio de diseño (CLS)

Mide la estabilidad visual (es decir, si la página salta o no a medida que el usuario se desplaza a través del contenido). Para proporcionar una buena experiencia de usuario, las páginas deben mantener un CL de menos de 0,1 o un mínimo de 0,25 para evitar una puntuación “pobre” (aunque entre 0.1 y 0.25 aún “de mejora de las necesidades”).

Esta auditoría se enfoca En las métricas con un puntaje “pobre”, ya que estas serán las áreas principales de prioridad, pero también puede ajustarlo para incluir “mejora de las necesidades”. Entonces, ahora sabemos lo que estamos auditando, vamos a entrar en el proceso de auditoría en sí.

Relacionado: Guía para las vitales web de Core para SEOs y desarrolladores

CÓMO AUDITAR LOS VIVALES WEB DE AUDITORÍA UTILIZANDO FROG

  • Sabiendo lo que son las vitales web básicas, pero FindiNG Una forma de auditar y comunicar los problemas de vitales web básicos a los clientes de una manera que sea útil y accionable es un desafío que se enfrenta a los que se encuentran a través del mundo. El proceso de auditoría que he colocado está diseñado para proporcionar detalles reales, ejemplos y datos para trabajar cuando aborde los problemas de las vitales web principales.
  • Para iniciar la auditoría, necesitará tres cosas:
  • Una versión de pago del sitio web de la rana gritando.

  • Clave API de PagePeed Insights (que puede obtener de

esta página de documentación de Google PagePeed Insights

). El dominio del sitio web que está auditando.

    Paso 1: Conecte la tecla API de PagesPeed Insights a FROG

  • primero, deberá conectarte La tecla API de su PagePeed Insights para gritar Rana. Esta voluntadLe permite acceder a los datos y recomendaciones de PagePeed Insights en una página por página. Solo obtendrá un número limitado de consultas de PagesPeed Insights (alrededor de 25,000 por día), lo que debería ser suficiente para sitios más pequeños, pero para sitios más grandes, podrá aplicar los aprendizajes de las páginas que obtiene consultas para el resto de el sitio.

Con su clave de la API de PagePeed Insights en la mano, abra la rana gritando y navegue hasta la configuración> Acceso a API> PageSpeed ​​Insights.

The pagespeed insights secret key input screen within screaming frog. Pegue su clave API en el “Secret Caja de tecla “

Haga clic en” Conectar “

. Si los datos de campo están disponibles en los usuarios de la vida real, optó por los usuarios, aparecerá aquí.

The metrics tab within the pagespeed insights menu of screaming frog. Métricas del faro: la mayoría de los datos de laboratorio que utilizamos dentro de la auditoría vienen de aquí, incluidos los puntajes LCP, TBT y CLS .

OPORTUNIDADES: proporciona sugerencias para las mejoras de la velocidad de la página específicas de cada página.

Diagnóstico: proporciona información adicional sobre el rendimiento general del sitio web que se está arrastrando.

The crawl progress bar within screaming frog.

Paso 2: Crawl El sitio web

A continuación, deberá comenzar su rastreo. Copie el dominio del sitio web que está arrastrando y péguelo en la caja en la parte superior del rastreador que dice “Ingrese URL a Spider”. A medida que el sitio está arrastrado, notará que hay un “rastreo” y una barra de progreso “API” en la esquina superior derecha. Deberá esperar a que ambos alcancen el 100% antes de comenzar a analizar sus datos.

Exporting the crawl within screaming frog.

    Paso 3: Reporte el tamaño del problema

  • Antes de ingresar a los detalles específicos de lo que necesita fijación, el primer paso es comunicar la extensión del problema. Para hacer esto, debe observar qué porcentaje de páginas fallan cada vital general de umbrales mínimos.
  • En la barra de navegación superior, seleccione “Pagespeed” y luego “Guscort. “
  • Al observar sus datos exportados, encuentre las siguientes columnas y filtre en consecuencia:
  • Tiempo de pintura contento más grande (MS) – Filtro Para encontrar todas las páginas con LCP de 4000ms o más.

Tiempo de bloqueo total (MS): filtro para encontrar todas las páginas con TBT de 300 ms o más.

Mayúsculas de diseño acumulativo – Filtro para encontrar todo Páginas con CLS de 0.25 o más.

Agregue estos datos a una hoja de datos por separado para que usted o su cliente puedan ver fácilmente las páginas que fallan cada vital central. Luego, puede informar sobre un porcentaje de páginas en el sitio que fallan cada umbral mínimo de vitalización web. Aquí hay un ejemplo que envié a un cliente recientemente:

El 95% de las páginas tienen una pintura contenta más grande de más de 4 segundos (falla): consulte la pestaña “LCP> 4S” en el DA adjuntoTasheet.

El 58% de las páginas tienen un tiempo de bloqueo total de más de 300 milisegundos (falla): consulte la pestaña “TBT> 300ms” en la hoja de datos adjunta.

El 93% de las páginas tienen un acumulativo. Puntuación de cambio de diseño de más de 0.25 (falla): consulte la pestaña “CLS> 0.25” en la hoja de datos adjunta.

Exporting a list of pages that have render-blocking resources in screaming frog. Ahora está armado con una lista completa (o una lista de muestras, si el sitio también estaba Grande) de páginas que no cumplen con los umbrales mínimos de las vitales web principales, por lo que los desarrolladores saben exactamente dónde buscar páginas fallidas. Si nota algún patrón (por ejemplo, es solo páginas de blog, etc.), también puede informar esto ahora.

Paso 4: Informe los problemas específicos de cada página y haga las recomendaciones apropiadas An example of determining potential savings for each Core Web Vitals-related issue.

Esta es la parte de la auditoría donde convertimos problemas en soluciones. Sabemos que X cantidad de PAGES Están falsificando los umbrales mínimos de los vitales web básicos, pero ¿qué podemos hacer al respecto? Aquí es donde la API de Pagespeed Insights realmente funciona su magia. en el lado derecho, en la pestaña “Descripción general”, desplácese hacia abajo a “PageSpeed”. Aquí encontrará la lista de problemas / recomendaciones relacionadas con la velocidad de la página y en su mayor parte, los vitales web principales.

Hay una amplia variedad de temas diferentes informados aquí. Si hay alguno con ellas que no está familiarizado, busquelo en el sitio web

web.dev

para obtener más información. Si bien los datos disponibles dentro de la rana gritando y las ideas de PagePeed no pueden proporcionar una lista completamente exhaustiva de cada problema que puede afectar los vitales web de Core, sin duda ayuda al analizar el sitio de su cliente en su conjunto.

Haga clic en un asuntoPara ver las páginas afectadas, y expórtelas a guardarlas en su hoja de datos. Ahora está informando sobre los aspectos específicos de cuántas páginas se ven afectadas por un problema en particular y las URL de las páginas afectadas. En el siguiente ejemplo, he exportado una lista de todas las páginas que tienen recursos de bloqueo de renderizado que podrían afectar negativamente las LCP. Ahora puedo recomendar que el cliente analice esta lista y decida si enlate, aplazar o eliminar los recursos en estas páginas sería posible.

An example of how to view render-blocking resources in screaming frog.

Para cada una de las recomendaciones que eres HACIENDO, también podrá ver los “ahorros” que podrían hacerse fijando ese problema en particular, ya sea en bytes o milisegundos. Usando sus datos exportados para cada problema, ahora puede agregar los ahorros potenciales para cada problema, y ​​el AverAhorro de edad que se pueden hacer por página resolviendo ese problema, por lo que puede hacer sus recomendaciones para qué temas a abordar primero en función de la cantidad de potenciales ahorros de carga que se pueden hacer. En el siguiente ejemplo, los ahorros en milisegundos y bytes son mucho más grandes para diferir las imágenes de pantalla descoldar que la eliminación de CSS no utilizados, por lo que la diferencia de las imágenes de la pantalla, será una prioridad más alta.



Paso 5: Informe de ejemplos de los problemas específicos de cada página Al informar sobre los ejemplos de los problemas específicos de cada página, proporcionamos un conjunto de datos más granular que permite que los clientes / desarrolladores comprendan rápidamente Lo que es el problema y si es algo que se puede resolver o no. Siguiendo el ejemplo de los recursos de bloqueo de procesamiento, ahora noEed para seleccionar una de las URL afectadas por este problema, y ​​seleccione la pestaña “Detalles de PagePeed” en la barra de navegación inferior. El panel inferior izquierdo ahora mostrará la información de la velocidad de la página relevante para la página seleccionada. Navegue a las oportunidades> Eliminar los recursos de bloqueo de procesamiento. En el panel inferior derecho, ahora verá las URL de los recursos de bloqueo de renderizado en esa página, su tamaño (en bytes) y los ahorros de carga de la página potencial que se podría hacer (en milisegundos) si se eliminan estos recursos de bloqueo de render. Desafortunadamente, no puede exportar estos problemas específicos a granel (por lo que soy consciente ), pero puede copiar y pegar algunos ejemplos en su hoja de datos y nuevamente busque cualquier patrón. A menudo, los mismos recursos aparecerán en varias páginas / cada páginaEn el sitio, por lo que los aprendizamientos se pueden aplicar en todo el sitio. Una vez que haya juntado estos datos para cada problema en el sitio, puede proporcionar un informe escrito con recomendaciones para cada problema en orden de prioridad y consultar los datos En su hoja de datos. Paso 6: Una vez que se han realizado cambios, rastreando el sitio nuevamente y compártelo Cuanto más pronto complete esta auditoría, como algunos de los Los problemas tomarán tiempo para resolver. Una vez que se han abordado los problemas, puede volver al Paso uno y volver a colocar el sitio para ver cómo han cambiado las cosas. Aquí es donde sus porcentajes de páginas que no cumplan con los umbrales mínimos de los vitales web del núcleo serán tan útiles, ya que muestra una forma rápida y fácil de comprender si sus cambios han tenido el impacto deseado o no. cuando reportiNG En los vitales web centrales y la actualización de la experiencia de la página a los clientes, las preguntas que a menudo me preguntan son cómo esta actualización va a impactar en las clasificaciones. A pesar de que esto claramente es una actualización importante, no preveo los sitios web que no han conocido los umbrales mínimos al ver una gran caída en las clasificaciones durante la noche. Es más probable que sea un caso de sitios que tengan un excelente contenido que pueda cumplir o exceder los umbrales mínimos de los vitales web principales, al ver una ligera mejora en las clasificaciones, lo que, por supuesto, las caídas leves en rankings para los competidores que superan. Este sentimiento es compatible con las propias directrices de Google sobre el tema: “Mientras que todos los componentes de la experiencia de la página son importantes, priorizaremos las páginas con la mejor información en general, incluso siAlgunos aspectos de la experiencia de la página son subpar. Una buena experiencia de página no anula tener un contenido excelente y relevante. Sin embargo, en los casos en que hay varias páginas que tienen contenido similar, la experiencia de la página se vuelve mucho más importante para la visibilidad en la búsqueda “. Los propietarios de sitios que pueden cumplir con los umbrales mínimos se están poniendo en una Distinante ventaja En términos de visibilidad de búsqueda, y aunque no podemos predecir exactamente lo que sucederá en el día en que la actualización de la experiencia de la página va a vivir, este proceso de auditoría le ayudará a prepararse bien preparado. Las opiniones expresadas en este artículo son las del autor invitado y no necesariamente la tierra de los motores de búsqueda. Los autores del personal se enumeran aquí .

One reply on “Cómo auditar los vitales web principales”

[…] Este método le brinda una comprensión del tamaño de los temas para comunicar mejor el alcance a los clientes: ” El 95% de las páginas tienen una pintura contenta más grande de más de 4 segundos (falla) “. Crewe también demuestra cómo dar los números detrás de las correcciones para ayudar a los clientes a comprender cómo priorizar el CWV puede mejorar su sitio en general: “Para cada una de las recomendaciones que está haciendo, también podrá ver los ‘aho… […]

Leave a Reply

Your email address will not be published. Required fields are marked *