Tácticas de crecimiento editorial para la temporada electoral | WEBINAR
Tácticas de crecimiento editorial para la temporada electoral | WEBINAR
Al final de este módulo, debería tener una comprensión clara de los distintos 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
Responder cuestionario
Realizar la prueba 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 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 página evalúa el rendimiento de un sitio, no su contenido. Si bien Google aún prioriza la relevancia del contenido al responder las consultas de los usuarios, la experiencia de página es un factor decisivo cuando varios sitios ofrecen un nivel de cobertura similar.
Las cuatro señales de experiencia de la página son:
Las CWV miden la experiencia del usuario centrándose en la velocidad de carga de una página, su capacidad de respuesta a la entrada del usuario y su estabilidad visual. Existen tres métricas para esto:
La actualización de abril de 2015 de Google introdujo la métrica de optimización para dispositivos móviles del gigante de las búsquedas, que mejora la clasificación de las páginas optimizadas para dispositivos móviles en los SERP móviles.
En efecto, Google dará prioridad a aquellos sitios que garanticen 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 demasiado cerca uno del otro, no hay desplazamiento horizontal y se evita el contenido que no se puede reproducir.
La actualización se aplica a páginas individuales, no a sitios web completos, y tampoco afecta al contenido que se visualiza en navegadores de computadoras de escritorio o portátiles.
HTTPS, o protocolo seguro de transferencia de hipertexto, es una versión segura del protocolo de comunicación de Internet HTTP.
HTTPS, o HTTP, constituye la primera parte de cada URL, conocida como "esquema". Esta parte va antes del nombre de dominio, que es el segmento de la URL conocido como "autoridad".
La diferencia entre HTTPS y HTTP radica en que el primero es seguro, mientras que el segundo no. En la práctica, esto significa que los usuarios que acceden a un sitio web mediante una conexión HTTP envían sus datos personales en texto plano sin cifrar.
HTTPS protege esa conexión, lo que significa que todos los datos enviados entre el navegador del usuario y el servidor del sitio web se cifran durante el proceso. Los sitios que desean conexiones seguras necesitan un certificado SSL, que el navegador del usuario comprueba y verifica.
Los intersticiales son un formato de anuncios exclusivo para dispositivos móviles que aparecen únicamente en pausas naturales en el contenido (por ejemplo, cuando un usuario pasa de un artículo al siguiente) y cubren la pantalla en el proceso.
Los anuncios intersticiales se consideran intrusivos cuando bloquean u ocultan parcialmente la vista del contenido por parte del usuario. Los cuadros de diálogo en sitios web móviles que se comportan de forma similar también entran en esta categoría.
Las habilidades más sólidas de la mayoría de los editores tienden a ser la creación, publicación y marketing de contenido, lo que deja poco espacio para comprender y optimizar los distintos pilares de la experiencia de la página.
Los recursos finitos significan que los editores tendrán dificultades para justificar el tiempo y el dinero necesarios para investigar el backend de páginas web individuales, y mucho menos de un sitio web completo.
Incluso si los editores pueden dedicar tiempo a abordar el problema, como podemos ver arriba, la experiencia de la página es un asunto multifacético que requiere un enfoque holístico para ofrecer mejoras de rendimiento significativas.
Saber en cuál de las cuatro señales de experiencia de la página comenzar a trabajar puede ser un dolor de cabeza en sí mismo.
La experiencia de página es increíblemente importante para el SEO del editor, ya que un excelente contenido no es suficiente para garantizar una ubicación superior dentro de los SERP.
Google aún prioriza la mejor información, lo que significa que el contenido único o las primicias de noticias tendrán un buen rendimiento incluso si la experiencia de la página es deficiente . Sin embargo, cuando varios editores ofrecen una excelente cobertura temática, la experiencia de la página se convierte en un factor decisivo que influye en el posicionamiento en las SERP.
Cada uno de los cuatro pilares de la experiencia de página tiene un impacto diferente en el SEO de un sitio web. El impacto más inmediato proviene de centrarse en las CWV, lo que se traducirá en un sitio web que carga más rápido.
Numerosos estudios han demostrado que cuanto más tarda en cargarse un sitio web, más rápido pierde el interés la audiencia y mayor es la tasa de rebote.
Por ejemplo, un estudio de Google de 2018 descubrió que la probabilidad de rebote aumentó un 32% cuando los tiempos de carga de la página aumentaron de 1 segundo a 3 segundos.
Otro estudio de Google de 2020 reveló que los sitios de noticias que aprobaron la prueba CWV tuvieron una tasa de abandono un 22 % menor que los que no la aprobaron. Yahoo! JAPAN, por su parte, mejoró su puntuación CLS en 0,2 y registró un aumento del 15,1 % en las páginas vistas por sesión y 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 una señal de clasificación , una tasa de rebote alta habla de factores que a Google sí le importan, es decir, la velocidad de carga de una página, la capacidad de respuesta y la estabilidad visual.
Los editores que se dirigen a audiencias en dispositivos móviles deben asegurarse de que su sitio web transmita señales optimizadas para móviles que tanto Google como Bing puedan detectar. Ambos motores de búsqueda priorizarán los sitios web optimizados al mostrar resultados de búsqueda a usuarios móviles.
En comparación con las CWV y la optimización para dispositivos móviles, implementar HTTPS tendrá un impacto mucho menor en el SEO de un editor. Google anunció en 2014 que lo usaría como indicador de posicionamiento y comenzó a marcar todos los sitios HTTP como "no seguros" en Chrome en 2018. Sin embargo, la mayor ventaja es la mayor seguridad de los datos, especialmente si su módulo de negocio se basa en los ingresos por suscripciones.
Mientras tanto, los anuncios intersticiales intrusivos o los cuadros de diálogo pueden limitar la capacidad de los rastreadores web de rastrear e indexar una página, impidiendo que los motores de búsqueda puedan siquiera clasificarla, y mucho menos aparecer en los primeros lugares de los resultados de búsqueda.
El primer paso para mejorar la experiencia de la página comienza con la evaluación de la eficacia actual de su sitio web.
Existe una amplia gama de herramientas propias y de terceros para lograr esto, pero, para esta guía, analizaremos las herramientas propias de Google.
Sabemos que los CWV son un factor de posicionamiento importante. Pero ¿cómo se miden? La siguiente tabla muestra los parámetros dentro de los cuales deben encontrarse los valores óptimos de CWV para una experiencia óptima en la página.
Ahora que sabemos qué debemos medir y en qué medida, 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 a los editores es por lejos la más desafiante desde el punto de vista técnico y no es una que recomendamos siquiera considerar a menos que cuentes con un buen desarrollador que te ayude con su implementación.
Hablamos de recopilar datos de usuarios de tu sitio web, un proceso conocido como monitorización de usuarios reales (RUM), y luego analizar los resultados en Google Analytics 4 (GA4). Google cuenta con otras herramientas, como PageSpeed Insights (PSI), que utilizan el muestreo de datos para evaluar tu sitio. Sin embargo, si el objetivo es obtener una visión completa de la experiencia del usuario en tu sitio web, necesitas datos reales recopilados de tu sitio.
Recomendamos utilizar GA4 para esta tarea por la sencilla razón de que Google pretende comenzar a “eliminar” la generación anterior de Google Analytics, Universal Analytics (UA), a partir de mediados de 2023.
Como editor, ya deberías haber creado una cuenta de GA4 antes de la transición. Si aún no lo has hecho, sigue las guías de Google sobre cómo configurarla por primera vez o cómo añadirla a un sitio que ya tenga UA .
Una vez hecho esto, el siguiente paso es vincular el almacén de datos de BigQuery de Google a GA4 desde el Administrador de Analytics. Vincular BigQuery te permitirá consultar tus datos mediante SQL. Aquí tienes una guía sobre cómo vincularlos .
Una vez realizados estos pasos, ahora podemos agregar la biblioteca de web vitals 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 código abierto npm ejecutando “npm install web-vitals” en su terminal de comandos o mediante<script> tags on a content distribution network (CDN).
He aquí un ejemplo de dicho script:
Una vez instalada la biblioteca de web-vitals, los datos del usuario se pueden enviar a Google Tag Manager (GTM) mediante una etiqueta de plantilla personalizada recomendada por Google que Simo Ahava creó y mantiene.
Una vez instalada la etiqueta, las métricas de CWV y los datos de atribución asociados pueden enviarse a GA4.
Una vez que hayas configurado Analytics para rastrear los datos de GTM, podrás ver los datos de eventos en la interfaz de BigQuery. Estos datos se pueden consultar de la siguiente manera:
Una vez que se devuelve la consulta, el informe debería verse así:
Debemos recalcar que esta es una solución para desarrolladores y, de hecho, es mucho más compleja. Sin embargo, adoptar esta solución le proporcionará una visión más precisa del rendimiento de su sitio web.
Para obtener una explicación más detallada de este proceso, consulte la guía de Google para ver 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 del enfoque GA/RUM, sin embargo, se lo cita con frecuencia como una de las herramientas más importantes para medir CWV, gracias a la facilidad de uso de la herramienta.
Aunque solo utilice muestras de experiencias de usuario reales extraídas del Informe de Experiencia de Usuario de Chrome (CrUX) de los últimos 28 días, PSI ofrece una interfaz de usuario sencilla y fácil de entender . Esto simplifica enormemente la interpretación de los datos.
Como puede ver en nuestro ejemplo a continuación, examinar el sitio de Forbes proporciona inmediatamente una gran cantidad de información tanto en la versión de escritorio como en la versión móvil del editor.
PSI utiliza las categorías verde, ámbar y roja mencionadas anteriormente al asignar calificaciones de desempeño Bueno, Necesita mejorar y Malo.
El enfoque de muestreo de CrUX significa que, si bien la evaluación anterior de Forbes tomó en cuenta algunas experiencias de usuarios reales del sitio, no puede tener en cuenta todos los datos de los usuarios del sitio.
Este enfoque de muestreo se vuelve problemático para sitios más pequeños, muchos de los cuales no aparecerá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 código abierto Lighthouse . Vea el siguiente ejemplo:
El problema con este enfoque es que Lighthouse recopila sus datos utilizando configuraciones de dispositivo y red predeterminadas, que no reflejan la configuración de los usuarios. Por lo tanto, no es un buen sustituto del sistema real.
GSC es una herramienta diseñada para proporcionar a los editores una vista panorámica de los problemas de CWV de su sitio web, abriendo la puerta a un enfoque holístico para mejorar el rendimiento del sitio.
Para ello, agrupa sus informes de rendimiento de URL según su estado, tipo de métrica o similitud temática. No identifica problemas en páginas individuales, lo que impide implementar correcciones a nivel granular.
Aquí es donde interviene PSI. Cabe destacar, sin embargo, que el informe de cada página de PSI puede diferir considerablemente de los resultados grupales de GSC. Esto se debe a que cada página es solo un componente de los resultados grupales agregados de GSC.
Al iniciar sesión en el panel de control de GSC, los usuarios verán la pestaña Core Web Vitals a la izquierda. Al hacer clic en esta pestaña, se muestran informes CWV separados para dispositivos móviles y computadoras de escritorio para grupos de URL.
A pesar de que existen tres métricas CWV (LCP, FID y CLS), las URL recibirán una calificación general basada en su métrica de peor rendimiento para un dispositivo específico, lo que también afectará los informes de grupo.
Por ejemplo, si una URL en un dispositivo móvil recibe un FID deficiente y un LCP bueno, se etiquetará como deficiente en un dispositivo móvil.
Es importante destacar que GSC no está diseñado para soluciones granulares. Sin embargo, es ideal para editores con muchas páginas similares. Por ejemplo, los sitios de noticias pueden tener un diseño relativamente estándar para sus páginas de artículos, que utilizan una imagen como el elemento más grande en la parte superior de la página. En este caso, GSC puede ayudar rápidamente a identificar problemas de LCP en diversas URL.
La última herramienta del kit de medición del rendimiento de Google es Lighthouse . Esta herramienta es completamente diferente a las anteriores, ya que emula el rendimiento del usuario basándose en un conjunto de parámetros establecidos.
No utiliza datos de campo, por lo que sus usos prácticos son más limitados. Por ejemplo, los datos de campo se ven influenciados por la conexión de red del usuario y su distancia a los servidores del sitio, mientras que Lighthouse emula un dispositivo de rango medio para recopilar datos en un entorno controlado.
También es importante comprender que la puntuación de Lighthouse no es simplemente una combinación de las puntuaciones de CWV. Excluye el FID, ya que los datos de laboratorio, por su naturaleza, excluyen las interacciones del usuario final, y añaden las métricas de tiempo total de bloqueo (TBT), índice de velocidad (SI) y tiempo de interacción (TTI). Para quienes deseen simular una experiencia FID en el laboratorio, el TBT puede utilizarse como proxy.
Sin embargo, recomendamos no usar Lighthouse como herramienta principal de medición. En su lugar, debería usarse como herramienta complementaria a PSI para solucionar problemas específicos de la página.
Los editores que deseen utilizar Lighthouse en sus pruebas pueden hacerlo a través de Chrome Devtools , que está integrado directamente en el navegador Chrome, una extensión para dicho navegador o en web.dev/measure .
Lighthouse auditará su página web y le proporcionará puntuaciones de 1 a 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 se diferencia del diseño web de escritorio tradicional en que los dispositivos móviles tienen pantallas más pequeñas, generalmente tienen hardware menos potente y dependen únicamente de entradas táctiles.
Los sitios web optimizados para móviles priorizan la experiencia del usuario siguiendo una serie de prácticas recomendadas que analizaremos más adelante. Por ahora, la mejor manera de comprobar si tus páginas son compatibles con móviles es con la Prueba de Optimización para Móviles .
Al ingresar la URL de una página web optimizada para dispositivos móviles, se obtiene el siguiente resultado:
Las páginas que no superen esta prueba mostrarán varias opciones de solución. Las abordaremos más adelante.
Comprobar si su sitio web tiene una conexión segura es un proceso extremadamente sencillo que implica abrir su navegador y mirar el símbolo a la izquierda de la URL en la barra de direcciones.
En Chrome, una conexión segura se indicará mediante un símbolo de candado cerrado como este:
Una conexión no segura tendrá un símbolo de información como el siguiente:
Determinar si sus anuncios intersticiales son intrusivos o no no es tan simple como ingresar su sitio web en una herramienta en línea y esperar que aparezca una marca de verificación o no.
Requiere estudiar los anuncios intersticiales y los cuadros de diálogo de su sitio y decidir si pasan ciertos parámetros.
Piense en estos parámetros como preguntas, por ejemplo:
Si responde afirmativamente a cualquiera de estas preguntas, probablemente sea un indicador de que el anuncio o el cuadro de diálogo es intrusivo.
Ahora que tenemos una comprensión firme de 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 mejorar las señales de clasificación de nuestros sitios
Primero analizaremos CWV, ya que depurar y optimizar LCP, CLS y FID tendrán el mayor impacto en su capacidad de competir por los primeros lugares en las clasificaciones SERP muy disputadas.
Si bien la compatibilidad con dispositivos móviles es increíblemente importante para los sitios dirigidos a usuarios móviles, mejorar las CWV mejorará el rendimiento de las páginas de los sitios independientemente de si se visualizan en dispositivos móviles o en computadoras de escritorio.
El abordaje del HTTPS y los anuncios intersticiales intrusivos se ha dejado para el final, ya que son victorias más sencillas y menos gratificantes.
Hay varias opciones cuando se trata de mejorar el rendimiento de CWV, que hemos dividido en orden de importancia según las cuales creemos que merecen.
Optimizar los Core Web Vitals de cualquier página es un espectro de acciones y es importante saber por dónde empezar para maximizar sus recursos.
Como ya hemos señalado anteriormente, la pintura de contenido más grande (LCP) mide cuánto tiempo lleva cargar por completo el texto o la imagen más grande visible por encima del pliegue.
Utilice PSI para identificar qué contenido de la página activa la prueba LCP. Para ello, diríjase a la sección de diagnóstico del informe y haga clic en "Elemento de pintura con contenido más grande". Esto es lo que vimos en la página principal de SODP:
Una puntuación LCP baja generalmente se puede atribuir a tiempos de respuesta lentos del servidor, JavaScript y CSS que bloquean la representación, tiempos de carga de recursos o representación del lado del cliente, o incluso una combinación de los cuatro.
Optimizar su página en realidad implica optimizar cuatro subpartes diferentes del proceso de carga de LCP:
Todos estos pasos deben optimizarse para que veas una mejora en tu puntuación LCP. Sin embargo, esto no significa que todas las subpartes sean igualmente importantes.
Google ha sugerido que el tiempo total de LCP se debe desglosar de manera que el TTFB y el tiempo de carga de recursos representen cada uno alrededor del 40 %, mientras que la carga de recursos y los retrasos en la representación de elementos deben representar cada uno menos del 10 %.
Lo ideal sería que estas dos últimas estuvieran lo más cerca de cero posible y tuvieran prioridad sobre las otras dos fases.
Hay dos formas de ayudar a reducir el retraso de carga de recursos lo más cerca de cero posible:
Lo diremos directamente: recomendamos consultar con su desarrollador web antes de implementar estas correcciones. Esta es una operación de backend y requiere experiencia para que funcione correctamente.
Descubrimiento de recursos
Cada navegador web viene con un escáner de precarga, cuya función es ayudar al analizador HTML principal del navegador a detectar el contenido de la página.
Mientras que el analizador HTML principal procesa el marcado sin procesar hasta que se encuentra con un recurso bloqueado (como un script que no contiene un async o defer) , el escáner de precarga ocupa un papel más especulativo.
En otras palabras, el escáner de precarga busca recursos para obtener antes de que el analizador HTML principal los alcance y continúa funcionando incluso si el analizador está bloqueado. El escáner de precarga puede utilizarse 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 para cada activo.
Por ejemplo, si el LCP es una imagen, entonces sus src o srcset deben estar presentes en el código fuente. Las imágenes de fondo CSS, por su parte, se pueden precargar incluyendo en el marcado HTML o en el encabezado. Finalmente, las fuentes se pueden cargar de forma similar mediante .
Sin embargo, cabe destacar que usar la precarga para reducir los tiempos de carga de LCP puede generar nuevos problemas, como la despriorización asíncronos . Por eso recomendamos hablar con tu desarrollador sobre esto.
Para obtener más información sobre este tema, consulta los análisis profundos de Google sobre la optimización de LCP y el escáner de precarga .
Prioridad de recursos
Los navegadores intentan descargar recursos CSS, fuentes, scripts, imágenes e iframes de la forma más óptima posible mediante la asignación de prioridades. Si bien son excelentes para determinar las prioridades de los recursos, eso no significa que sean perfectos.
Para optimizar la priorización de recursos, los desarrolladores pueden usar sugerencias de prioridad basadas en marcado para indicar a los navegadores qué recursos tienen mayor prioridad. Por ejemplo, un desarrollador puede usar JavaScript y la API Fetch para etiquetar la imagen LCP con el fetchpriority="high" , lo que agiliza esa métrica CWV específica.
Vale la pena señalar que las sugerencias de prioridad solo funcionan en navegadores basados en Chromium , como Google Chrome y Microsoft Edge.
Es posible que su desarrollador ya haya implementado la carga diferida para los activos debajo del pliegue; consulte con él para estar seguro, pero también vale la pena pedirle que use sugerencias de prioridad para los activos por encima del pliegue.
Para obtener más información sobre la carga prioritaria, recomendamos consultar la guía de Google sobre carga de recursos .
El equipo de desarrollo del gigante de las búsquedas pudo utilizar Priority Hints para mejorar el LCP de 2,6 segundos a 1,9 segundos en una prueba de Google Flights.
FID rastrea cuánto tiempo tarda el navegador de un usuario en comenzar a procesar la primera entrada, excluyendo el desplazamiento y el zoom.
Esta medida captura la experiencia del usuario al interactuar con una página web, lo que significa que las páginas web lentas tendrán una puntuación baja. El objetivo es mantener la puntuación FID por debajo de 100 milisegundos.
La mala capacidad de respuesta generalmente se debe a un uso excesivo de JavaScript, que los navegadores procesarán antes que las entradas.
El código que consume el foco del navegador durante 50 milisegundos o más se denomina tarea larga y se considera un indicio de sobrecarga de JavaScript. Dividir estas tareas largas en fragmentos de código más pequeños puede solucionar el rendimiento lento y mejorar la FID.
Pero ese no es el único aspecto que vale la pena discutir con tu desarrollador. Es importante hablar sobre cómo la ejecución de scripts, tanto propios como de terceros, puede ralentizar tu sitio web. La carga progresiva de código y funciones puede ayudar a abordar los desafíos de los primeros, mientras que la carga bajo demanda y la priorización de carga pueden ayudar con los segundos.
Otra opción sería utilizar trabajadores web para ejecutar JavaScript en segundo plano y evitar que su navegador se sature al procesar scripts.
CLS es básicamente una medida de la estabilidad visual de tu sitio web. Si tus visitantes pierden su ubicación en una página porque el contenido se desplaza para dar paso a la carga de anuncios e imágenes, tu sitio tendrá una mala puntuación.
Cuanto menos rebote el diseño de tu página, mejor será tu puntuación CLS. Google evalúa los sitios web considerando la disrupción en la ventana gráfica, así como el salto de los recursos en relación con ella.
Minimizar cambios de diseño inesperados básicamente implica designar espacio para anuncios, imágenes y vídeos incrustados.
Recuerdas los src o srcset que analizamos al hablar sobre el descubrimiento de recursos? Esto es fundamental para mejorar las puntuaciones de CLS.
Para las imágenes estáticas, configure el ancho y la altura usando los src para indicarle al navegador que reserve espacio para activos de carga más lenta, evitando así cambios de diseño.
Vea el código de ejemplo de Google a continuación:
Las imágenes adaptables requieren un srcset para definir los límites máximos de ancho y alto que el navegador puede seleccionar. Asegúrate de usar imágenes con la misma relación de aspecto.
He aquí otro ejemplo:
Al tratar con anuncios, hay algunos pasos que puedes seguir:
También se recomienda reservar espacio estático si desea implementar iFrames, contenido incrustado y contenido dinámico, como llamadas a la acción (CTA).
Cuando los navegadores descargan y renderizan fuentes web, existe la posibilidad de que se produzca un destello de texto sin estilo (FOUT) o un destello de texto invisible (FOIT). El primero ocurre al reemplazar una fuente de respaldo por una nueva, mientras que el segundo se debe a un retraso en la renderización de una nueva fuente.
Puedes resolver ambos problemas usando Para indicarle al escáner de precarga que capture las fuentes web antes. Las fuentes precargadas tienen mayor probabilidad de aparecer en la primera capa.
Hay otras soluciones en la guía de resolución de problemas de CLS , así como también su análisis profundo del uso de la precarga para evitar FOIT .
Si está buscando mejoras en la velocidad del sitio y todavía utiliza una opción de alojamiento de servidor único tradicional, entonces probablemente sea momento de considerar cambiar a una red de distribución de contenido (CDN).
Una CDN consiste en una red de servidores ubicados en diferentes centros de datos alrededor del mundo que distribuyen el contenido del sitio web para mejorar el rendimiento. Si bien tanto la opción de un solo servidor (también conocido como alojamiento local) como la CDN entregan el contenido del sitio web a los visitantes, solo una CDN puede tener en cuenta la ubicación geográfica del usuario y seleccionar el servidor más cercano para reducir los tiempos de carga.
Sin embargo, la geografía no es la única ventaja, ya que las CDN también están mejor equipadas para gestionar picos de tráfico repentinos, así como recursos del servidor raíz, como el ancho de banda.
En definitiva, 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, existen varios competidores importantes a considerar .
Independientemente del proveedor de alojamiento que utilice, sus servidores estarán sujetos a ciertas restricciones de hardware.
Los servidores contienen en gran medida los mismos componentes clave que permiten el funcionamiento de tu portátil o computadora de escritorio (CPU y RAM), que gestionan todas las tareas de tu cuenta. Deberías poder usar el panel de control de tu proveedor de hosting para comprobar la CPU y la RAM instaladas en tu servidor e incluso solicitar recursos adicionales para mejorar el rendimiento de tu sitio web.
Si analiza la CPU de su servidor, es importante comprender que solo se utiliza un núcleo para atender la solicitud de un visitante a una página web. Esto significa que las velocidades de reloj de un solo núcleo siempre son más rápidas. Las CPU multinúcleo pueden procesar múltiples vistas de página y otros servicios del servidor.
Este es otro para tu desarrollador.
Revise su base de datos con cierta frecuencia para asegurarse de que no esté sobrecargada con fotos y archivos sin usar. Eliminar archivos innecesarios la despejará, lo que acelerará el tiempo promedio de carga de las páginas.
Usar imágenes muy grandes puede ralentizar tu sitio web. ¿De qué tamaño? Cualquier imagen de más de 1 MB es simplemente demasiado grande.
Y como ya sabemos, los tiempos de carga más lentos generarán tasas de rebote más altas y enviarán señales no deseadas a Google.
Para quienes usan WordPress, existen varios plugins de optimización de imágenes que pueden simplificar una tarea manual que de otro modo sería tediosa. Además, muchos también incluyen otras funciones como la carga diferida y el ajuste de tamaño automático.
Que un sitio sea compatible con dispositivos móviles o no depende de si lo ha simplificado y agilizado para la experiencia de navegación móvil.
Los usuarios móviles interactúan con las páginas de forma diferente y tienen mucha menos paciencia con los tiempos de carga lentos y los sitios web difíciles de navegar. Si su sitio web no ha superado la prueba de optimización para móviles descrita anteriormente, o incluso si la ha superado, pero le interesa optimizarlo aún más, repasemos algunas de las mejores prácticas.
Esta debería ser la principal preocupación de todo editor. Una forma sencilla de abordar la facilidad de uso es plantearse preguntas como:
Estas respuestas te ayudarán a identificar los problemas de los usuarios. Por ejemplo, no quieres que tus usuarios ajusten sus pantallas para ver tu contenido. Puedes ver a qué nos referimos en el siguiente ejemplo.
Para optimizar su contenido para dispositivos móviles, existen tres opciones de desarrollo:
Los hemos ordenado en términos de facilidad de implementación y recomendamos adoptar un diseño responsive, ya que es el 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 tienes que mantener un sitio web, que puede mostrarse fácilmente en cualquier tipo de pantalla.
Por el contrario, los diseños dinámicos funcionan mostrando código HTML diferente según el dispositivo del usuario. Las páginas deben usar el encabezado HTTP Vary para evitar que se muestre código incorrecto en el dispositivo equivocado.
Finalmente, existen subdominios móviles, que no recomendamos debido a la cantidad de recursos necesarios para una implementación eficaz. Los subdominios móviles son sitios completamente independientes con necesidades de alojamiento distintas. Para garantizar que los rastreadores comprendan la relación entre dominio y subdominio, deberá incluir la etiqueta rel="canonical"
Dado que el diseño responsivo es la opción más sencilla, es la que recomendamos a los editores. Para obtener más información sobre el diseño responsivo, consulta la guía de implementación de Google .
A continuación se muestra una lista rápida de consideraciones técnicas para cualquier diseño:
Este último paso es la forma más sencilla de mejorar la experiencia de la página, pero también contribuye en gran medida a mejorar la tranquilidad del usuario.
Cambiar a HTTPS protege y cifra la información de sus usuarios, además de ayudar a prevenir ataques de intermediario (MitM). Además, tener un certificado SSL elimina las advertencias del navegador sobre falta de seguridad.
Tu proveedor de hosting debería poder ofrecerte seguridad HTTPS; si no es así, podrías considerar cambiarte a uno que sí lo haga. Ya existen varios proveedores de hosting reconocidos que ofrecen HTTPS gratis . Además, los que ofrecen certificados SSL utilizan su propio servicio en lugar del externo, lo que facilita y agiliza aún más la implementación.
Si desea solicitar e instalar un certificado SSL de una Autoridad de Certificación (CA), debe seguir cuatro pasos:
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 que utilice HTTPS.
Le recomendamos 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 completa de Google sobre el tema.
Los anuncios intersticiales intrusivos y los cuadros de diálogo dificultan que los motores de búsqueda comprendan el contenido de una página web, lo que puede perjudicar el rendimiento de SERP.
Sería fantástico si hubiera una forma de crear anuncios intersticiales que no interrumpieran la experiencia del usuario, pero ese es el objetivo de estos anuncios: ocupan toda la pantalla en las pausas del contenido para captar la atención del usuario.
Por lo tanto, a los editores les conviene más usar anuncios de banner en lugar de anuncios intersticiales, ya que solo ocupan una pequeña parte de la pantalla. Es mejor arriesgarse a la ceguera del banner que a la frustración del usuario.
Los editores pueden utilizar banners compatibles con el navegador o banners HTML simples que enlacen a la página de destino del CTA.
Los cuadros de diálogo también se pueden usar para campañas promocionales, pero pueden diseñarse para que sean discretos. Es necesario garantizar que los usuarios puedan acceder al contenido sin interrupciones.
No existen atajos para optimizar la experiencia de tu página, y es fundamental que abordes los puntos anteriores. Dicho esto, cabe destacar 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 para mejorar el rendimiento de CWV.
Si analizamos el Informe de tecnología CWV, vemos que solo alrededor del 29 % de los sitios web de WordPress tienen buenos CWV, mientras que el 41 % de los sitios de Wix obtienen la marca verde.
Vale la pena evaluar si cambiar a un CMS especializado podría mejorar sus CWV de forma nativa.
Hay mucho camino por recorrer cuando se trata de optimizar la experiencia de la página, y comenzar puede ser un poco abrumador. Sin embargo, es importante recordar que se come el elefante dando un mordisco a la vez.
Aspirar a una puntuación "Buena" en todas tus métricas de CWV no es necesario para que tu sitio web suba en las SERP. Sin embargo, establecer objetivos tan ambiciosos puede ser contraproducente, ya que puede ser un objetivo desmoralizante.
En lugar de eso, busca pequeñas mejoras en tus resultados de CWV y concéntrate en abordar los resultados "deficientes" sin preocuparte demasiado por los "necesita mejorar". Eso puede venir después, cuando tengas más tiempo y recursos para dedicarle al proceso.
Ya hemos hablado de la mejora en la puntuación CLS de Yahoo! JAPAN. Veamos un par de sitios más de los que podemos aprender algunas lecciones.
El diario indio The Economic Times, que atiende a más de 45 millones de usuarios activos mensuales, redujo su puntuación CLS en un 250%, de 0,25 a 0,09, y su tiempo LCP en un 80%, de 4,5 segundos a 2,5 segundos.
Entre octubre de 2020 y julio de 2021, la editorial redujo las puntuaciones LCP en el rango "Deficiente" en un 33%, mientras que los valores CLS en el rango "Deficiente" disminuyeron un 65%. Estas mejoras permitieron a The Economic Times superar los umbrales de CWV en toda su área de origen, a la vez que reducían las tasas de rebote generales en un 43%.
El editor logró esto de diversas maneras, la primera de las cuales fue priorizar las descargas de recursos mediante sugerencias de prioridad. También abordó las tareas largas, fragmentando fragmentos de código para garantizar que los recursos críticos para la representación de la página superior se cargaran primero.
El sitio web de noticias del Reino Unido mejoró su puntuación 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%.
The Telegraph utilizó Chrome DevTools para identificar instancias individuales de cambio de diseño.
Antes de eso, utilizaba WebPageTest para encontrar dónde en la línea de tiempo se produjo el cambio de diseño.
Con estos datos en la mano, el equipo comenzó a centrarse en reducir los cambios de diseño abordando estas áreas
Para los anuncios, The Telegraphed comenzó a reservar espacio y utilizó el tamaño de anuncio más común para especificar las dimensiones. Esto también ayudó a evitar que los anuncios se colapsaran al visualizarse 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.
The Telegraph realizó otros ajustes, como mover el encabezado a la parte superior del marcado y usar marcadores de posición para videos incrustados, pero finalmente describió el proceso como "bastante fácil" y que aún tuvo un impacto significativo.
Mejorar la experiencia de usuario no tiene por qué ser abrumador. Mide los cuatro pilares de la experiencia de usuario y luego decide qué recursos puedes dedicar a mejorar tus resultados.
Si eres una editorial pequeña, el equilibrio de recursos será crucial y te recomendamos identificar recursos razonablemente fáciles de alcanzar para tu primer proyecto.
Al analizar el enfoque del Telegraph, se centró en un aspecto de las CWV en lugar de los tres, e implementó mejoras significativas. El Economic Times se centró en dos de los tres y obtuvo resultados impresionantes.
Activo ahora
Ver más
