Supervisa el rendimiento

Priorizar el rendimiento no solo es bueno para los usuarios, sino que también puede ser bueno para las empresas. Si bien las prácticas recomendadas de esta colección se enfocan principalmente en la optimización de la integración de Google Publisher Tag (GPT), hay muchos otros factores que contribuyen al rendimiento general de una página determinada. Cada vez que realices cambios, es importante evaluar el impacto de esos cambios en todos los aspectos del rendimiento de tu sitio.

Mide el rendimiento de la página

Para comprender cómo afecta un cambio al rendimiento de tu sitio, primero debes establecer un modelo de referencia con el cual comparar. La mejor manera de hacerlo es crear un presupuesto de rendimiento que defina un modelo de referencia, que tu sitio puede cumplir o no en la actualidad. Sin embargo, si te interesa mantener un nivel fijo de rendimiento, puedes usar las métricas de rendimiento actuales de tu sitio como modelo de referencia.

Para comenzar a medir el rendimiento, se recomienda una combinación de los siguientes enfoques:

  • Supervisión sintética
    Puedes usar herramientas como Lighthouse y Publisher Ads Audits for Lighthouse para medir el rendimiento de la página en un entorno de lab. Este tipo de medición no requiere interacción del usuario final, por lo que es adecuada para su uso en pruebas automatizadas y se puede usar para validar el rendimiento de los cambios antes de lanzarlos a los usuarios.
  • Supervisión de usuarios reales (RUM)
    Puedes usar herramientas como Google Analytics y PageSpeed Insights para recopilar datos de rendimiento reales directamente de los usuarios. Este tipo de medición se basa en las interacciones del usuario final, por lo que es útil para identificar problemas de rendimiento de la última milla que las pruebas sintéticas no pueden detectar fácilmente.

Asegúrate de tomar mediciones y compararlas con tu modelo de referencia con regularidad. Esto te dará una buena indicación de si el rendimiento de tu sitio está en la dirección correcta con el tiempo.

Elige qué medir

En lo que respecta al rendimiento, no hay una métrica única que pueda brindarte todo lo que necesitas saber acerca del rendimiento de tu sitio. Para obtener una imagen completa, deberás analizar una variedad de métricas que abarcan varios aspectos del rendimiento de la página. En la siguiente tabla, se enumeran algunas áreas de rendimiento clave y métricas sugeridas.

Área de rendimiento
Velocidad de carga percibida Mediciones

La rapidez con la que una página puede cargar y renderizar todos los elementos de la IU.


Métricas sugeridas

Primer procesamiento de imagen con contenido (FCP)
Procesamiento de imagen con contenido más grande (LCP)
Tiempo para renderizar el primer anuncio

Capacidad de respuesta de la carga de página Mediciones

Indica la rapidez con la que una página se vuelve responsiva después de la carga inicial.


Métricas sugeridas

Retraso de primera entrada (FID)
Tiempo de carga (TTI)
Tiempo de bloqueo total (TBT)

Estabilidad visual Mediciones

La cantidad de elementos de la IU que se desplazan y si estos desplazamientos interfieren con la interacción del usuario Consulta Minimiza el cambio de diseño para obtener más información.


Métricas sugeridas

Cambio de diseño acumulado
Cambio de diseño acumulado (CLS)

Además del rendimiento de la página, es posible que también quieras medir las métricas de la empresa específicas del anuncio. Puedes obtener información como impresiones, clics y visibilidad por posición en los informes de Google Ad Manager.

Probar cambios

Una vez que hayas definido tus métricas de rendimiento y hayas comenzado a medirlas con regularidad, puedes comenzar a usar estos datos para evaluar el impacto en el rendimiento de los cambios que realices en tu sitio a medida que se implementen. Para ello, compara las métricas medidas después de un cambio con las que se midieron antes de que se realizara el cambio (o el modelo de referencia que estableciste antes). Este tipo de pruebas te permitirá detectar y abordar los problemas de rendimiento antes de que se conviertan en un problema importante para tu empresa o tus usuarios.

Pruebas automáticas

Puedes medir las métricas que no dependen de la interacción del usuario a través de pruebas sintéticas. Este tipo de pruebas se deben ejecutar con la mayor frecuencia posible durante el proceso de desarrollo para comprender cómo los cambios no publicados afectarán el rendimiento. Este tipo de pruebas proactivas puede ayudar a descubrir problemas de rendimiento antes de que los cambios se publiquen para los usuarios.

Una forma de lograrlo es hacer que las pruebas sintéticas sean parte de un flujo de trabajo de integración continua (IC), en el que las pruebas se ejecutan automáticamente cada vez que se realiza un cambio. Puedes usar Lighthouse CI para integrar pruebas de rendimiento sintético en muchos flujos de trabajo de CI:

Pruebas A/B

Las métricas que dependen de la interacción del usuario no se pueden probar por completo hasta que se lance un cambio para los usuarios. Esto puede ser riesgoso si no estás seguro de cómo se comportará el cambio. Una técnica para mitigar ese riesgo es la prueba A/B.

Durante una prueba A/B, se publican diferentes variantes de una página para los usuarios de forma aleatoria. Puedes usar esta técnica para publicar una versión modificada de tu página a un pequeño porcentaje del tráfico general, mientras que a la mayoría se le seguirá mostrando la página sin modificar. Combinado con la RUM, puedes evaluar el rendimiento relativo de los dos grupos para determinar cuál tiene un mejor rendimiento, sin poner en riesgo el 100% del tráfico.

Otro beneficio de las pruebas A/B es que te permiten medir con mayor precisión los efectos de los cambios. En muchos sitios, puede ser difícil determinar si una pequeña diferencia en el rendimiento se debe a un cambio reciente o a una variación normal en el tráfico. Dado que el grupo experimental de una prueba A/B representa un porcentaje fijo del tráfico general, las métricas deben diferir del grupo de control en un factor constante. Por lo tanto, las diferencias observadas entre los 2 grupos se pueden atribuir con mayor confianza al cambio que se está probando.

Las herramientas como Optimizely y Google Optimize pueden ayudarte a configurar y ejecutar pruebas A/B. Sin embargo, ten en cuenta que las pruebas A/B basadas en etiquetas (la configuración predeterminada de estas herramientas) pueden afectar negativamente el rendimiento y proporcionar resultados engañosos. Por lo tanto, se recomienda la integración del servidor:

Resultados de la prueba A/B

Para medir el impacto de un cambio con una prueba A/B, recopilas métricas de los grupos de control y experimental, y las comparas entre sí. Para ello, necesitas una forma de saber qué tráfico es parte de qué grupo.

En el caso de las métricas de rendimiento de la página, a menudo es suficiente incluir un identificador simple en cada página que indique si se publicó la versión de control o la experimental. Este identificador puede ser cualquier cosa que desees, siempre que sea algo con lo que puedas analizar y correlacionar las métricas. Si usas un framework de prueba compilado previamente, esto se suele controlar automáticamente.

En el caso de las métricas comerciales específicas del anuncio, puedes usar la función de segmentación por par clave-valor de GPT para diferenciar las solicitudes de anuncios del grupo de control del grupo experimental:

// On control group (A) pages, set page-level targeting to:
googletag.pubads().setTargeting('your-test-id', 'a');

// On experimental group (B) pages, set page-level targeting to:
googletag.pubads().setTargeting('your-test-id', 'b');

Luego, se puede hacer referencia a estos pares clave-valor cuando se ejecutan informes de Google Ad Manager para filtrar los resultados por grupo.