Tácticas de crecimiento de editores para la temporada electoral | SEMINARIO WEB
Tácticas de crecimiento de editores para la temporada electoral | SEMINARIO WEB
Al final de este módulo, debe tener una comprensión clara de los diversos componentes que contribuyen a la experiencia de la página, por qué son importantes y cómo se puede optimizar cada uno para mejorar tanto la experiencia del usuario de su sitio como su SEO.
Duración del vídeo
17:09
Responda la prueba
Tomar cuestionario del módulo actual
Materiales
Plantillas listas para usar
Recursos
Informes y recursos
2.3.1 ¿Qué es la experiencia de página?
La experiencia de la página es un conjunto de señales, que incluyen Core Web Vitals (CWV), compatibilidad con dispositivos móviles, HTTPS y pautas intersticiales intrusivas, que Google utiliza para extrapolar la experiencia del usuario en un sitio web.
La experiencia de la página es una evaluación del rendimiento de un sitio en lugar de su contenido. Si bien Google todavía prioriza la relevancia del contenido al responder las consultas de los usuarios, la experiencia de la página es un factor decisivo cuando varios sitios ofrecen un nivel similar de cobertura.
Las cuatro señales de experiencia de página son:
Los CWV miden la experiencia del usuario centrándose en la rapidez con la que se carga una página, su capacidad de respuesta a la entrada del usuario y también su estabilidad visual. Hay tres métricas para esto:
La actualización de Google en abril de 2015 introdujo la métrica amigable para el móvil del gigante de búsqueda, que aumenta la clasificación de páginas para dispositivos móviles en SERP móviles.
Efectivamente, Google priorizará aquellos sitios que aseguran que su contenido sea fácilmente legible en dispositivos móviles, lo que significa que no hay necesidad de hacer zoom, los objetivos táctiles como los botones de inicio de sesión no están espaciados demasiado cerca el uno del otro, no se evita desplazamiento horizontal y contenido no jugable.
La actualización se aplica a páginas individuales, no sitios web completos, y tampoco afecta el contenido que se ve en los navegadores de escritorio/portátiles.
HTTPS, o Protocolo de transferencia de hipertexto seguro, es una versión segura del Protocolo de comunicación de Internet HTTP.
HTTPS, o HTTP, forma la primera parte de cada URL que se conoce como el "esquema". Esto viene antes del nombre de dominio, que es el segmento de la URL conocido como la "autoridad".
La diferencia entre HTTPS y HTTP es que el primero es seguro mientras que el segundo no lo es. Lo que esto significa en la práctica es que los usuarios que inician sesión en un sitio a través de una conexión HTTP envían sus datos personales en texto sin cifras sin cifrar.
HTTPS asegura esa conexión, lo que significa que cualquier dato enviado entre el navegador del usuario y el servidor del sitio web está encriptado en el camino. Los sitios que desean conexiones seguras necesitan un certificado SSL, que el navegador del usuario verifica y verifica.
Los intersticiales son un formato de anuncio móvil solo que solo aparece en las rupturas naturales en el contenido, como cuando un usuario se mueve de un artículo a otro, que cubre la pantalla en el proceso.
Los intersticiales se consideran intrusivos cuando bloquean o oscurecen parcialmente la vista de los usuarios del contenido. Los cuadros de diálogo en sitios web móviles que se comportan de manera similar también se encuentran en esta categoría.
La mayoría de los conjuntos de habilidades más fuertes de los editores tienden a ser la creación de contenido, la publicación y el marketing, dejando poco espacio para comprender y optimizar los diversos pilares de experiencia de la página.
Los recursos finitos significan que los editores tendrán dificultades para justificar el tiempo y el dinero necesarios para profundizar en el backend de las páginas web individuales, y mucho menos un sitio web completo.
Incluso si los editores pueden dedicar tiempo a abordar el problema, como podemos ver desde arriba, la experiencia de la página es un problema multifacético que requiere un enfoque holístico para ofrecer ganancias de rendimiento significativas.
Saber cuál de las señales de experiencia de cuatro páginas para comenzar a trabajar puede ser un dolor de cabeza en sí mismo.
La experiencia de la página es increíblemente importante para el editor SEO, ya que el contenido excelente no es suficiente para garantizar la mejor ubicación dentro de los SERP.
Google todavía valora la mejor información antes de cualquier otra cosa, lo que significa contenido o noticias únicas "Scoops" funcionará bien incluso si la experiencia de la página es "deficiente" . Sin embargo, en los casos en que varios editores proporcionan una excelente cobertura tópica, la experiencia de la página se convierte en un factor decisivo importante que influye en la clasificación SERP.
Cada uno de los pilares de experiencia de cuatro páginas tiene un impacto diferente en el SEO de un sitio web. El impacto más inmediato proviene de centrarse en los CWV, que se traducirá en un sitio web que se carga más rápido.
Numerosos estudios han demostrado que cuanto más tiempo sea un sitio web para cargarse, más rápido la audiencia pierde interés y más alta será la tasa de rebote.
Por ejemplo, un estudio de Google de 2018 encontró que la probabilidad de rebote aumentó un 32% cuando los tiempos de carga de la página subieron de 1 segundo a 3 segundos.
Otro estudio de Google de 2020 encontró que los sitios de noticias que aprobaron la prueba CWV vieron una tasa de abandono un 22% más baja que los que fallaron. Yahoo! Mientras tanto, Japón mejoró su puntaje CLS en 0.2 y vio un aumento del 15.1% en las vistas de la página por sesión y un aumento del 13.3% en la duración de la sesión.
Si bien Google ha dicho explícitamente que no utiliza las tasas de rebote como señal de clasificación , una alta tasa de rebote habla con los factores que le importa a Google, a saber, la velocidad de carga de una página, la capacidad de respuesta y la estabilidad visual.
Los editores dirigidos al público en dispositivos móviles deben garantizar que su sitio envíe señales amigables con los dispositivos móviles que Google y Bing pueden captar. Ambos motores de búsqueda priorizarán sitios web amigables al entregar resultados de búsqueda a los usuarios móviles.
En comparación con los CWV y la amistad móvil, la implementación de HTTPS tendrá un impacto mucho menor en el SEO de un editor. Google dijo en 2014 que lo usaría como una señal de clasificación y comenzó a marcar todos los sitios HTTP como "no seguros" en Chrome en 2018. Sin embargo, el mayor beneficio aquí es la seguridad de los datos mejorada, especialmente si su módulo comercial se basa en los ingresos por suscripción.
Mientras tanto, pueden limitar los anuncios intersticiales o los cuadros de diálogo, pueden limitar la capacidad de los rastreadores web para rastrear e indexar una página, evitando que los motores de búsqueda incluso puedan clasificarlo, dejar solo con un alto contenido de búsqueda en los resultados de búsqueda.
El primer paso para mejorar la experiencia de la página comienza con la evaluación de la efectividad actual de su sitio web.
Hay una amplia gama de herramientas de primer y tercero para lograr esto, pero, para esta guía, veremos las herramientas de la primera parte de Google.
Ahora sabemos que los CWV son un factor de clasificación importante. Pero, ¿cómo se miden? La siguiente tabla enumera los parámetros dentro de los cuales los números de CWV óptimos deberían caer para la experiencia de la mejor página.
Ahora que sabemos lo que necesitamos medir y por cuánto, podemos ver cómo medir la experiencia de la página.
A continuación se muestra una lista de algunos de los métodos más utilizados.
La primera opción abierta para los editores es, con mucho, la más desafiante técnicamente y no es una que recomendemos incluso considerar a menos que tenga un buen desarrollador para ayudarlo con su implementación.
Estamos hablando de recopilar datos de usuarios de su sitio, un proceso conocido como monitoreo de usuario real (RUM) y luego analizar los resultados dentro de Google Analytics 4 (GA4). Google tiene otras herramientas, como PageSpeed Insights (PSI), que utilizan el muestreo de datos para evaluar su sitio. Pero si el objetivo es tener una imagen completa de experiencia del usuario para su sitio web, entonces necesita datos del mundo real recopilados de su sitio.
Aconsejamos usar GA4 para esta tarea por la simple razón de que Google tiene la intención de comenzar "el sol" a la generación anterior de Google Analytics, Universal Analytics (UA), desde mediados de 2023.
Como editor, ya debería haber configurado una cuenta GA4 en previsión del cambio. Si no lo ha hecho, siga las guías de Google sobre cómo configurarlo por primera vez o cómo agregarlo a un sitio que ya tiene UA .
Una vez hecho, el siguiente paso es vincular el almacén de datos BigQuery de Google a GA4 desde Analytics Admin. Vinculación de BigQuery le permitirá consultar sus datos utilizando SQL. Aquí hay una guía sobre cómo vincular los dos .
Con esos pasos fuera del camino, ahora podemos agregar la biblioteca de Vitales web a su sitio.
La biblioteca, que es una biblioteca de JavaScript modular extremadamente pequeña para la recopilación de datos, está disponible en GitHub.
La biblioteca se puede instalar desde el repositorio en línea de NPM de código abierto ejecutando "NPM Install Web-Vitals" en su terminal de comando o a través de<script> tags on a content distribution network (CDN).
Aquí hay un ejemplo de tal guión:
Una vez que se ha instalado la Biblioteca Web-Vitals, los datos del usuario se pueden enviar a Google Tag Manager (GTM), utilizando una etiqueta de plantilla personalizada recomendada por Google que Simo Ahava creó y mantiene.
Una vez que se ha instalado la etiqueta, las métricas de CWV y los datos de atribución asociados pueden reenviarla a GA4.
Una vez que haya configurado Analytics para rastrear los datos de GTM, podrá ver los datos de eventos en la interfaz BigQuery. Estos datos se pueden consultar así:
Una vez que se devuelve la consulta, el informe debe verse algo así:
Realmente tenemos que enfatizar nuevamente que esta es una solución de desarrollador y, de hecho, es mucho más complejo que esto. Sin embargo, adoptar esta solución le dará la lectura más precisa en el rendimiento de su sitio web.
Para obtener una explicación más detallada de este proceso, consulte la guía de Google para ver los CWV en GA4 .
Si bien este es el enfoque más preciso para monitorear los CWV, existen enfoques más simples para abordar este problema.
El PSI es menos preciso que el uso de un enfoque GA/RUM, sin embargo, con frecuencia se cita como una de las herramientas más importantes para medir los CWV, gracias a la facilidad de uso de la herramienta.
Si bien solo puede usar muestras de experiencias reales de usuario tomadas del Informe de experiencia de usuario de Chrome (Crux) durante el período anterior de 28 días, PSI proporciona una interfaz de usuario simple y fácil de entender . Esto significa que interpretar los datos es un proceso mucho más simple.
Como puede ver en nuestro ejemplo a continuación, examinar el sitio de Forbes inmediatamente proporciona una gran cantidad de información en el escritorio del editor y el sitio web móvil.
PSI usa las categorías verdes, ámbar y rojo de arriba al asignar bien, necesita mejoras y malas calificaciones de rendimiento.
El enfoque de muestreo de Crux significa que, si bien la evaluación anterior de Forbes asumió algunas experiencias de usuario del mundo del mundo real, no puede tener en cuenta todos los datos del usuario del sitio.
Este enfoque de muestreo se vuelve problemático para sitios más pequeños, muchos de los cuales no se presentarán en los datos de campo de Crux.
Sin embargo, PSI aún puede ofrecer un diagnóstico virtual de su sitio web utilizando datos de laboratorio extraídos de la herramienta de faro de código abierto . Vea el siguiente ejemplo:
El problema con este enfoque es que Lighthouse recopila sus datos utilizando la configuración de dispositivos y redes predeterminados, lo que no reflejará la configuración de sus usuarios. Esto significa que es un sustituto deficiente de lo real.
GSC es una herramienta diseñada para proporcionar a los editores una vista de ojo de aves de los problemas de CWV de su sitio web, abriendo la puerta a un enfoque holístico para mejorar el rendimiento del sitio.
Lo hace al agrupar sus informes de rendimiento de URL basados en el estado, el tipo métrico o la similitud tópica. No identifica problemas con las páginas individuales, negando la oportunidad de implementar soluciones a nivel granular.
Aquí es donde entra PSI. Sin embargo, vale la pena señalar que el informe de página individual de PSI puede diferir notablemente de los resultados del grupo del GSC. Esto se debe a que la página individual es solo un componente de los resultados del grupo agregado de GSC.
Al iniciar sesión en el tablero de GSC, los usuarios verán la pestaña Core Web Vitals en el lado izquierdo. Al hacer clic en esta pestaña, muestra informes de CWV móviles y de escritorio separados para grupos de URL.
A pesar de que hay tres métricas de CWV (LCP, FID y CLS, las URL recibirán una calificación general basada en su métrica de peor desempeño para un dispositivo específico que también afectará los informes grupales.
Por ejemplo, si una URL en dispositivos móviles recibe un FID pobre y un buen LCP, se etiquetará como pobre en el móvil.
Nuevamente, es importante tener en cuenta que GSC no está destinado a soluciones granulares. Sin embargo, es ideal para los editores que tienen muchas páginas similares. Por ejemplo, los sitios de noticias pueden tener un diseño y diseño relativamente estándar para sus páginas de artículos que utiliza una imagen como el elemento más grande sobre el pliegue. En este caso, GSC puede ayudar rápidamente a identificar problemas de LCP en una gama de URL.
La herramienta final en el kit de herramientas de medición de rendimiento de Google es Lighthouse . Esta herramienta es completamente diferente de las que vinieron antes, ya que emula el rendimiento del usuario en función de un conjunto establecido de parámetros.
No utiliza datos de campo y, por lo tanto, es más limitado en términos de usos prácticos. Por ejemplo, los datos de campo están influenciados por la conexión de red de un usuario y su distancia a los servidores del sitio, mientras que Lighthouse emula un dispositivo de rango medio para recopilar datos dentro de un entorno controlado.
También es importante entender que el puntaje de Lighthouse no es solo una amalgama de las puntuaciones de CWV. Excluye FID, ya que los datos de laboratorio por su naturaleza excluyen las interacciones del usuario final, al tiempo que agrega tiempo de bloqueo total (TBT), índice de velocidad (SI) y tiempo para interactivas (TTI) en la mezcla. Para aquellos que desean simular una experiencia FID en el laboratorio, TBT puede usarse como un proxy.
Sin embargo, recomendamos que no use Lighthouse como un recurso de medición primario. Más bien, debe usarse como una herramienta complementaria junto con PSI para ayudar a solucionar problemas de página específicos.
Los editores que desean usar el faro en sus pruebas pueden hacerlo a través de Chrome Devtools que se hornean directamente al navegador Chrome, una extensión para dicho navegador o en Web.dev/MeASure .
Lighthouse auditará su página web y proporcionará puntajes de 100 en cuatro áreas:
Así es como se ve cuando ponemos nuestra página de inicio a través de la opción Web.dev.
El diseño web móvil difiere del diseño web de escritorio tradicional en que los dispositivos móviles tienen pantallas más pequeñas, generalmente lucen hardware menos potente y depende únicamente de las entradas táctiles.
Los sitios amigables con los móviles priorizan la experiencia del usuario siguiendo un conjunto de mejores prácticas que exploraremos un poco más tarde. Por ahora, la mejor manera de verificar si sus páginas son amigables con los dispositivos móviles es con la prueba amigable para móviles .
Ingresar una URL de una página web amigable para dispositivos móviles devuelve el siguiente resultado:
Páginas que falla esta prueba aparecerán con una serie de opciones de reparación para seguir. Los entraremos un poco más tarde.
Verificar si su sitio web tiene una conexión segura es un proceso extremadamente simple, que implica abrir su navegador y mirar el símbolo a la izquierda de la URL en la barra de direcciones.
En Chrome, se denotará una conexión segura a través de un símbolo de candado cerrado como este:
Una conexión no segura tendrá un símbolo de información como así:
Determinar si sus anuncios intersticiales son intrusivos o no es tan simple como ingresar a su sitio web en una herramienta en línea y esperar a que devuelva una marca o no.
Requiere estudiar los anuncios intersticiales y los cuadros de diálogos en su sitio y decidir si pasan ciertos parámetros.
Piense en estos parámetros como preguntas, por ejemplo:
Si responde que sí a cualquiera de estas preguntas, probablemente sea un indicador de que el cuadro de diálogo o AD o es intrusivo.
Ahora que tenemos un comprensión firme sobre los diferentes componentes de los cuatro componentes que cuentan para la experiencia de la página, así como los medios para monitorear su rendimiento, pasemos a explorar cómo exactamente podemos aumentar las señales de clasificación de nuestros sitios
Primero veremos CWVS, ya que la depuración y optimización de LCP, CLS y FID tendrán el mayor impacto en su capacidad para competir por los mejores puntos en clasificaciones SERP muy disputadas.
Si bien la amabilidad móvil es increíblemente importante para los sitios dirigidos a usuarios móviles, mejorar los CWV aumentará el rendimiento de la página para los sitios, independientemente de si se ven en dispositivos móviles o escritorio.
Abordar los HTTP y los intersticiales intrusivos se han dejado hasta el final, ya que son victorias más fáciles y menos gratificantes.
Hay una serie de opciones cuando se trata de mejorar el rendimiento de CWV, que hemos desglosado en orden de la importancia que creemos que merecen.
Optimizar los vitales de la web central de cualquier página es un espectro de acciones y es importante saber dónde comenzar a maximizar sus recursos.
Como ya hemos señalado anteriormente, la pintura contentful más grande (LCP) mide cuánto tiempo lleva cargar completamente el texto o activo de imagen más grande visible sobre el pliegue.
Use PSI para identificar qué contenido de página desencadena la prueba LCP, dirigiéndose a la sección de diagnóstico del informe y haciendo clic en "Elemento de pintura contento más grande". Esto es lo que vimos en la página de inicio de SODP:
Una puntuación LCP pobre generalmente se puede reducir a tiempos de respuesta del servidor lentos, bloquear JavaScript y CSS, tiempos de carga de recursos o representación del lado del cliente, o incluso una combinación de los cuatro.
La optimización de su página realmente implica optimizar cuatro subpartes diferentes del proceso de carga LCP:
Todos estos pasos deben estar optimizados para que vea una mejora en su puntaje LCP. Sin embargo, no significa que todas las subpartes sean igualmente importantes.
Google ha sugerido que el tiempo total de LCP debe desglosarse con TTFB y el tiempo de carga de recursos, cada uno de los cuales representa alrededor del 40%, mientras que los retrasos de carga de recursos y elementos deben tener en cuenta menos del 10%.
Idealmente, estos dos últimos deben ser lo más cerca posible de cero y tener prioridad sobre las otras dos fases.
Hay dos formas de ayudar a reducir el retraso de carga de recursos lo más cerca posible de cero:
Diremos esto de inmediato, recomendamos consultar con su desarrollador web antes de sumergirse en estas soluciones. Esta es una operación de backend y requiere una mano experimentada para que funcione según lo desee.
Descubrimiento de recursos
Cada navegador web viene con un escáner de precarga, cuyo trabajo es para ayudar al analizador HTML principal del navegador a detectar el contenido de la página.
Mientras que el analizador HTML primario procesa el marcado bruto hasta que se ejecuta en un recurso de bloqueo, como un script que no contiene un asíncrono o diferir , el escáner precargado ocupa un papel más especulativo.
En otras palabras, el escáner de precarga está buscando recursos para obtener antes de que el analizador HTML primario los alcance y continúe funcionando incluso si el analizador está bloqueado. El escáner de precarga se puede usar para encontrar y cargar el LCP lo más cerca posible de la solicitud de página inicial.
Para garantizar que el recurso LCP se pueda descubrir desde la fuente HTML, los desarrolladores tienen opciones específicas de activos.
Por ejemplo, si el LCP es una imagen, entonces sus SRC o SRCSET deben estar presentes en el código fuente. Mientras tanto, las imágenes de fondo de CSS se pueden precargar al incluir en HTML Markup o en el encabezado. Finalmente, las fuentes se pueden cargar de manera similar a través de .
Sin embargo, vale la pena señalar que el uso de la precarga para reducir los tiempos de carga LCP puede introducir nuevos problemas en la mezcla, como la depioridad de de asíncrono . Hay una razón por la que abogamos por hablar con su desarrollador sobre esto.
Para obtener más información sobre este tema, consulte las inmersiones profundas de Google en la optimización de LCP y el escáner de precarga .
Prioridad de recursos
Los navegadores intentan descargar los activos CSS, Font, Script, Image e Iframe de la manera más óptima posible asignando prioridad. Los navegadores son excelentes para descubrir prioridades de activos, pero eso no significa que sean perfectos.
Para optimizar la priorización de activos, los desarrolladores pueden usar sugerencias de prioridad basadas en el marcado para indicar a los navegadores qué activos tienen una mayor prioridad. Por ejemplo, un desarrollador puede usar JavaScript y la API de Fetch para etiquetar la imagen LCP con el FetchPriority = "High" , acelerando esa métrica CWV particular.
Vale la pena señalar que las sugerencias de prioridad solo funcionan en navegadores basados en cromo , como Google Chrome y Microsoft Edge.
Es posible que su desarrollador ya haya implementado la carga perezosa para debajo de los activos de pliegue, consulte con ellos para asegurarse, pero también vale la pena que usen sugerencias prioritarias para los activos por encima del pliegue.
Para obtener más información sobre la carga de prioridad, recomendamos verificar la guía de Google para la carga de recursos .
El equipo de desarrollo del gigante de la búsqueda pudo usar pistas prioritarias para mejorar LCP de 2.6 segundos a 1.9 segundos en una prueba de vuelos de Google.
FID rastrea cuánto tiempo lleva el navegador de un usuario para comenzar a procesar la primera entrada, excluyendo el desplazamiento y el zoom.
Esta medida se trata de capturar la experiencia del usuario de interactuar con una página web, lo que significa que las páginas web lentas anotarán mal. Mantener ese puntaje FID por debajo de 100 milisegundos es el objetivo.
La mala capacidad de respuesta generalmente se reduce a un uso excesivo de JavaScript, que los navegadores procesarán antes de las entradas.
El código que consume el enfoque de un navegador durante 50 milisegundos o más se denomina una tarea larga y se ve como un signo de hinchazón de JavaScript. Romper estas tareas largas en trozos de código más pequeños puede abordar el rendimiento lento y mejorar el FID.
Pero esa no es la única área que vale la pena discutir con su desarrollador. Es importante discutir cómo la ejecución de script de terceros y de terceros puede desacelerar su sitio. La carga progresiva del código y las características puede ayudar a abordar los desafíos de los primeros, mientras que la carga a pedido y la priorización de carga pueden ayudar con el segundo.
Otra opción sería usar los trabajadores web para ejecutar JavaScript en segundo plano y evitar que su navegador reciba scripts de procesamiento.
CLS es básicamente una medición de la estabilidad visual de su sitio web. Si sus visitantes pierden su lugar en una página gracias al contenido de que se mueva para dar paso a que los anuncios y las imágenes se carguen, entonces su sitio va a anotar mal.
Cuanto menos se vuelva el diseño de su página, mejor será su puntaje CLS. Google juzga los sitios web al considerar la interrupción dentro de la ventana gráfica, así como hasta qué tan lejos saltaron los activos en relación con ella.
Minimizar los cambios de diseño inesperados básicamente gira en torno a designar espacio para anuncios, imágenes y videos integrados.
¿Recuerdas los SRC o SRCSet que vimos cuando hablamos de descubrimiento de recursos? Bueno, esto es bastante fundamental para mejorar las puntuaciones de CLS.
Para imágenes estáticas, establezca el ancho y la altura utilizando los SRC para decirle al navegador que reserve espacio para los activos de carga más lentos, evitando así los cambios de diseño.
Vea el código de ejemplo de Google a continuación:
Las imágenes receptivas requieren un srcset para definir el ancho máximo y los límites de altura que el navegador puede seleccionar. Asegúrese de usar imágenes con la misma relación de aspecto.
Aquí hay otro ejemplo:
Al tratar con anuncios, hay algunos pasos que puede tomar:
También se recomienda reservar espacio estático si tiene la intención de implementar iFrames, contenido integrado y contenido dinámico, como llamadas a la acción (CTA).
Cuando los navegadores descargan y representan fuentes web, existe la posibilidad de que ocurra un destello de texto no establecido (Fout) o un destello de texto invisible (FOIT). La primera ocurre cuando una fuente respaldo se intercambia con una nueva fuente, mientras que la segunda es el resultado de un retraso en una nueva fuente que se representa.
Puedes resolver ambos problemas usando Para decirle al escáner de precarga que tome las fuentes web antes. Las fuentes precargadas tienen una mayor probabilidad de cumplir con la primera pintura.
Hay otras soluciones en la Guía de solución de problemas de CLS , así como su profunda inmersión en el uso de precarga para prevenir FOIT .
Si está buscando mejoras de velocidad del sitio y todavía está utilizando una opción de alojamiento tradicional de servidor único, entonces probablemente sea hora de considerar cambiar a una red de entrega de contenido (CDN).
Un CDN consiste en una red de servidores ubicados en diferentes centros de datos en todo el mundo que distribuyen el contenido del sitio web para mejorar el rendimiento. Si bien tanto una opción de servidor único, también conocida como alojamiento local, y CDN ofrecen contenido del sitio web a los visitantes, solo un CDN puede tener en cuenta la ubicación geográfica del usuario y luego elegir el servidor más cercano para reducir los tiempos de carga.
Sin embargo, la geografía no es la única ventaja, ya que los CDN también están mejor equipados para administrar picos de tráfico repentinos, así como los recursos del servidor raíz, como el ancho de banda.
En última instancia, una experiencia de navegación más rápida envía una fuerte señal de CWV a Google. Si bien Cloudflare es uno de los proveedores de CDN más conocidos del mercado, hay una serie de competidores serios a considerar .
Independientemente del proveedor de alojamiento que use, sus servidores estarán sujetos a ciertas limitaciones de hardware.
Los servidores contienen en gran medida los mismos componentes clave que permiten que su computadora portátil/escritorio funcione, a saber, una CPU y RAM, que manejan todas las tareas de su cuenta. Debería poder utilizar el tablero de su proveedor de alojamiento para verificar la CPU y la RAM instalada en su servidor e incluso poder solicitar recursos adicionales para aumentar el rendimiento de su sitio.
Si está mirando la CPU de su servidor, entonces es importante comprender que solo se utiliza un solo núcleo para cumplir con la solicitud de un visitante de una página web. Esto significa que las velocidades de reloj de un solo núcleo más rápidas son siempre un. Las CPU de múltiples núcleos pueden procesar múltiples vistas de página y otros servicios de servidor.
Este es otro para su desarrollador.
Revise su base de datos sobre una base semi-frecuente para asegurarse de que no se haya inflado con fotos y archivos no utilizados. Eliminar archivos innecesarios lo desanimará, acelerando los tiempos de carga de la página promedio.
El uso de imágenes realmente grandes puede y reducirá su sitio web. ¿Qué tan grande? Cualquier cosa de más de 1 MB es simplemente demasiado grande.
Y como ya sabemos, los tiempos de carga más lentos conducirán a tasas de rebote más altas y enviarán señales no deseadas a Google.
Para aquellos en WordPress, hay una serie de complementos de optimización de imágenes para elegir que pueden optimizar una tarea manual tediosa. Además, muchos también vienen con otras características, como la carga perezosa y la reducción automática.
Si un sitio es amigable con el teléfono móvil o no gira en torno a si ha simplificado y simplificado su sitio para la experiencia de navegación móvil.
Los usuarios móviles interactúan con las páginas de manera diferente y tienen mucha menos paciencia para los tiempos de carga lentos y los sitios difíciles de navegar. Si su sitio ha fallado en la prueba amigable para dispositivos móviles descrita anteriormente, o incluso si se pasa pero está interesado en una mayor optimización, pasemos sobre algunas de las mejores prácticas.
Esta debería ser la principal preocupación de todos los editores. Una forma simple de abordar la facilidad de uso es hacerse preguntas como:
Estas respuestas contribuirán en gran medida a identificar los puntos de dolor del usuario. Por ejemplo, no desea que sus usuarios ajusten sus pantallas para ver su contenido. Puede ver lo que queremos decir en el siguiente ejemplo.
Para optimizar su contenido para dispositivos móviles, hay tres opciones de desarrollo:
Los hemos ordenado en términos de facilidad de implementación y recomendamos adoptar un diseño receptivo, ya que es la menos exigente de las tres opciones.
Los desarrolladores simplemente agregan la Meta Name = "Viewport" al código existente de una página web
La ventaja aquí es que solo tiene que mantener un sitio web, que se puede mostrar fácilmente en cualquier tipo de pantalla.
Por el contrario, los diseños dinámicos funcionan al servir un código HTML diferente basado en el dispositivo del usuario. Las páginas deben usar el encabezado Vary HTTP para evitar que el código incorrecto se entregue al dispositivo incorrecto.
Finalmente, hay subdominios móviles, que no recomendamos dada la cantidad de recursos necesarios para implementar de manera efectiva. Los subdominios móviles son sitios completamente separados que separan las necesidades de alojamiento. Para garantizar que los rastreadores comprendan la relación entre el dominio y el subdominio, deberá incluir la etiqueta rel = "canónica"
Porque los diseños receptivos es la opción más simple, es la que recomendamos para los editores. Para ver más de cerca el diseño receptivo, consulte la Guía de implementación de Google .
Aquí hay una lista rápida de consideraciones técnicas para cualquier diseño:
Este último paso es la forma más simple de mejorar la experiencia de la página, pero también contribuye en gran medida a mejorar la tranquilidad de su usuario.
Cambiar a HTTPS protege y cifra la información de sus usuarios, también ayuda a evitar ataques al hombre en el medio (MITM). Además de esto, tener un certificado SSL elimina las advertencias del navegador sobre la falta de seguridad.
Su proveedor de alojamiento realmente debería poder proporcionarle seguridad HTTPS, si no es así, podría valer la pena considerar un movimiento a uno que lo haga. Ya hay varios proveedores de alojamiento notables que proporcionan HTTPS de forma gratuita . Además, aquellos proveedores de alojamiento que proporcionan certificados SSL usan su propio servicio en lugar del externo, lo que hace que el proceso sea aún más fácil y rápido de implementar.
Si desea solicitar e instalar un certificado SSL de las autoridades de certificado (CAS), hay cuatro pasos que debe seguir. Estos son:
Es importante asegurarse de que al migrar su sitio a HTTPS no afecte su estrategia de ingresos publicitarios. El problema es que un HTTPNo funcionará en un sitio usando HTTPS.
Aconsejamos consultar con sus socios de tecnología publicitaria antes de realizar cualquier cambio en su sitio.
Para obtener más detalles, consulte la guía integral de Google sobre el tema.
Los intrusivos anuncios intersticiales y cuadros de diálogo dificultan que los motores de búsqueda comprendan el contenido de una página web, que puede socavar el rendimiento de SERP.
Sería genial si hubiera una forma de crear intersticiales que no interrumpieran la experiencia del usuario, pero ese es el objetivo de tales anuncios. Se hacen cargo de toda la pantalla en Breaks in Content para obtener la atención del usuario.
Como tal, los editores estarían mejor utilizando anuncios de banner en lugar de anuncios intersticiales, ya que solo ocupan una pequeña porción de bienes inmuebles de pantalla. Mejor arrancar la ceguera de la pancarta que la frustración del usuario.
Los editores pueden usar pancartas respaldadas por el navegador o pancartas HTML simples que se vinculan a la página de destino de la CTA.
Los cuadros de diálogo también se pueden usar para campañas promocionales, pero estos pueden diseñarse para no ser INTRISIVOS. Debe asegurarse de que los usuarios puedan acceder al contenido sin interrupción.
No hay atajos reales para optimizar la experiencia de su página y es vital que arregle los puntos anteriores. Dicho esto, vale la pena señalar que, si bien WordPress es fácilmente la plataforma de publicación más popular del mundo, esto no significa necesariamente que sea el mejor CMS cuando se trata de aumentar el rendimiento de CWV.
Mirar el informe de la tecnología CWVS muestra que solo alrededor del 29% de los sitios web de WordPress tienen buenos CWV, mientras que el 41% de los sitios WIX obtienen la garrapata verde.
Vale la pena sopesar si cambiar a un CMS especializado podría mejorar sus CWV de forma nativa.
Hay mucho terreno que cubrir cuando se trata de optimizar la experiencia de la página y comenzar puede ser un poco desalentador. Sin embargo, es importante recordar que comes el elefante dando un bocado a la vez.
No es necesario apuntar a una "buena" puntuación en todas sus métricas de CWV para ayudar a su sitio a subir los SERP. Sin embargo, más que eso, establecer tales objetivos tan elevados puede ser contraproducente, ya que puede ser una búsqueda desmoralizadora.
Más bien, apunte a pequeñas victorias cuando se trata de sus CWV, concéntrese en abordar los resultados "pobres" sin preocuparse demasiado por la barra de "necesidades de mejora". Eso puede venir más tarde, cuando tiene más tiempo y recursos para dedicar al proceso.
Ya hemos hablado de Yahoo! El puntaje CLS mejorado de Japón, veamos otro par de sitios de los que podemos aprender algunas lecciones.
Indian Daily The Economic Times, que atiende a más de 45 millones de usuarios activos mensuales, redujo su puntaje CLS en un 250% de 0.25 a 0.09 y su tiempo LCP 80% de 4.5 segundos a 2.5 segundos.
Entre octubre de 2020 y julio de 2021, el editor recortó los puntajes LCP en el rango "pobre" en un 33%, mientras que los valores de CLS en el rango "pobre" cayeron en un 65%. Estas ganancias permitieron que los tiempos económicos aprobaran los umbrales de CWV en todo su origen al tiempo que reducen las tasas generales de rebote en un 43%.
El editor logró esto de varias maneras, con el primero de ellos para priorizar las prioridades de descarga de activos utilizando sugerencias prioritarias. También abordó tareas largas, rompiendo fragmentos de código para garantizar que los recursos que sean críticos para la representación de la página de pliegue se cargaran primero primero.
El sitio web de noticias del Reino Unido mejoró su puntaje CLS de 0.25 a 0.1 , al tiempo que aumentó el número de URL que recibieron una calificación aprobatoria del 57% al 72%.
El Telegraph usó crome DevTools para identificar instancias individuales de diseño de desplazamiento.
Antes de usar WebPageTest para encontrar en dónde se produjo en la línea de tiempo el cambio de diseño.
Con estos datos en mano, el equipo comenzó a centrarse en reducir los cambios de diseño abordando estas áreas
Para los anuncios, el telegrafiado comenzó a reservar espacio para ellos y usó el tamaño de anuncio más común para especificar dimensiones. Esto también ayudó a evitar que los anuncios colapsen cuando se vean en una tableta.
El equipo abordó un problema similar con las imágenes en línea en la parte superior de los artículos, que no tenían dimensiones especificadas.
El telégrafo hizo otros ajustes, como mover el encabezado a la parte superior del marcado y usar marcadores de posición para videos integrados, pero finalmente describió el proceso como "bastante fácil" sin dejar de tener un impacto significativo.
Mejorar la experiencia de la página no necesita ser abrumadora. Mida los cuatro pilares de la experiencia de la página y luego decida qué recursos puede dedicar a mejorar sus resultados.
Si es un editor más pequeño, el equilibrio de recursos será crucial y recomendamos identificar frutas colgantes razonablemente bajas para su primer proyecto.
Al observar el enfoque del telégrafo, se centraron en un aspecto de los CWV en lugar de los tres e hicieron mejoras significativas. Los tiempos económicos se centraron en dos de los tres para ofrecer algunos resultados impresionantes.
Activo ahora
Ver más
