WebPageTest

TL;DR — WebPageTest es una herramienta gratuita que carga su página en un navegador real, desde una ubicación real, y le muestra exactamente qué ocurrió durante la carga: cada archivo que descargó, en qué orden, y un video fotograma a fotograma de la página apareciendo. Es la herramienta que se usa cuando PageSpeed Insights dice que una página es lenta pero usted quiere ver por qué. No es un producto de Google, y sus puntuaciones no influyen en su posicionamiento: es una herramienta de diagnóstico.

Qué es WebPageTest

La mayoría de las herramientas de velocidad le dan un número. WebPageTest le da una historia: una imagen detallada, paso a paso, de cómo se cargó su página.

Se entra en webpagetest.org, se escribe una URL, se elige desde qué punto del mundo probar y con qué tipo de dispositivo y conexión, y se inicia la prueba. Un navegador real, en una máquina real, carga su página, y WebPageTest lo registra todo: cada imagen, script y fuente que solicitó, cuánto tardó cada uno, y un filmstrip: un conjunto real de capturas de pantalla, fotograma a fotograma, de la página apareciendo en pantalla.

Es gratuita y de código abierto. La creó un desarrollador llamado Patrick Meenan en 2008, y una empresa llamada Catchpoint la compró en 2020; pero la versión pública gratuita en webpagetest.org sigue ahí, a disposición de cualquiera.

Por qué usarla en lugar de PageSpeed Insights

PageSpeed Insights (la herramienta de Google) es excelente para decirle que una página es lenta y darle una puntuación. WebPageTest es mejor para decirle por qué y dónde. Si PSI dice «reduce render-blocking resources», WebPageTest le muestra el archivo exacto que está bloqueando, en qué segundo, en un gráfico que se lee como una línea de tiempo.

La otra cosa que la gente entiende mal: las puntuaciones de WebPageTest no son un factor de posicionamiento. Google posiciona en parte según la rapidez con la que los visitantes reales experimentan su sitio (eso se llama «field data», datos de campo, y procede de usuarios reales de Chrome). WebPageTest es una prueba de «laboratorio» (lab): una ejecución controlada en una máquina. Sirve para encontrar y corregir problemas, no para el número que Google ve en realidad.

Las dos vistas por las que casi todo el mundo empieza

• El waterfall. Un gráfico con una fila por cada archivo que cargó su página, apilados en el orden en que llegaron. Las barras largas y los archivos acumulados al principio suelen ser donde vive la lentitud.
• El filmstrip. Una fila de capturas de pantalla que muestran la página pintándose a lo largo del tiempo. Puede ver literalmente el momento en que aparece su contenido principal, o el momento en que algo salta de sitio en la página.

¿Quiere la versión completa: la connection view, la receta exacta que uso para cazar los desplazamientos de diseño, cómo se compara con Lighthouse y CrUX, y cómo la uso para SEO técnico? Cambie a la pestaña Avanzado.

TL;DR — WebPageTest es una herramienta de rendimiento de laboratorio (sintética), gratuita y de código abierto: entran una URL, una ubicación de prueba real y distribuida, un navegador y un perfil de red; salen diagnósticos profundos: waterfall (marcas de recursos que bloquean el renderizado, secuenciación), filmstrip/video (fotograma a fotograma, con una opción Highlight Layout Shifts para el CLS), connection view (DNS/TCP/TLS/TTFB) y Core Web Vitals fotograma a fotograma. Patrick Meenan la creó en 2008 (una herramienta interna de AOL); Catchpoint la adquirió en 2020; el código sigue siendo abierto bajo la licencia Polyform Shield. El eje de rigor: produce datos de laboratorio, no datos de campo, así que no alimenta la señal de posicionamiento de CWV de Google (esa es la de CrUX, con usuarios reales). Es un diagnóstico, no la puntuación que ve Google; y tampoco es competencia de Lighthouse, porque puede ejecutar Lighthouse dentro de ella. Recurra a ella cuando PageSpeed Insights le diga que una página es lenta pero no por qué ni en qué punto de la carga.

Qué es en realidad

Cada resultado de WebPageTest es una ejecución configurada: una URL, probada desde una ubicación concreta, en un navegador y un dispositivo concretos, sobre un perfil de conexión concreto, en un momento concreto. No es una medición universal de «lo rápido que es su sitio»: es evidencia de esa ejecución, y hay que leerla como tal.

Dentro de ese encuadre, WebPageTest es la herramienta de diagnóstico profundo de la caja de herramientas del rendimiento web. web.dev, el propio sitio para desarrolladores de Google, lo plantea bien: “WebPageTest contains an advanced suite of metrics and trace viewers. It enables deep diving into the performance of your site on real mobile hardware with network conditions.” (traducción) «WebPageTest reúne un conjunto avanzado de métricas y visores de trazas. Permite profundizar en el rendimiento de su sitio en hardware móvil real con condiciones de red.» (web.dev, «Cómo entender las herramientas de velocidad»)

Su página de auditoría añade el ángulo cercano al SEO: “WebPagetest will also check static-content caching, time to first byte, and if your site makes effective use of CDNs.” (traducción) «WebPageTest también comprueba la caché del contenido estático, el tiempo hasta el primer byte y si su sitio aprovecha eficazmente las CDN.» (web.dev, «Auditar el rendimiento»)

Donde las herramientas hermanas de este clúster —Google Lighthouse, PageSpeed Insights y el Chrome UX Report (CrUX)— le dan una puntuación o un apto/no apto, WebPageTest le da la evidencia petición por petición y fotograma a fotograma que hay debajo de esa puntuación.

Una breve historia, y una nota al pie genuinamente rara

Patrick Meenan creó WebPageTest y la liberó como código abierto en 2008; nació como herramienta interna de pruebas en AOL. Catchpoint la adquirió en 2020. La página «Acerca de» lo cuenta directamente: “Catchpoint’s 2020 acquisition of WebPageTest, created and open-sourced by Patrick Meenan in 2008, marked a significant milestone.” (traducción) «La adquisición de WebPageTest por parte de Catchpoint en 2020 —creada y liberada como código abierto por Patrick Meenan en 2008— marcó un hito importante.» La misión que se declara allí es contundente: “slow is the new down, and our mission is to empower you to deliver the best experiences to your users.” (traducción) «la lentitud es la nueva caída, y nuestra misión es ayudarle a ofrecer la mejor experiencia posible a sus usuarios». (webpagetest.org/about)

Esta es la nota al pie rara que vale la pena nombrar: Meenan trabaja ahora en Google, en Chrome y en rendimiento web. Y sin embargo, la propia página oficial de herramientas de Core Web Vitals de Google —web.dev/articles/vitals-tools, exactamente la página a la que el documento sobre Core Web Vitals de Search Central enlaza con el texto “the different tools that can help you measure and report Core Web Vitals” (traducción) «las distintas herramientas que pueden ayudarle a medir las Core Web Vitals y a elaborar informes sobre ellas»— no menciona WebPageTest. Enumera CrUX, PageSpeed Insights, Search Console, Lighthouse, el panel Performance de DevTools, la biblioteca JS web-vitals y Lighthouse-CI. La herramienta creada por la persona que ahora trabaja allí está ausente.

Léalo con cuidado, eso sí: no es una señal de que WebPageTest esté obsoleta o carezca de respaldo. Google mantiene una lista curada de sus propios productos; una herramienta de código abierto de terceros sencillamente no está en ella. Otras páginas de web.dev (speed-tools, performance-audit-tools) hacen referencia a WebPageTest de forma positiva. Es un vacío de curación, no un veredicto sobre la herramienta.

Laboratorio vs. campo: la distinción que más importa

Este es el eje de rigor de todo el tema, y es el hermano del punto laboratorio-frente-a-campo que recorre todo el clúster de herramientas de rendimiento web.

WebPageTest ejecuta datos de laboratorio (sintéticos): una prueba controlada y repetible en una máquina que usted configura, en un momento que usted elige. Eso es algo muy distinto de los datos de campo: las mediciones de usuarios reales del Chrome UX Report (CrUX) que Google Search sí utiliza para la señal de posicionamiento de Core Web Vitals, y que aparecen en PageSpeed Insights y en Search Console.

Dicho llanamente:

• Una ejecución de WebPageTest no alimenta la señal de posicionamiento de Google. Mide las mismas métricas que le importan a Google (LCP, INP, CLS), pero el número por el que Google posiciona viene de los datos de campo de CrUX, no de ninguna ejecución de laboratorio: ni de la de WebPageTest, ni de la sección de laboratorio de PSI, ni de la de Lighthouse.
• WebPageTest sirve para el diagnóstico: reproducir un problema, aislarlo y confirmar una corrección en un ciclo rápido y controlado. Los datos de campo (CrUX) son la confirmación lenta y autorizada de que los usuarios reales notaron la mejora; véase Core Web Vitals para saber cómo funciona esa señal de posicionamiento.

Dicho sin rodeos, un resultado de WebPageTest no es —y no puede sustituir a— los datos de campo de CrUX, las cifras de tráfico de usuarios reales, ni un resultado de posicionamiento o de experiencia de página en Google Search. Son conjuntos de datos independientes que necesitan su propia evidencia; una ejecución sintética rápida no es prueba de que ninguno de ellos se haya movido.

Si solo se lleva una cosa de esta página: WebPageTest le dice qué corregir; CrUX le dice si se movió la señal de posicionamiento de Google.

Cómo ejecutar una prueba básica

El flujo básico es deliberadamente sencillo:

1. URL. La página pública que quiere probar (tiene que ser accesible públicamente).
2. Test location. WebPageTest se ejecuta en máquinas reales distribuidas físicamente por el mundo: elija una cercana a su audiencia, porque la distancia y las condiciones de red cambian el resultado.
3. Navegador / dispositivo. Chrome le da la mayor cantidad de datos. También puede emular dispositivos móviles.
4. Perfil de conexión. Una red limitada (por ejemplo, una conexión móvil lenta) para que esté probando condiciones realistas, no la fibra de su oficina.
5. Ejecuciones repetidas. Esto es lo que se salta quien empieza. El rendimiento varía de una ejecución a otra (jitter de red, carga del servidor, contención de CPU), así que WebPageTest ejecuta varias pruebas e informa de una mediana. Nunca confíe en una sola ejecución: lea la mediana. Eso sí, tenga en cuenta que la mediana sigue siendo una muestra sintética de la configuración que usted eligió, no una medición poblacional de lo que experimentan los visitantes reales; para eso están los datos de campo (CrUX).

Cada uno de esos ajustes forma parte del experimento, no es un detalle incidental. Si está comparando dos pruebas —antes/después de una corrección, o su sitio frente al de un competidor—, la comparación solo significa algo cuando registra los ajustes y los mantiene constantes: la misma ubicación, el mismo navegador, el mismo perfil de conexión, el mismo estado de caché (first view frente a repeat view) y aproximadamente el mismo número de ejecuciones y la misma ventana temporal. Cambie cualquiera de ellos entre ejecuciones y podrá confundir con facilidad la deriva de la configuración de prueba con una diferencia real de rendimiento.

Cómo leer los resultados

El gráfico waterfall

El waterfall es una línea de tiempo petición por petición: una fila por recurso, en orden de carga, y cada barra muestra las fases de DNS/conexión/TLS/espera/descarga. Marca los recursos que bloquean el renderizado, muestra las cadenas de redirecciones como saltos adicionales y hace evidente cuándo un puñado de recursos situados arriba está frenando todo lo que viene detrás. Aquí es donde «reduce render-blocking resources» deja de ser una abstracción y se convierte en «ese archivo CSS, en ese segundo».

La connection view

Agrupada por conexión en lugar de por petición, esta vista expone la resolución DNS, la conexión TCP, la negociación TLS y el time to first byte (TTFB) por host. Es la forma más rápida de ver si su lentitud está del lado del servidor o de la red (un TTFB lento, demasiadas conexiones separadas) o del lado del contenido.

El filmstrip / video view, y mi receta para cazar el CLS

El filmstrip es una tira de capturas de pantalla de la página pintándose a lo largo del tiempo; el video view la reproduce. Es como ve —no como infiere— cuándo aparece su contenido principal y cuándo salta algo en la página.

Esta es la función de WebPageTest en la que más me apoyo, y la he recorrido repetidamente en charlas y en mi guía de Core Web Vitals en Ahrefs. Para cazar el Cumulative Layout Shift, la receta exacta que uso: “In Filmstrip View, use the following options: Highlight Layout Shifts, Thumbnail Size: Huge, Thumbnail Interval: 0.1 secs.” (traducción) «En Filmstrip View, use las siguientes opciones: Highlight Layout Shifts, Thumbnail Size: Huge, Thumbnail Interval: 0,1 s.» Eso convierte el filmstrip en una línea de tiempo de alta resolución en la que un desplazamiento es imposible de pasar por alto. En el ejemplo real de esa guía, el culpable era un cambio de fuente: “Notice how our font restyles between 5.1 secs and 5.2 secs, shifting the layout as our custom font is applied.” (traducción) «Fíjese en cómo nuestra fuente cambia entre los 5,1 s y los 5,2 s, desplazando el diseño a medida que se aplica nuestra fuente personalizada.» Las fuentes web, las imágenes que cargan tarde y los anuncios inyectados son los sospechosos habituales del CLS, y el filmstrip los pilla visualmente en el acto.

Una precaución: que un recurso termine de cargarse en el waterfall en el mismo momento en que el filmstrip muestra un salto es una evidencia circunstancial fuerte, no una prueba: es una hipótesis. Confírmela aislando al sospechoso (bloquee ese dominio o esa petición, o aplácela) y volviendo a ejecutar la misma configuración; si el desplazamiento desaparece, ha confirmado la causa en lugar de limitarse a correlacionar dos líneas de tiempo.

Core Web Vitals, fotograma a fotograma

WebPageTest informa de LCP, CLS y (con interacción real) INP junto a TTFB, FCP y Speed Index, y le permite ver en qué punto de la carga ocurrió cada uno en lugar de darle solo un valor final. Cuando hay datos de campo de CrUX disponibles, pueden mostrarse junto a los resultados de laboratorio, pero los diagnósticos profundos son los de la ejecución de laboratorio.

Funciones avanzadas

• Scripting / flujos de varios pasos. Pruebe páginas detrás de un inicio de sesión, o un flujo de carrito/checkout: cree un script de los pasos para que WebPageTest mida un recorrido real y no solo una portada en frío. Controle y anote de qué depende el script: la cuenta o las credenciales de prueba utilizadas, en qué estado está esa cuenta, cualquier contenido dinámico de la página y su cuota de API; un script sin documentar es tan difícil de comparar entre ejecuciones como una prueba manual sin documentar.
• Bloqueo de dominios / peticiones. Bloquee un dominio de terceros concreto y vuelva a ejecutar la prueba para medir exactamente cuánto le está costando ese widget de chat o ese script publicitario. Esto es algo que PSI sencillamente no puede hacer.
• Lighthouse dentro de WebPageTest. «WebPageTest vs. Lighthouse» es una falsa dicotomía: puede ejecutar una auditoría de Lighthouse desde dentro de WebPageTest. Vale la pena ser preciso sobre lo que eso significa: la auditoría de Lighthouse es su propio informe distinto y versionado —su propia puntuación de 0–100 y su propia lista de auditorías—, generado dentro de la sesión de prueba más amplia de WebPageTest, no fusionado con las métricas nativas de waterfall/filmstrip de WebPageTest. Como lo expresé en la guía de Ahrefs, la mayoría de las herramientas de velocidad usan Lighthouse por debajo: “The exception is WebPageTest, although you can also run Lighthouse tests with it as well.” (traducción) «La excepción es WebPageTest, aunque también puede ejecutar pruebas de Lighthouse con ella.» (Ahrefs — Core Web Vitals)
• Opportunities & Experiments. Una función de comparación antes/después de cambios en el HTML, sin código, que permitía comparar dos estados de una página sin tocar producción; se introdujo alrededor de 2022, según la cobertura de la época de Detlef Johnson en Search Engine Land (ese artículo concreto ha sido retirado del sitio desde entonces, y no pude reconfirmar de forma independiente el nombre actual ni la disponibilidad de la función frente a una sesión activa de WebPageTest durante esta ronda de actualización; conviene comprobarlo de nuevo antes de montar un flujo de trabajo en torno a ese nombre).
• API / automatización e instancias privadas. Hay una API para pruebas programáticas y, como el código es abierto, puede levantar su propia instancia privada.

Usar WebPageTest para SEO técnico

Este es el ángulo que la mayoría de las guías de WebPageTest se saltan, y es la razón por la que la herramienta pertenece al kit de un SEO técnico:

• Probar como Googlebot. Puede fijar un agente de usuario de Googlebot y observar cómo se comporta el JS que bloquea el renderizado: una aproximación útil (no una réplica perfecta) de cómo podría experimentar la página el renderizador de Google. La guía de WebPageTest para SEO técnico de MobileMoxie plantea bien su valor para el SEO: “The tool provides detailed information about the health of your pages and helps analyze things like round trip requests, asset errors, redirects, caching concerns, security information, and more.” (traducción) «La herramienta ofrece información detallada sobre la salud de sus páginas y ayuda a analizar cosas como las peticiones de ida y vuelta, los errores de recursos, las redirecciones, los problemas de caché, la información de seguridad y más.»
• Auditar cadenas de redirecciones. El waterfall expone cada salto de redirección, de modo que una cadena de redirecciones inflada (cada una, un viaje de ida y vuelta) queda a la vista en lugar de oculta.
• Comprobar la eficacia de la caché y de la CDN. Según web.dev, más arriba, WebPageTest comprueba el almacenamiento en caché de contenido estático, el TTFB y el uso de CDN: las cañerías que gobiernan la rapidez con la que tanto los bots como los usuarios reciben sus bytes.
• Diagnosticar problemas de renderizado con JS. Si el contenido solo aparece después de que se ejecute JavaScript, el filmstrip y el waterfall le muestran cuándo (y si) se pintó.
• Evidencia antes/después para las partes interesadas. Un filmstrip en paralelo de la página actual frente a una corrección propuesta es un artefacto mucho más persuasivo para un cliente o un equipo de ingeniería que una cifra de Lighthouse que bajó seis puntos.

Precios y acceso

El servicio público gratuito de webpagetest.org ha ofrecido históricamente del orden de cientos de ejecuciones de prueba al mes, además de una clave de API gratuita con límites diarios. Un nivel de pago, WebPageTest Pro, desbloquea más volumen de API, pruebas privadas y prioridad en la cola de pruebas. Y como todo el conjunto es de código abierto bajo la licencia Polyform Shield —Catchpoint lo formula así: “the WebPageTest code remains freely accessible under the Polyform Shield license, permitting its use for internal or non-competing commercial projects” (traducción) «el código de WebPageTest sigue siendo libremente accesible bajo la licencia Polyform Shield, lo que permite su uso en proyectos comerciales internos o no competidores» (webpagetest.org/about) —, también puede alojar usted mismo una instancia privada.

Limitaciones honestas

• Curva de aprendizaje. La interfaz es densa; un waterfall intimida antes de resultar útil.
• Hace falta una cuenta para los resultados guardados o privados. Las pruebas sueltas y ocasionales son abiertas, pero guardar resultados y hacer pruebas privadas requiere una cuenta.
• Diagnostica, no remedia. WebPageTest le muestra el problema con un detalle exquisito; no le llevará de la mano hasta la solución como intentan hacer algunas herramientas de puntuación.
• Variabilidad de una sola ejecución. Una sola ejecución puede inducir a error. Use varias ejecuciones y lea la mediana: por algo la herramienta lo hace así por defecto.

Una nota sobre Bing

No hay documentación de Bing ni de Microsoft que posicione a WebPageTest como una entrada de posicionamiento ni como una recomendación de primera parte. Bing Webmaster Tools tiene su propio Site Scan y sus recomendaciones relacionadas con la velocidad, pero nada específico de WebPageTest; y las propias Core Web Vitals siguen siendo principalmente una construcción de Google. (No confunda WebPageTest con el bing.com/tools/speedtest del propio Bing, que es una prueba de velocidad de red, no una herramienta de rendimiento de página.)

Dónde encaja esto

Este es el miembro de diagnóstico profundo del clúster de herramientas de rendimiento web. Cada una de sus hermanas tiene un trabajo distinto: Google Lighthouse es la auditoría de laboratorio que produce la puntuación de 0–100 (y que muchas otras herramientas ejecutan por debajo); PageSpeed Insights muestra los datos de campo de CrUX y una ejecución de laboratorio de Lighthouse en una sola interfaz; el Chrome UX Report (CrUX) es el conjunto de datos de campo de usuarios reales con el que Google posiciona realmente. Para las métricas que todas ellas miden y los umbrales que usa Google, empiece por el hub de Core Web Vitals. Para ver el flujo completo en el que se enmarcan estas herramientas, consulte el clúster de rendimiento web.

Resumen con IA

Una síntesis condensada de la versión Advanced:

• WebPageTest = la herramienta de rendimiento de diagnóstico profundo, basada en laboratorio. Gratuita y de código abierto; creada por Patrick Meenan en 2008 (una herramienta interna de AOL), adquirida por Catchpoint en 2020, con el código bajo la licencia Polyform Shield.
• Cada resultado es una ejecución configurada: una URL, una ubicación, un navegador, un perfil de conexión, un momento en el tiempo; no una medición universal. Las comparaciones solo significan algo cuando registra esos ajustes y los mantiene constantes.
• Laboratorio, no campo. Produce datos sintéticos de laboratorio y no alimenta la señal de posicionamiento de Core Web Vitals de Google: esa es la de CrUX, con usuarios reales (visible en PageSpeed Insights y en Search Console). Una ejecución de WebPageTest tampoco establece el tráfico de usuarios reales ni un resultado de posicionamiento o de experiencia de página en Search: sirve para el diagnóstico, no para el número por el que Google posiciona.
• El flujo: URL → ubicación de prueba real y distribuida → navegador/dispositivo → red limitada → varias ejecuciones repetidas, lea la mediana (nunca una sola ejecución; aunque incluso la mediana sigue siendo una muestra sintética, no datos de campo).
• Vistas características: waterfall (petición por petición, marcas de recursos que bloquean el renderizado, cadenas de redirecciones), filmstrip/video (fotograma a fotograma; una opción Highlight Layout Shifts para el CLS), connection view (DNS/TCP/TLS/TTFB) y Core Web Vitals fotograma a fotograma. Alinear un evento del waterfall con un fotograma del filmstrip es una hipótesis sólida, no una prueba: confírmelo aislando el recurso y volviendo a probar.
• Receta para el CLS: Filmstrip View → Highlight Layout Shifts activado, Thumbnail Size Huge, Thumbnail Interval 0,1 s: la manera de pillar en el acto un cambio de fuente o un desplazamiento por una imagen tardía.
• No es competencia de Lighthouse: puede ejecutar una auditoría de Lighthouse desde dentro de WebPageTest, pero es su propio informe distinto y versionado (su propia puntuación, sus propias auditorías), no fusionado con las métricas nativas de WebPageTest. Otras funciones avanzadas: scripting/flujos de varios pasos (documente credenciales/estado/cuotas), bloqueo de dominios de terceros, una función de comparación antes/después sin código introducida alrededor de 2022 (su nombre y disponibilidad actuales no se reconfirmaron de forma independiente en esta ronda), una API y el autoalojamiento.
• Usos en SEO: probar como Googlebot, auditar cadenas de redirecciones, comprobar la caché/CDN/TTFB, diagnosticar el renderizado con JS y producir evidencia antes/después para las partes interesadas.
• Nota al pie curiosa: Meenan trabaja ahora en Google y, aun así, la propia página oficial de herramientas de CWV de Google (web.dev/articles/vitals-tools) no incluye WebPageTest. Eso es un vacío de curación para una herramienta de terceros, no una señal de que esté obsoleta.
• Limitaciones: interfaz densa y curva de aprendizaje, hace falta una cuenta para las pruebas guardadas o privadas, diagnostica en lugar de remediar, y una sola ejecución puede inducir a error.

Documentación oficial

Documentación de fuentes primarias (las menciones de WebPageTest por parte de Google, la documentación propia de WebPageTest y una nota sobre Bing).

WebPageTest / Catchpoint

• WebPageTest — Acerca de: la historia de origen Meenan/Catchpoint, la declaración de misión y la licencia Polyform Shield.
• WebPageTest: el servicio público gratuito de pruebas, incluidos el formulario de prueba, la interfaz de resultados/filmstrip y la API para pruebas programáticas.

Google (dónde hace referencia a WebPageTest, y dónde llamativamente no)

• web.dev — Cómo entender las herramientas de velocidad: sitúa a WebPageTest como la opción avanzada de diagnóstico de laboratorio y señala que se puede ejecutar Lighthouse desde la propia herramienta.
• web.dev — Auditar el rendimiento: presenta WebPageTest para comprobar caché, TTFB y CDN.
• web.dev — Herramientas para Core Web Vitals: el recopilatorio de herramientas de CWV del propio Google, que no menciona WebPageTest (la nota al pie del vacío de curación).
• Google Search Central — Core Web Vitals: enlaza a web.dev para las recomendaciones de herramientas en lugar de nombrar una herramienta de laboratorio de terceros.

Bing / Microsoft

• Ninguna documentación de Bing/Microsoft hace referencia a WebPageTest como entrada de posicionamiento ni como recomendación de primera parte. El Site Scan propio de Bing Webmaster Tools es el análogo de primera parte más cercano. Consulte las directrices para webmasters de Bing para orientación general.

Citas de la fuente

Declaraciones oficiales sobre WebPageTest. Cuando un enlace incluye un anclaje #:~:text=, salta al pasaje citado en la página de origen.

Google / web.dev: dónde encaja WebPageTest

• “WebPageTest contains an advanced suite of metrics and trace viewers. It enables deep diving into the performance of your site on real mobile hardware with network conditions.” (traducción) «WebPageTest ofrece métricas avanzadas y visores de trazas con los que puede analizar a fondo el rendimiento del sitio en hardware móvil real y bajo distintas condiciones de red.» — web.dev, «Cómo entender las herramientas de velocidad». Ir a la cita
• “WebPagetest will also check static-content caching, time to first byte, and if your site makes effective use of CDNs.” (traducción) «WebPageTest también revisa la caché del contenido estático, el tiempo hasta el primer byte y si el sitio utiliza bien las CDN.» — web.dev, «Auditar el rendimiento». Ir a la cita

WebPageTest / Catchpoint: historia, misión, licencia

• “Catchpoint’s 2020 acquisition of WebPageTest, created and open-sourced by Patrick Meenan in 2008, marked a significant milestone.” (traducción) «La adquisición en 2020 por Catchpoint de WebPageTest, que Patrick Meenan había creado y publicado como código abierto en 2008, marcó un hito importante.» — página «Acerca de» de WebPageTest. Fuente
• “slow is the new down, and our mission is to empower you to deliver the best experiences to your users.” (traducción) «La lentitud es la nueva caída, y nuestra misión es darle los medios para ofrecer a sus usuarios la mejor experiencia.» — página «Acerca de» de WebPageTest. Fuente
• “The WebPageTest code remains freely accessible under the Polyform Shield license, permitting its use for internal or non-competing commercial projects.” (traducción) «El código de WebPageTest continúa disponible libremente bajo la licencia Polyform Shield, que permite utilizarlo en proyectos internos o en proyectos comerciales que no compitan con el servicio.» — Catchpoint, página «Acerca de» de WebPageTest. Fuente

Patrick Stox (yo) / Ahrefs: la técnica del filmstrip para el CLS

• “In Filmstrip View, use the following options: Highlight Layout Shifts, Thumbnail Size: Huge, Thumbnail Interval: 0.1 secs.” (traducción) «En Filmstrip View, use las siguientes opciones: Highlight Layout Shifts, Thumbnail Size: Huge, Thumbnail Interval: 0,1 s.» — de mi guía de Core Web Vitals en Ahrefs. Fuente
• “The exception is WebPageTest, although you can also run Lighthouse tests with it as well.” (traducción) «La excepción es WebPageTest, aunque también puede ejecutar pruebas de Lighthouse con ella.» — yo, sobre en qué se diferencia WebPageTest de las herramientas basadas en Lighthouse. Fuente

MobileMoxie: el ángulo del SEO técnico

• “The tool provides detailed information about the health of your pages and helps analyze things like round trip requests, asset errors, redirects, caching concerns, security information, and more.” (traducción) «La herramienta detalla el estado de las páginas y facilita el análisis de peticiones de ida y vuelta, errores de recursos, redirecciones, caché, información de seguridad y otros aspectos.» — MobileMoxie, sobre WebPageTest para SEO técnico. Fuente

Hoja de referencia rápida de WebPageTest

Dónde encaja frente a las otras herramientas

Las vistas

Receta para cazar el CLS (mía)

• Filmstrip View → Highlight Layout Shifts activado → Thumbnail Size: Huge → Thumbnail Interval: 0,1 s. Busque el fotograma en el que el diseño salta (a menudo un cambio de fuente web o una imagen/anuncio tardío).

Datos rápidos

• Laboratorio, no campo: no alimenta la señal de posicionamiento de CWV de Google (esa es la de CrUX).
• Lea la mediana, nunca una sola ejecución: el rendimiento varía de una ejecución a otra.
• Puede ejecutar Lighthouse dentro de WebPageTest: no es una disyuntiva.
• Código abierto bajo la licencia Polyform Shield; el autoalojamiento es posible.
• Meenan (su creador) trabaja ahora en Google y, aun así, web.dev/articles/vitals-tools no incluye WebPageTest: un vacío de curación, no una obsolescencia.

Una ejecución de WebPageTest: checklist

Consiga un resultado fiable y útil en lugar de uno engañoso:

• Test location fijada cerca de su audiencia real (la distancia cambia las cifras).
• Dispositivo y perfil de conexión coinciden con los de sus usuarios (por ejemplo, móvil emulado en una red limitada), no con la fibra de su oficina.
• Varias ejecuciones repetidas activadas, y está leyendo la mediana, no una sola ejecución.
• Revisado el waterfall en busca de recursos que bloquean el renderizado y de saltos de redirección sueltos.
• Revisada la connection view en busca de un TTFB lento o de demasiadas conexiones separadas.
• Ejecutado el filmstrip para ver cuándo se pinta el contenido principal y, para el CLS, activado Highlight Layout Shifts con intervalos de 0,1 s y miniaturas Huge.
• Confirmado que está tratando el resultado como datos de laboratorio, y contrastada la señal de posicionamiento real con CrUX (PageSpeed Insights / Search Console).
• Para un tercero sospechoso, usado el bloqueo de dominios/peticiones para medir su costo real.
• Para flujos de inicio de sesión o de compra, usado scripting en lugar de probar una portada en frío.
• Guardado un filmstrip antes/después si va a proponer una corrección a las partes interesadas.

Herramientas que se complementan con WebPageTest

• El propio WebPageTest (webpagetest.org): la herramienta pública gratuita de laboratorio, además de la API y un nivel Pro de pago para volumen y pruebas privadas.
• PageSpeed Insights: la vía rápida para consultar los datos de campo (CrUX) que WebPageTest no puede generar, y así saber si la señal de posicionamiento se movió de verdad.
• Google Search Console — informe «Core Web Vitals»: encuentre grupos de páginas que fallan a escala en todo el sitio y después lleve una URL representativa a WebPageTest para diagnosticarla.
• Panel Performance de Chrome DevTools: el compañero local, cómodo para páginas con inicio de sesión, para el análisis de laboratorio cuando no necesita ubicaciones distribuidas.
• Google Lighthouse: ejecutable desde dentro de WebPageTest, o de forma autónoma en DevTools/CLI para la auditoría de 0–100.
• CrUX Vis (cruxvis.withgoogle.com): visualice la tendencia de campo de usuarios reales a lo largo del tiempo para confirmar que una corrección diagnosticada con WebPageTest llegó a los usuarios reales. (Véase el Chrome UX Report (CrUX).)

Errores con WebPageTest que generan falsa confianza

Tratar una ejecución de laboratorio como el veredicto de campo de Google

WebPageTest son datos sintéticos del dispositivo, la ubicación, el navegador y el perfil de red que usted seleccionó. Úselo para diagnosticar causas; use CrUX o RUM de primera parte para describir a los usuarios reales y la evaluación de CWV de Google.

Comparar ejecuciones con ajustes de prueba distintos

Un cambio de ubicación, de conexión, de navegador, de estado de caché o del número de ejecuciones puede pesar más que el cambio de código que se está probando. Guarde la configuración y compare lo comparable.

Optimizar la puntuación principal en lugar del waterfall

El valor de WebPageTest está en la secuenciación de peticiones, el establecimiento de conexiones, los filmstrips y el momento de cada métrica. Rastree la métrica lenta hasta una petición concreta o un evento concreto del hilo principal, en lugar de ajustar una calificación de forma aislada.

Juzgar un cambio a partir de una sola ejecución

Las pruebas de laboratorio varían. Ejecute varias pruebas con el mismo perfil y compare resultados representativos; investigue los valores atípicos en lugar de quedarse con la ejecución más rápida.

Probar solo la portada

Cada plantilla tiene elementos LCP, scripts, terceros y comportamiento de caché distintos. Incluya las páginas donde los usuarios y los datos de campo muestran el problema real.

Demostrar un cambio de rendimiento en WebPageTest

Prueba controlada antes/después

Prueba a ejecutar: guarde una configuración de ubicación/navegador/red/caché y ejecute varias pruebas para la versión sin cambios y para la modificada. Resultado esperado: la métrica objetivo y su causa en el waterfall mejoran en ejecuciones representativas. Interpretación del fallo: el cambio es ineficaz, o la varianza de la prueba supera al efecto. Ventana de seguimiento: resultado de laboratorio inmediato. Disparador de reversión: una regresión constante en la métrica objetivo o en una Core Web Vital adyacente.

Prueba de secuenciación de peticiones

Prueba a ejecutar: compare waterfalls después de cambiar el preload, la prioridad, el CSS/JS que bloquea el renderizado o la caché. Resultado esperado: la petición prevista empieza antes, transfiere menos bytes o evita la red en el estado de caché esperado. Interpretación del fallo: la indicación o la configuración no se aplicó, u otra dependencia controla la secuencia. Ventana de seguimiento: inmediata. Disparador de reversión: el cambio retrasa una petición más crítica o genera errores.

Prueba de corrección visual

Prueba a ejecutar: inspeccione el filmstrip/video y el resaltado de desplazamientos de diseño para el mismo perfil antes/después. Resultado esperado: un renderizado más rápido no introduce contenido ausente, parpadeos ni nuevos desplazamientos. Interpretación del fallo: la mejora numérica sacrificó la corrección visual. Ventana de seguimiento: cada viewport representativo antes de publicar. Disparador de reversión: contenido roto o una nueva inestabilidad visible.

Recursos que valen su tiempo

Mis textos relacionados

• Core Web Vitals: guía completa (Ahrefs): incluye mi receta de Filmstrip de WebPageTest para diagnosticar el Cumulative Layout Shift, la comparación entre WebPageTest y Lighthouse y las métricas que mide la herramienta, además de explicar cómo intervienen en el posicionamiento. (Esta página absorbió mi anterior guía avanzada de PageSpeed Insights, que ahora redirige aquí.)
• Guía de SEO técnico para principiantes (Ahrefs): explica dónde encaja el rendimiento web en el panorama general.

Mis charlas

• Actualización sobre experiencia de página — TMC, junio de 2021 (SlideShare): cubre la misma técnica de Filmstrip/CLS de WebPageTest en formato de charla.
• Curso intensivo de SEO técnico — Beer & SEO Meetup, mayo de 2019 (SlideShare): muestra WebPageTest como parte del kit de SEO técnico ya en 2019.

De la industria

• WebPageTest — Acerca de: la fuente primaria para la historia, la misión y la licencia Polyform Shield.
• Cómo entender las herramientas de velocidad (web.dev): el lugar que el propio Google asigna a WebPageTest entre las herramientas de laboratorio.
• Auditar el rendimiento (web.dev): explica el uso de WebPageTest para comprobar caché, TTFB y CDN.
• Cómo configurar WebPageTest para evaluar el SEO técnico (MobileMoxie): la guía de configuración existente más cercana al enfoque SEO (agente de usuario de Googlebot, redirecciones, caché y errores de recursos).
• Guía completa para usar WebPageTest (Kinsta): el texto explicativo general más completo sobre historia, configuración, interpretación de resultados y precios.
• WebPageTest: guía de pruebas de rendimiento web (DebugBear): escrito por un proveedor, pero con un buen desglose del promedio de varias ejecuciones, las vistas waterfall, filmstrip y de conexiones, y el scripting.

Ponga a prueba sus conocimientos: WebPageTest

Cinco preguntas rápidas sobre qué es WebPageTest, cómo leerlo y dónde encaja. Elija una respuesta para cada una y después compruebe.

Registro de cambios