Experimentar con la medición de navegaciones suaves

Barry Pollard

Michal Mocny

Fecha de publicación: 1 de febrero de 2023; última actualización: 30 de marzo de 2026

Desde su lanzamiento, la iniciativa de Métricas web esenciales ha buscado medir la experiencia real del usuario de un sitio web, en lugar de los detalles técnicos detrás de cómo se crea o carga un sitio web. Las tres métricas de Core Web Vitals se crearon como métricas centradas en el usuario, una evolución de las métricas técnicas existentes, comoDOMContentLoaded o load, que medían los tiempos que a menudo no estaban relacionados con la forma en que los usuarios percibían el rendimiento de la página. Por este motivo, la tecnología utilizada para crear el sitio no debería afectar la puntuación, siempre y cuando el sitio tenga un buen rendimiento.

La realidad siempre es un poco más compleja que el ideal, y las métricas de Métricas web esenciales nunca admitieron por completo la popular arquitectura de aplicación de una sola página. En lugar de cargar páginas web individuales y distintas a medida que el usuario navega por el sitio, estas aplicaciones web usan las llamadas "navegaciones suaves", en las que el contenido de la página se cambia con JavaScript. En estas aplicaciones, la ilusión de una arquitectura de página web convencional se mantiene alterando la URL y enviando las URLs anteriores al historial del navegador para permitir que los botones de atrás y adelante funcionen como el usuario esperaría.

Muchos frameworks de JavaScript usan este modelo, pero cada uno de una manera diferente. Dado que esto está fuera de lo que el navegador tradicionalmente entiende como una "página", medirlo siempre ha sido difícil: ¿dónde se debe trazar la línea entre una interacción en la página actual y considerarla como una página nueva?

El equipo de Chrome ha estado considerando este desafío durante algún tiempo y busca estandarizar una definición de lo que es una "navegación suave" y cómo se pueden medir las Métricas web esenciales para este tipo de navegación, de manera similar a como se miden los sitios web implementados en la arquitectura convencional de varias páginas (MPA).

Realizamos varias mejoras en la API en función de los comentarios de los desarrolladores sobre la última prueba de origen y ahora les pedimos a los desarrolladores que prueben la iteración más reciente y proporcionen comentarios sobre el enfoque antes de que se lance. Tenemos bastante confianza en la versión final de la API después de estas iteraciones y nuestro objetivo es lanzarla más adelante este año, según los comentarios que recibamos sobre esta última prueba de origen.

¿Qué es la navegación suave?

Creamos la siguiente definición de navegación suave:

• La navegación se inicia con una acción del usuario.
• La navegación genera un cambio visible en la URL para el usuario.
• La interacción genera una pintura visible.

En algunos sitios, estas heurísticas pueden generar falsos positivos (que los usuarios no considerarían realmente como una "navegación") o falsos negativos (en los que el usuario sí considera que se produjo una "navegación" a pesar de no cumplir con estos criterios). Agradecemos tus comentarios sobre las heurísticas en el repositorio de especificaciones de navegación suave.

Compatibilidad de DevTools con las navegaciones suaves

Agregamos compatibilidad con las navegaciones suaves en el panel Rendimiento de las Herramientas para desarrolladores en la vista de registro:

Puedes ver marcadores para las navegaciones suaves y el LCP, ambos marcados con un * para ayudar a diferenciarlos de las entradas de navegación dura habituales. Esta opción está habilitada de forma predeterminada y es independiente de los cambios en la API de rendimiento que analizaremos a continuación. Es una forma rápida de probar si el experimento de navegación suave funciona correctamente en tu sitio.

Por el momento, solo se muestran las marcas de tiempo de la navegación suave y el LCP en la vista de seguimiento. Más adelante, se agregarán otras métricas (por ejemplo, LCP) y compatibilidad en la vista de Métricas en vivo.

¿Cómo implementa Chrome las navegaciones suaves para los desarrolladores web?

Una vez que se habiliten las heurísticas de navegación suave (más información en la siguiente sección), Chrome cambiará la forma en que informa algunas métricas de rendimiento:

• Se emitirá un evento soft-navigation PerformanceTiming después de que se detecte cada navegación no definitiva.
• Esta entrada soft-navigation incluirá un navigationId, la nueva URL en el atributo name, así como un interactionId de la interacción iniciadora.
• Se emitirán una o más entradas de interaction-contentful-paint después de las interacciones que provoquen una pintura con contenido. Se puede usar para medir el Largest Contentful Paint (LCP) en las navegaciones suaves cuando la interacción emite una navegación suave.
• El atributo navigationId se agrega a cada uno de los tiempos de rendimiento (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event y layout-shift). Esto corresponde a la entrada de navegación en la que se emitió el evento. Ten en cuenta que, cuando estas entradas abarcan navegaciones suaves, pueden contener el navigationId anterior o siguiente, según el momento en que se emitió la entrada. Obtén más información sobre este tema en la sección Informa las métricas en la URL adecuada.
• El soft-navigation incluirá una entrada largestInteractionContentfulPaint que contendrá la entrada interaction-contentful-paint más grande emitida como parte de la navegación. Luego, se puede usar como el LCP inicial de esa navegación, y ese LCP se puede actualizar a medida que se observan más entradas de interaction-contentful-paint para esa interacción.
• Es posible que algunas entradas de interaction-contentful-paint ocurran antes de que se produzca la navegación suave (si la actualización de la URL no se produce hasta después de esas renderizaciones). En estos casos, la entrada largestInteractionContentfulPaint más grande evita la necesidad de almacenar en búfer y revisar entradas anteriores. Ten en cuenta que el largestInteractionContentfulPaint es una copia exacta de la entrada interaction-contentful-paint más grande, por lo que esa entrada habrá usado el navigationId anterior, ya que fue cuando se produjo el procesamiento de imagen, pero estos procesamientos de imagen se deben medir en función del nuevo navigationId.
• La entrada soft-navigation también incluirá paintTime y presentationTime como el FCP para esa navegación.
• Ten en cuenta que también se emitirán entradas de interaction-contentful-paint después de más interacciones, pero el LCP de una URL debe restringirse a las entradas de interaction-contentful-paint que coincidan con las navegaciones suaves interactionId para excluirlas.

Estos cambios permitirán que las métricas web esenciales y algunas de las métricas de diagnóstico asociadas se midan por navegación de página, aunque hay algunos matices que se deben tener en cuenta.

¿Cuáles son las implicaciones de habilitar las navegaciones suaves en Chrome?

Estos son algunos de los cambios que los propietarios de sitios deben tener en cuenta después de habilitar esta función:

• El monitoreo de las entradas de soft-navigation permite "segmentar" las entradas de rendimiento en cada "navegación".
• Las métricas de CLS y INP ya se pueden segmentar a tu discreción, en lugar de medirse durante la duración de todo el ciclo de vida de la página, pero la API de Soft Navigation proporciona una medida estandarizada de cuándo sucede esto, independientemente de la tecnología subyacente que se utilice.
• La entrada largest-contentful-paint se finaliza en una interacción (lo cual es necesario para iniciar una navegación suave), por lo que solo se puede usar para medir el LCP de la navegación "dura" inicial. Esto significa que no cambiará cuando se midan las navegaciones suaves, por lo que el LCP de la carga de la página inicial y de navegación dura se puede medir como siempre.
• La nueva entrada interaction-contentful-paint que se emitirá a partir de las interacciones se puede usar para medir el LCP en las navegaciones suaves, pero hay algunas consideraciones sobre cómo usar esta entrada que analizaremos en este artículo.
• Ten en cuenta que no todos los usuarios admitirán esta API de navegación suave, en especial en las versiones anteriores de Chrome y en quienes usen otros navegadores. Ten en cuenta que es posible que algunos usuarios no registren las métricas basadas en la navegación suave, incluso si registran las métricas de Métricas web esenciales.
• Como se trata de una nueva función experimental que no está habilitada de forma predeterminada, los sitios deben probarla para detectar efectos secundarios no deseados.

Consulta con tu proveedor de RUM si admite la medición de las Métricas web esenciales por navegación suave. Muchos planean probar este nuevo estándar y tendrán en cuenta las consideraciones anteriores. Mientras tanto, algunos proveedores también permiten mediciones limitadas de las métricas de rendimiento basadas en sus propias heurísticas.

Para obtener más información sobre cómo medir las métricas de las navegaciones suaves, consulta la sección sobre cómo medir las métricas web esenciales por navegación suave.

¿Cómo habilito las navegaciones suaves en Chrome?

Las navegaciones suaves no están habilitadas de forma predeterminada en Chrome, pero están disponibles para experimentación si se habilita explícitamente esta función.

En el caso de los desarrolladores, pueden habilitar esta opción activando la marca en chrome://flags/#soft-navigation-heuristics. También se puede habilitar con los argumentos de la línea de comandos de --enable-features=SoftNavigationHeuristics cuando se inicia Chrome. Habilitar la marca chrome://flags/#enable-experimental-web-platform-features también habilita las navegaciones suaves.

En el caso de un sitio web que desee habilitar esta función para que todos sus visitantes vean el impacto, se ejecutará una prueba de origen a partir de Chrome 147 que se puede habilitar registrándose en la prueba y, luego, incluyendo un elemento meta con el token de la prueba de origen en el encabezado HTML o HTTP. Consulta la publicación Comienza a usar las pruebas de origen para obtener más información.

Los propietarios de sitios pueden optar por incluir la prueba de origen en sus páginas para todos los usuarios o solo para un subconjunto de ellos. Ten en cuenta la sección de implicaciones anterior para saber cómo esto cambia la forma en que se pueden informar tus métricas, en especial si habilitas esta prueba de origen para una gran proporción de tus usuarios. Ten en cuenta que CrUX seguirá registrando las métricas de la misma manera, independientemente de este parámetro de configuración de navegación suave, por lo que no se verá afectado por esas implicaciones. También se debe tener en cuenta que las pruebas de origen también se limitan a habilitar funciones experimentales en un máximo del 0.5% de todas las cargas de páginas de Chrome como mediana durante 14 días, pero esto solo debería ser un problema para los sitios muy grandes.

Cómo detectar la compatibilidad con la API de Soft Navigations

Puedes usar el siguiente código para probar si se admite la API:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

Ten en cuenta que supportedEntryTypes se inmoviliza en el primer uso, por lo que, si un token de prueba de origen insertado en la página agrega de forma dinámica la compatibilidad con las navegaciones suaves, es posible que se muestre el valor original, antes de que se active esa función.

En este caso, se puede usar la siguiente alternativa mientras las navegaciones suaves aún no se admiten de forma predeterminada y se encuentran en este estado de transición:

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

¿Cómo puedo medir las navegaciones suaves?

Una vez que se habilite el experimento de navegación suave, las métricas se registrarán con la API de PerformanceObserver, como sucede con otras métricas. Sin embargo, hay algunas consideraciones adicionales que se deben tener en cuenta para estas métricas.

Cómo informar navegaciones suaves

Puedes usar un PerformanceObserver para observar las navegaciones suaves. A continuación, se muestra un ejemplo de fragmento de código que registra entradas de navegación suave en la consola, incluidas las navegaciones suaves anteriores en esta página con la opción buffered:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

Se puede usar para finalizar las métricas de página de ciclo de vida completo de la navegación anterior.

Informa las métricas en la URL correspondiente

Cuando se detecta una navegación suave, se deben finalizar las Métricas web esenciales de la página anterior y, luego, se deben registrar para la URL anterior. Además, se debe iniciar el monitoreo nuevo para la URL nueva.

El atributo name de la entrada soft-navigation adecuada contendrá la nueva URL para la que se deben informar las métricas, y navigationId será la referencia única para esta navegación (ya que se puede visitar la misma URL varias veces durante la vida útil de una aplicación de una sola página). Esto se puede consultar con la API de PerformanceEntry:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

Denuncia la URL correcta de interaction-contentful-paint

Se necesitan consideraciones adicionales para calcular el LCP a partir de las entradas de interaction-contentful-paint, ya que no todas las entradas de interaction-contentful-paint se deben asignar con navigationId ni se deben informar como LCP para esa URL:

• El primer problema es que se pueden emitir entradas de interaction-contentful-paint antes de que se produzca la navegación suave si se produce una pintura antes de la actualización de la URL. En estos casos, el navigationId será para la URL anterior. Si primero se actualiza la URL, la pintura completará la navegación suave y, en ese caso, primero se emitirá la entrada soft-navigation y la interaction-contentful-paint tendrá la URL nueva.
• El segundo problema es que, en interaction-contentful-paint, se seguirán emitiendo entradas para las interacciones más recientes, ya que el alcance de esta métrica de rendimiento se extiende más allá del LCP para las navegaciones suaves. Solo queremos considerar las renderizaciones de la carga de navegación suave para el LCP y no las de las interacciones posteriores.

Por lo tanto, se debe usar interactionId en lugar de navigationId para asignar entradas de interaction-contentful-paint a soft-navigation-entries y obtener la URL correcta. Esto controlará las entradas con navigationIds antiguos y filtrará las entradas de interaction-contentful-paint que no se deben tener en cuenta para el LCP.

Además, también deberías considerar procesar la entrada largestInteractionContentfulPaint de las entradas soft-navigation, para controlar con mayor facilidad las entradas interaction-contentful-paint que ocurren antes de que se emita soft-navigation entries.

Cómo obtener el startTime de las navegaciones suaves

Todos los tiempos de rendimiento, incluidos los de las navegaciones suaves, y las entradas que se usan para calcular las métricas de Métricas web esenciales se registran como un tiempo desde el tiempo de navegación inicial "dura" de la página. Por lo tanto, el tiempo de inicio de la navegación suave se debe restar de los tiempos de las métricas de carga de la navegación suave (por ejemplo, LCP) para informarlos en relación con este tiempo de navegación suave.

La hora de inicio de la navegación se puede obtener de manera similar asignando la entrada soft-navigation adecuada y usando su startTime.

El objeto startTime es la hora de la interacción inicial (por ejemplo, un clic en un botón) que inició la navegación suave. Esto es algo diferente a las "navegaciones duras", en las que la "hora de inicio" es cuando la página nueva se "confirma" en el navegador y después de que se ejecuta parte del código del controlador de eventos. Los tiempos de inicio de la navegación suave también incluyen ese código del controlador de eventos, ya que medimos desde el tiempo de inicio de la interacción.

Mide las Métricas web esenciales por navegación suave

Para medir las Métricas web esenciales, escucha las entradas de soft-navigation y restablece las métricas cuando las recibas. El FCP se puede emitir en función de presentationTime y el LCP se puede inicializar en largestInteractionContentfulPaint. El INP y el CLS deben inicializarse en 0, como lo harían para una carga de página.

Luego, el LCP, el INP y el CLS se pueden medir y supervisar como de costumbre (con la excepción de usar interaction-contentful-paint para que el LCP proporcione las coincidencias de interactionId). interactionId y navigationId se pueden usar para nombrar las entradas a una URL como se mencionó anteriormente.

Los tiempos seguirán devolviéndose en relación con la hora de inicio de navegación "fija" original. Por lo tanto, para calcular el LCP de una navegación suave, por ejemplo, deberás tomar el tiempo de interaction-contentful-paint y restarle el tiempo de inicio de navegación suave adecuado, como se detalló anteriormente, para obtener un tiempo relativo a la navegación suave.

Algunas métricas se miden tradicionalmente a lo largo de la vida útil de la página: por ejemplo, el LCP puede cambiar hasta que se produce una interacción. El CLS y el INP se pueden actualizar hasta que se abandone la página, independientemente de las interacciones. Por lo tanto, las métricas de la navegación anterior deben finalizarse a medida que se produce cada nueva navegación suave. Esto significa que las métricas de navegación "duras" iniciales pueden finalizar antes de lo habitual cuando se miden las Métricas web esenciales con navegaciones suaves.

Del mismo modo, cuando se comiencen a medir las métricas de la nueva navegación suave de estas métricas de larga duración, las métricas deberán "restablecerse" o "reinicializarse" y tratarse como métricas nuevas, sin memoria de los valores que se establecieron para las "páginas" anteriores. Es decir, se restablece la comprensión de cuál es la pintura, la interacción con la siguiente pintura o el cambio de diseño "más grande" para permitir que se vuelva a medir desde cero.

¿Cómo se debe tratar el contenido que permanece igual entre las navegaciones?

El LCP para las navegaciones suaves (calculado a partir de interaction-contentful-paint) medirá solo las nuevas renderizaciones y solo las renderizaciones asociadas con la interacción que causó la navegación. Esto puede generar un LCP diferente, por ejemplo, desde una carga en frío de esa navegación suave a una carga suave.

Por ejemplo, toma una página que incluya una imagen de banner grande que sea el elemento LCP, pero el texto debajo de ella cambia con cada navegación suave. La carga inicial de la página marcará la imagen del banner como el elemento LCP y basará el tiempo de LCP en ella. En las navegaciones suaves posteriores, el texto que se encuentre debajo será el elemento más grande que se renderice después de la navegación suave y será el nuevo elemento LCP. Sin embargo, si la página se carga con un vínculo directo a la URL de navegación suave, la imagen del banner será una nueva pintura y, por lo tanto, será apta para considerarse como el elemento LCP.

Del mismo modo, una animación puede actualizar parte de la página de forma continua, sin relación con ninguna navegación suave que ocurra. Las nuevas renderizaciones debido a esa animación de fondo no se considerarían para el LCP de la nueva navegación suave. Sin embargo, se pueden considerar para el LCP si la página se volvió a cargar desde esta URL.

Como muestran estos ejemplos, el elemento LCP para la navegación suave se puede registrar de manera diferente según cómo se cargue la página, de la misma manera que cargar una página con un vínculo de anclaje más abajo en la página puede generar un elemento LCP diferente para las navegaciones duras.

¿Cómo se mide el TTFB?

El tiempo hasta el primer byte (TTFB) para la carga de una página convencional representa el tiempo que tardan en devolverse los primeros bytes de la solicitud original.

En el caso de una navegación suave, esta es una pregunta más difícil. ¿Deberíamos medir la primera solicitud realizada para la página nueva? ¿Qué sucede si todo el contenido ya existe en la app y no hay solicitudes adicionales? ¿Qué sucede si esa solicitud se realiza con anticipación con una recuperación previa? ¿Qué sucede si una solicitud no está relacionada con la navegación suave desde la perspectiva del usuario (por ejemplo, es una solicitud de Analytics)?

Un método más simple es registrar un TTFB de 0 para las navegaciones suaves, de manera similar a lo que recomendamos para las restauraciones de la memoria caché atrás/adelante. Este es el método que usa la biblioteca web-vitals para las navegaciones suaves y el que recomendamos para esta métrica en este momento.

¿Deberías medir las Métricas web esenciales con ambas metodologías?

Durante este experimento, se recomienda que sigas midiendo tus Métricas web esenciales de la manera actual, en función de las navegaciones de página "duras", ya que la nueva implementación puede tener problemas o cambiar antes de que se lance definitivamente. Esto también coincidirá con lo que CrUX mide por el momento (más información al respecto más adelante).

Las navegaciones suaves se deben medir además de estas para que puedas ver cómo se podrían medir en el futuro y para que tengas la oportunidad de proporcionar comentarios al equipo de Chrome sobre cómo funciona esta implementación en la práctica. Esto te ayudará a ti y al equipo de Chrome a dar forma a la API en el futuro.

En el caso del LCP, esto significa considerar solo las entradas de largest-contentful-paint para la ruta actual y las entradas de largest-contentful-paint y interaction-contentful-paint para la ruta nueva.

En el caso del CLS y el INP, esto significa medirlos en todo el ciclo de vida de la página, como se hace actualmente, y segmentar por separado la línea de tiempo por navegaciones suaves para medir valores de CLS y INP separados para la nueva.

Usa la biblioteca web-vitals para medir las Métricas web esenciales en las navegaciones suaves

La forma más sencilla de tener en cuenta todos los matices es usar la biblioteca de JavaScript web-vitals, que tiene compatibilidad experimental con la navegación suave en un soft-navs branch independiente (que también está disponible en npm y unpkg). Esto se puede medir de la siguiente manera (reemplaza doTraditionalProcessing y doSoftNavProcessing según corresponda):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

La biblioteca web-vitals también garantiza que las métricas se registren en la URL correcta como se indicó anteriormente, ya que incluyen tanto el navigationId como un navigationURL en las entradas proporcionadas a la devolución de llamada.

La biblioteca de web-vitals informa las siguientes métricas para las navegaciones suaves:

¿Estos cambios formarán parte de las mediciones de las Métricas web esenciales?

Queremos evaluar la heurística y ver si refleja con mayor precisión la experiencia del usuario antes de tomar una decisión sobre si se integrará en la iniciativa de las métricas web esenciales. El objetivo final es proporcionar un medio para medir mejor el rendimiento como experiencias de usuarios reales. Por lo tanto, sí, el objetivo es incluir estas métricas en las mediciones de Core Web Vitals que exponen todas las herramientas si este experimento resulta exitoso.

Valoramos los comentarios de los desarrolladores web sobre el experimento, la heurística utilizada y si creen que refleja con mayor precisión la experiencia. El repositorio de GitHub de navegación suave es el mejor lugar para proporcionar esos comentarios, aunque los errores individuales relacionados con la implementación de Chrome deben plantearse en el rastreador de problemas de Chrome.

¿Cómo se registrarán las navegaciones suaves en CrUX?

Aún no se determinó cómo se registrarán exactamente las navegaciones suaves en CrUX si este experimento tiene éxito. No necesariamente se tratarán de la misma manera que se tratan las navegaciones "duras" actuales.

En algunas páginas web, las navegaciones suaves son casi idénticas a las cargas de página completas en lo que respecta al usuario, y el uso de la tecnología de aplicaciones de una sola página es solo un detalle de implementación. En otros casos, pueden ser más similares a una carga parcial de contenido adicional.

Por lo tanto, es posible que decidamos registrar estas navegaciones suaves por separado en CrUX o, tal vez, ponderarlas cuando calculemos las Métricas web esenciales para una página o un grupo de páginas determinados. También es posible que podamos excluir por completo la navegación suave de carga parcial a medida que evolucione la heurística.

El equipo se concentra en la implementación heurística y técnica, lo que nos permitirá juzgar el éxito de este experimento, por lo que no se tomó ninguna decisión en estos frentes.

Comentarios

Estamos buscando activamente comentarios sobre este experimento en los siguientes lugares:

• Los comentarios sobre la API deben plantearse como problemas en GitHub.
• Si hay errores en la implementación de Chromium, se deben registrar en el sistema de seguimiento de problemas de Chrome, si aún no se encuentran entre los problemas conocidos.
• Puedes compartir comentarios generales sobre las métricas web vitales en web-vitals-feedback@googlegroups.com.

Si tienes dudas, no te preocupes demasiado. Preferimos recibir comentarios en cualquiera de los dos lugares y con gusto clasificaremos los problemas en ambos lugares y los redireccionaremos a la ubicación correcta.

Registro de cambios

Como esta API se encuentra en fase experimental, se le realizan varios cambios, más que a las APIs estables. Puedes consultar el registro de cambios de las heurísticas de navegación suave para obtener más detalles.

Conclusión

El experimento de navegación suave es un enfoque interesante sobre cómo podría evolucionar la iniciativa de Métricas web esenciales para medir un patrón común en la Web moderna que falta en nuestras métricas. Si bien este experimento aún está en sus primeras etapas y queda mucho por hacer, poner a disposición de la comunidad web en general el progreso logrado hasta el momento para que experimente con él es un paso importante. Recopilar los comentarios de este experimento es otra parte fundamental del proceso, por lo que recomendamos a quienes estén interesados en este desarrollo que aprovechen esta oportunidad para ayudar a definir la API y garantizar que represente lo que esperamos poder medir con ella.

Agradecimientos

Imagen en miniatura de Jordan Madrid en Unsplash

Este trabajo es una continuación del trabajo que comenzó Yoav Weiss cuando estaba en Google. Agradecemos a Yoav por su trabajo en esta API.