Repensar la sincronización del servidor como una herramienta de monitoreo crítica

 

 

 

  • Implemente rápidamente. Implementar inteligentemente
  • Clase magistral de diseño para una interfaz de usuario compleja, con Vitaly Friedman

  • Índice
    1. ConfiguraciónServer-Timing
    2. ConsumidorServer-Timing
    3. No es sólo cuestión de tiempo
    4. No se requieren referencias
    5. Solución 1: inspeccionar imágenes y otras respuestas de activos
    6. Solución 2: inspeccionar los recursos que regresan antes de que se ejecute JS
    7. Solución 3: inspeccionar el documento HTML
    8. Combinando Server-Timing con Service Workers

    ¿Qué hace que el encabezado infrautilizado sea Server-Timingexcepcionalmente poderoso entre todos los demás encabezados de respuesta? Reconsideraremos la expectativa de usarlo exclusivamente para cronometrar y veremos soluciones rápidas para desafíos de monitoreo difíciles de resolver.

     

    En el mundo de los encabezados HTTP, hay un encabezado que creo que merece más tiempo de emisión y es el Server-Timingencabezado . Para mí, es imprescindible en cualquier proyecto en el que se instrumente el monitoreo de usuarios reales (RUM). Para mi sorpresa, las conversaciones sobre monitoreo del rendimiento web rara vez surgen Server-Timingo cubren una comprensión muy superficial de su aplicación, a pesar de que lleva muchos años fuera de uso.

    Parte de esto se debe a la limitación percibida de que es exclusivamente para rastrear el tiempo en el servidor: ¡puede proporcionar mucho más valor! Repensemos cómo podemos aprovechar este encabezado. En este artículo, profundizaremos para mostrar cómo Server-Timinglos encabezados son tan excepcionalmente poderosos, mostraremos algunos ejemplos prácticos resolviendo problemas de monitoreo desafiantes con este encabezado y provocaremos algo de inspiración creativa al combinar esta técnica con trabajadores de servicios.

    Server-Timinges singularmente poderoso, porque es el único encabezado de respuesta HTTP que admite la configuración de valores de formato libre para un recurso específico y los hace accesibles desde una API del navegador JavaScript separada de las referencias de Solicitud/Respuesta. Esto permite que las solicitudes de recursos, incluido el propio documento HTML, se enriquezcan con datos durante su ciclo de vida, ¡y esa información se puede inspeccionar para medir los atributos de ese recurso!

    El único otro encabezado que se acerca a esta capacidad son los encabezados HTTP Set-Cookie/ Cookie. A diferencia de Cookielos encabezados, Server-Timingsolo se Cookiesenvían en la respuesta de un recurso específico las solicitudes y respuestas de todos los recursos una vez configurados y no vencidos. Es preferible tener estos datos vinculados a una única respuesta de recurso, ya que evita que los datos efímeros sobre todas las respuestas se vuelvan ambiguos y contribuye a una creciente colección de cookies enviadas para los recursos restantes durante la carga de una página.

    ConfiguraciónServer-Timing

    Este encabezado se puede configurar en la respuesta de cualquier recurso de red, como XHR, recuperación, imágenes, HTML, hojas de estilo, etc. Cualquier servidor o proxy puede agregar este encabezado a la solicitud para proporcionar datos inspeccionables. El encabezado se construye mediante un nombre con una descripción opcional y/o un valor de métrica. El único campo obligatorio es el nombre. Además, puede haber muchos Server-Timingencabezados establecidos en la misma respuesta que se combinarían y separarían mediante una coma.

    Algunos ejemplos simples:

    Server-Timing: cdn_process;desc=”cach_hit";dur=123Server-Timing: cdn_process;desc=”cach_hit", server_process; dur=42;Server-Timing: cdn_cache_hitServer-Timing: cdn_cache_hit; dur=123

    Nota importante : los recursos de origen cruzado Server-Timingy otros valores de tiempo potencialmente sensibles no están expuestos a los consumidores. Para permitir estas funciones, también necesitaremos el Timing-Allow-Originencabezado que incluya nuestro origen o el *valor.

    Para este artículo, eso es todo lo que necesitaremos para empezar a exponer el valor y dejar otros artículos más específicos para profundizar. Documentos de MDN .

    ConsumidorServer-Timing

    Los navegadores web exponen una API de línea de tiempo de rendimiento global para inspeccionar detalles sobre métricas/eventos específicos que han ocurrido durante el ciclo de vida de la página. Desde esta API podemos acceder a extensiones API de rendimiento integradas que exponen los tiempos en formato PerformanceEntries.

    Hay varios subtipos de entrada diferentes pero, para el alcance de este artículo, nos ocuparemos de los subtipos PerformanceResourceTimingy PerformanceNavigationTiming. Estos subtipos son actualmente los únicos subtipos relacionados con las solicitudes de red y, por lo tanto, exponen la Server-Timinginformación.

    Para el documento HTML de nivel superior, se recupera durante la navegación del usuario, pero sigue siendo una solicitud de recurso. Entonces, en lugar de tener diferentes PerformanceEntriesaspectos de navegación y recursos, proporciona PerformanceNavigationTimingdatos de carga de recursos, así como datos adicionales específicos de la navegación. Debido a que estamos analizando solo los datos de carga de recursos, nos referiremos exclusivamente a las solicitudes (documentos de navegación o de otro tipo) simplemente como recursos.

    Para consultar entradas de rendimiento, tenemos 3 API a las que podemos llamar: performance.getEntries(), performance.getEntriesByType(), performance.getEntriesByName(). Cada uno devolverá una serie de entradas de rendimiento con una especificidad cada vez mayor.

    const navResources = performance.getEntriesByType('navigation');const allOtherResources = performance.getEntriesByType('resource');

    Finalmente, cada uno de estos recursos tendrá un serverTimingcampo que es una matriz de objetos mapeados a partir de la información proporcionada en el Server-Timingencabezado, donde PerformanceEntryServerTimingse admite (consulte las consideraciones a continuación). La forma de los objetos en esta matriz está definida por la PerformanceEntryServerTiminginterfaz que esencialmente asigna las respectivas Server-Timingopciones de métricas del encabezado: name, descriptiony duration.

    Veamos esto en un ejemplo completo.

    Se realizó una solicitud a nuestro punto final de datos y entre los encabezados, enviamos lo siguiente:

    Server-Timing: lookup_time; dur=42, db_cache; desc=”hit”;

    En el lado del cliente, supongamos que este es nuestro único recurso cargado en esta página:

    const dataEndpointEntry = performance.getEntriesByName('resource')[0];console.log( dataEndpointEntry.serverTiming );// outputs:// [// { name: “lookup_time”, description: undefined, duration: 42 },// { name: “db_cache”, description:”hit”, duration: 0.0 },// ]

    Esto cubre las API fundamentales utilizadas para acceder a las entradas de recursos y la información proporcionada desde un Server-Timingencabezado. Para obtener enlaces a más detalles sobre estas API, consulte la sección de recursos en la parte inferior.

     

    Ahora que tenemos los fundamentos de cómo configurar y usar esta combinación de encabezado/API, profundicemos en las cosas divertidas.

    No es sólo cuestión de tiempo

    De mis conversaciones y trabajo con otros desarrolladores, el nombre "Server-Timing" impresiona una fuerte conexión de que se trata de una herramienta utilizada para rastrear períodos de tiempo o un detalle sobre un período de tiempo exclusivamente. Esto está totalmente justificado por el nombre y la intención de la función. Sin embargo, la especificación de este encabezado es muy flexible; permitiendo valores y expresando información que no podría tener nada que ver con el tiempo o el desempeño de ninguna manera. Incluso el durationcampo no tiene una unidad de medida predefinida; puedes poner cualquier número (doble) en ese campo. Al dar un paso atrás y darnos cuenta de que los campos disponibles no tienen vínculos especiales con tipos particulares de datos, podemos ver que esta técnica también es un mecanismo de entrega eficaz para cualquier dato arbitrario que permite muchas posibilidades interesantes.

    Ejemplos de información no temporal que podría enviar: código de estado de respuesta HTTP, regiones, identificadores de solicitud, etc.: cualquier dato de formato libre que se adapte a sus necesidades. En algunos casos, es posible que enviemos información redundante que podría estar ya en otros encabezados, pero está bien. Como veremos, a menudo no es posible acceder a otros encabezados de recursos y, si tiene valor de monitoreo, entonces está bien que sea redundante.

    No se requieren referencias

    Debido al diseño de las API de los navegadores web, actualmente no existen mecanismos para consultar solicitudes y sus respuestas relativas a posteriori. Esto es importante debido a la necesidad de gestionar la memoria. Para leer información sobre una solicitud o su respectiva respuesta, tenemos que tener una referencia directa a estos objetos. Todo el software de monitoreo del rendimiento web con el que trabajamos proporciona clientes RUM que colocan capas adicionales de parches de mono en la página para mantener el acceso directo a una solicitud que se realiza o a la respuesta que regresa. Así es como ofrecen monitoreo directo de todas las solicitudes realizadas sin que tengamos que cambiar nuestro código para monitorear una solicitud. Esta es también la razón por la que estos clientes requieren que antepongamos al cliente a cualquier solicitud que queramos monitorear. Las complejidades de parchear todas las API de red y sus funcionalidades vinculadas pueden volverse muy complejas muy rápidamente. Si hubiera un mecanismo de fácil acceso para obtener información relevante sobre recursos/solicitudes sobre una solicitud, ciertamente preferiríamos hacerlo en el lado del monitoreo.

    Para hacer las cosas más difíciles, este patrón de parcheo de monos solo funciona para recursos donde se usa JavaScript directamente para iniciar la red. Para imágenes, hojas de estilo, archivos JS, documentos HTML, etc., los métodos para monitorear los detalles de la solicitud/respuesta son muy limitados, ya que generalmente no hay una referencia directa disponible.

     

    Aquí es donde la API Performance Timeline ofrece un gran valor. Como vimos anteriormente, es literalmente una lista de solicitudes realizadas y algunos datos sobre cada una de ellas respectivamente. Los datos para cada entrada de rendimiento son mínimos y se limitan casi por completo a información de tiempo y algunos campos que, dependiendo de su valor, afectarían la forma en que se mide el rendimiento de un recurso en relación con otros recursos. Entre los campos de cronometraje tenemos acceso directo a los serverTimingdatos.

    Al juntar todas las piezas, los recursos pueden tener Server-Timingencabezados en sus respuestas de red que contienen datos arbitrarios. Luego, esos recursos se pueden consultar fácilmente y Server-Timingse puede acceder a los datos sin una referencia directa a la solicitud/respuesta en sí. Con esto, no importa si puede acceder/administrar referencias de un recurso, todos los recursos se pueden enriquecer con datos arbitrarios accesibles desde una API de navegador web fácil de usar. ¡Esa es una capacidad única y poderosa!

    A continuación, apliquemos este patrón a algunos desafíos tradicionalmente difíciles de medir.

    Solución 1: inspeccionar imágenes y otras respuestas de activos

    Las imágenes, hojas de estilo, archivos JavaScript, etc. normalmente no se crean utilizando referencias directas a las API de red con información sobre esas solicitudes. Por ejemplo, casi siempre activamos la descarga de imágenes colocando un imgelemento en nuestro HTML. Existen técnicas para cargar estos activos que requieren el uso de JavaScript fetch/ xhrAPI para extraer los datos e insertarlos directamente en una referencia de activos. Si bien esa técnica alternativa los hace más fáciles de monitorear, en la mayoría de los casos es catastrófica para el rendimiento. El desafío es ¿cómo inspeccionamos estos recursos sin tener referencias API de red directas?

    Para vincular esto con casos de uso del mundo real, es importante preguntarse por qué querríamos inspeccionar y capturar información de respuesta sobre estos recursos. Aquí hay algunas razones:

    • Es posible que queramos capturar de forma proactiva detalles como códigos de estado de nuestros recursos, para poder clasificar cualquier cambio.
      Por ejemplo, las imágenes faltantes (404) probablemente sean problemas y tipos de trabajo totalmente diferentes a lidiar con imágenes que devuelven errores del servidor (500).
    • Agregar monitoreo a partes de nuestra pila que no controlamos.
      Por lo general, los equipos descargan este tipo de activos en una CDN para almacenarlos y entregarlos a los usuarios. Si tienen problemas, ¿con qué rapidez podrá el equipo detectar el problema?
    • Las variaciones de recursos en tiempo de ejecución o bajo demanda se han convertido en técnicas más comunes.
      Por ejemplo, el cambio de tamaño de la imagen, el relleno automático de secuencias de comandos en la CDN, etc., estos sistemas pueden tener muchas limitaciones y razones por las que es posible que no puedan crear o entregar una variación. Si espera que el 100% de los usuarios recupere un tipo particular de variación de activo, es valioso poder confirmarlo.
      Esto surgió en una empresa anterior en la que trabajé donde se utilizaba el cambio de tamaño de imágenes bajo demanda para las imágenes en miniatura. Debido a las limitaciones del proveedor, un número significativo de usuarios tendría peores experiencias debido a la carga de imágenes en tamaño completo donde se supone que deben aparecer las miniaturas. Entonces, mientras pensábamos que 99% de los usuarios obtendrían imágenes óptimas, 30% tendría problemas de rendimiento porque las imágenes no cambiaban de tamaño.

    Ahora que entendemos qué podría motivarnos a inspeccionar estos recursos, veamos cómo Server-Timingse puede aprovechar para la inspección. Korean Beauty

     

    Imagen HTML:

    img src="/user-rsrc/12345?resize=trueheight=80width=80format=webp" alt="..."/

    Encabezados de respuesta de imagen:

    Status: 200…Server-Timing: status_code; dur=200;, resizing; desc=”failed”; dur=1200; req_id; desc=”zyx4321”

    Inspeccionando la información de respuesta de la imagen:

    const imgPerfEntry = performance.getEntriesByName('/user-rsrc/12345?resize=trueheight=80width=80format=webp')[0];// filter/capture entry data as neededconsole.log(imgPerfEntry.serverTiming);// outputs:// [// { name: “status_code”, description: undefined, duration: 200 },// { name: “resizing”, description:”failed”, duration: 1200 },// { name: “req_id”, description:”zyx4321”, duration: 0.0 },// ]

    Esta métrica fue muy valiosa porque, a pesar de devolver respuestas "felices" (200), nuestras imágenes no cambiaron de tamaño y potencialmente no se convirtieron al formato correcto, etc. Junto con el resto de la información de rendimiento en la entrada, como los tiempos de descarga, vemos el el estado se entregó 200(sin activar nuestros controladores de errores en el elemento), el cambio de tamaño falló después de gastar 1.2sen intentar cambiar el tamaño y tenemos una identificación de solicitud que podemos usar para depurar esto en nuestras otras herramientas. Al enviar estos datos a nuestro proveedor de RUM, podemos agregar y monitorear de manera proactiva la frecuencia con la que ocurren estas condiciones.

    Solución 2: inspeccionar los recursos que regresan antes de que se ejecute JS

    El código utilizado para monitorear recursos (búsqueda, XHR, imágenes, hojas de estilo, scripts, HTML, etc.) requiere código JavaScript para agregar y luego enviar la información a algún lugar. Esto casi siempre significa que existe la expectativa de que el código de monitoreo se ejecute antes que los recursos que se están monitoreando. El ejemplo presentado anteriormente del parche básico de mono utilizado para monitorear automáticamente las solicitudes de recuperación es un buen ejemplo de esto. Ese código debe ejecutarse antes de cualquier solicitud de recuperación que deba monitorearse. Sin embargo, hay muchos casos, desde el rendimiento hasta las limitaciones técnicas, en los que es posible que no podamos o simplemente no debamos cambiar el orden en el que se solicita un recurso para facilitar su seguimiento.

     

    Otra técnica de monitoreo muy común es colocar detectores de eventos en la página para capturar eventos que puedan tener valor de monitoreo. Esto generalmente viene en forma de onloadcontroladores onerrorde elementos o en un uso addEventListenermás abstracto. Esta técnica requiere que JS se haya configurado antes de que se active el evento o antes de que se conecte el oyente. Por lo tanto, este enfoque todavía conlleva la característica de solo monitorear eventos en el futuro, después de que se ejecute el JS de monitoreo, por lo que requiere que el JS se ejecute antes que los recursos que requieren medición.

    Al asignar esto a casos de uso del mundo real, los sitios de comercio electrónico ponen un gran énfasis en la representación de contenido "en la mitad superior de la página" muy rápidamente, por lo general posponiendo JS tanto como sea posible. Dicho esto, puede haber recursos que sean impactantes para medir, como la entrega exitosa de la imagen del producto. En otras situaciones, también podríamos decidir que la biblioteca de monitoreo en sí no debería estar en la ruta crítica debido al peso de la página. ¿Cuáles son las opciones para inspeccionar estas solicitudes retroactivamente?

    ¡La técnica es la misma que la Solución n.° 1! Esto es posible porque los navegadores mantienen automáticamente un búfer de todas las entradas de rendimiento (sujeto al límite de tamaño del búfer que se puede cambiar). Esto nos permite posponer JS hasta más adelante en el ciclo de carga de la página sin necesidad de agregar oyentes antes del recurso.

    En lugar de repetir el ejemplo de la Solución n.° 1, veamos cómo se ve la inspección retroactiva y futura de las entradas de desempeño para mostrar la diferencia de dónde se pueden aprovechar. Tenga en cuenta que, mientras inspeccionamos imágenes en estos ejemplos, podemos hacerlo para cualquier tipo de recurso.

    Al configurar el contexto para este código, nuestra necesidad es asegurarnos de que las imágenes de nuestros productos se entreguen correctamente. Supongamos que todas las imágenes del sitio web devuelven esta Server-Timingestructura de encabezado. Algunas de nuestras imágenes importantes pueden aparecer antes de nuestro script de monitoreo y, a medida que el usuario navega, se seguirán cargando más. ¿Cómo manejamos ambos?

    Encabezados de respuesta de imagen:

    Status: 200…Server-Timing: status_code; dur=200;, resizing; desc="success"; dur=30; req_id; desc="randomId"

    Nuestra lógica de seguimiento. Esperamos que esto se ejecute después del contenido de la ruta crítica de la página.

    Inspeccionando la información de respuesta de la imagen:

    function monitorImages(perfEntries){ perfEntries.forEach((perfEntry)={ // monitoring for the performance entries console.log(perfEntry.serverTiming);})}const alreadyLoadedImageEntries = performance.getEntriesByType('resource').filter(({ initiatorType })= initiatorType === 'img');monitorImages( alreadyLoadedImageEntries );const imgObserver = new PerformanceObserver(function(entriesList) {const newlyLoadedImageEntries = entriesList.getEntriesByType('resource').filter(({ initiatorType })= initiatorType === 'img'); monitorImages( newlyLoadedImageEntries );});imgObserver.observe({entryTypes: ["resource"]});

    A pesar de posponer nuestro script de monitoreo hasta que salió de la ruta crítica, estamos capturando los datos de todas las imágenes que se cargaron antes de nuestro script y continuaremos monitoreándolas a medida que el usuario continúe usando el sitio.

     

    Solución 3: inspeccionar el documento HTML

    El último ejemplo de solución que veremos está relacionado con el recurso definitivo "antes de que JS pueda ejecutarse": el documento HTML en sí. Si nuestras soluciones de monitoreo se cargan como JS a través de HTML, ¿cómo podemos monitorear la entrega del documento HTML?

    Existe cierta prioridad en el seguimiento de la entrega de documentos HTML. Para monitorear los datos de respuesta, la configuración más común es utilizar registros/métricas/seguimientos del servidor para capturar esta información. Esa es una buena solución, pero dependiendo de las herramientas, los datos pueden estar desacoplados de los datos de RUM, lo que hace que necesitemos múltiples herramientas para inspeccionar nuestras experiencias de usuario. Además, esta práctica también podría omitir metadatos (identificadores de instancia de página, por ejemplo) que nos permiten agregar y correlacionar información para una carga de página determinada; por ejemplo, la correlación de solicitudes asíncronas falla cuando el documento devuelve ciertos códigos de respuesta del documento.

    Un patrón común para realizar este trabajo es colocar el contenido dentro del propio contenido HTML. Esto debe incluirse en el contenido HTML, porque la lógica de monitoreo basada en JS no tiene acceso a los encabezados de solicitud HTML anteriores. Esto convierte nuestro documento HTML en un contenido de documento dinámico. Esto puede estar bien para nuestras necesidades y nos permite tomar esa información y proporcionarla a nuestras herramientas RUM. Sin embargo, esto podría convertirse en un desafío si nuestro sistema para la entrega de HTML está fuera de nuestro control, o si el sistema tiene algunas suposiciones sobre cómo debe funcionar la entrega de HTML. Ejemplos de esto podrían ser esperar que el HTML sea completamente estático, de modo que podamos almacenarlo en caché en sentido descendente de alguna manera determinista: es mucho más probable que los cuerpos HTML "parcialmente dinámicos" sean manejados incorrectamente por la lógica de almacenamiento en caché.

    Dentro del proceso de entrega de HTML, también podría haber datos adicionales que queramos comprender, como qué centros de datos procesaron la solicitud a lo largo de la cadena. Es posible que tengamos un controlador de borde CDN que represente una solicitud desde un origen. En este caso, no podemos esperar que cada capa pueda/deba procesar e inyectar contenido HTML. ¿ Cómo podrían Server-Timingayudarnos los encabezados aquí?

    Basándonos en los conceptos de la Solución n.° 1 y la Solución n.° 2, aquí se explica cómo podemos capturar datos valiosos sobre el documento HTML en sí. Tenga en cuenta que cualquier parte de la pila puede agregar un Server-Timingencabezado a la respuesta y se unirá en el valor del encabezado final.

    Supongamos que tenemos un controlador de borde CDN y un origen que puede procesar el documento:

     

    CDN agregó encabezados de respuesta:

    Status: 200…Server-Timing: cdn_status_code; dur=200;, cdn_cache; desc=”expired”; dur=15; cdn_datacenter; desc=”ATL”; cdn_req_id; desc=”zyx321abc789”; cdn_time; dur=120;

    Origin agregó encabezados de respuesta:

    Status: 200…Server-Timing: origin_status_code; dur=200;, origin_time; dur=30; origin_region; desc=”us-west”; origin_req_id; desc="qwerty321ytrewq789";

    Inspeccionando la información de respuesta HTML:

    // as mentioned earlier, the HTML document is a 'navigation' type of Performance Entry// that has a superset of information related to the resource and the navigation-specific infoconst htmlPerfEntry = performance.getEntriesByType('navigation')[0];// filter/capture entry data as neededconsole.log(htmlPerfEntry.serverTiming);// outputs:// [// { name: “cdn_status_code”, description: undefined, duration: 200 },// { name: “cdn_cache”, description:”expired”, duration: 0.0},// { name: “cdn_datacenter”, description:”ATL”, duration: 0.0 },// { name: “cdn_req_id”, description:”zyx321abc789”, duration: 0.0 },// { name: “cdn_time”, description: undefined, duration: 120 },// { name: “origin_status_code”, description: undefined, duration: 200 },// { name: “origin_time”, description: undefined, duration: 30 },// { name: “origin_region”, description:”us-west”, duration: 0.0 },// { name: “origin_req_id”, description:”qwerty321ytrewq789”, duration: 0.0 },// ]

    A partir de esta información, nuestro JavaScript de monitoreo (que podría haberse cargado mucho más tarde) puede agregar dónde ocurrió el procesamiento HTML, códigos de estado de los diferentes servidores (que pueden diferir por razones legítimas o errores) y solicitar identificadores si es necesario correlacionarlos. esto con los registros del servidor. También sabe cuánto tiempo se tomó en el "servidor" a través de la cdn_timeduración; el tiempo de "servidor" es el tiempo total a partir del primer servidor/proxy no usuario que proporcionamos. Utilizando esa cdn_timeduración, el valor HTML de tiempo hasta el primer byte ya accesible y la origin_timeduración, podemos determinar las secciones de latencia con mayor precisión, como la latencia del usuario, la cdnlatencia al origen, etc. Esto es increíblemente poderoso para optimizar una etapa tan crítica. punto de entrega y protegiéndolo de la regresión.

    Combinando Server-Timing con Service Workers

    Los trabajadores de servicio son scripts que el sitio web inicializa para ubicarse entre el sitio web, el navegador y la red (cuando esté disponible). Cuando actúan como proxy, se pueden utilizar para leer y modificar las solicitudes provenientes y las respuestas que regresan al sitio web. Dado que los trabajadores de servicios tienen tantas funciones, no intentaremos cubrirlos en profundidad en este artículo; una simple búsqueda en la web arrojará una montaña de información sobre sus capacidades. En este artículo, nos centraremos en la capacidad de proxy de un trabajador de servicio: su capacidad para procesar solicitudes/respuestas.

    La clave para combinar estas herramientas es saber que el Server-Timingencabezado y su respectivo PerformanceEntryse calculan después de que se realiza el proxy del trabajador del servicio. Esto nos permite utilizar los trabajadores del servicio para agregar Server-Timingencabezados a las respuestas que pueden proporcionar información valiosa sobre la solicitud en sí.

     

    ¿Qué tipo de información podríamos querer capturar dentro del trabajador del servicio? Como se mencionó anteriormente, los trabajadores de servicios tienen muchas capacidades y cualquiera de esas acciones podría producir algo valioso que capturar. Aquí hay algunos que me vienen a la mente:

    • ¿Esta solicitud se atiende desde la memoria caché del trabajador del servicio?
    • ¿Esto lo realiza el trabajador del servicio mientras está fuera de línea?
    • ¿Qué estrategia de trabajador de servicio se está utilizando para este tipo de solicitud?
    • ¿Qué versión del trabajador de servicio se está utilizando?
      Esto es útil para verificar nuestras suposiciones sobre la invalidación del trabajador de servicio.
    • Tome valores de otros encabezados y colóquelos en un Server-Timingencabezado para su agregación posterior.
      Es valioso cuando no tenemos la opción de cambiar los encabezados de la solicitud pero nos gustaría inspeccionarlos en RUM; como suele ser el caso con los proveedores de CDN.
    • ¿Cuánto tiempo ha estado un recurso en la caché del trabajador del servicio?

    Los trabajadores del servicio deben inicializarse en el sitio web, lo cual es un proceso asincrónico en sí mismo. Además, los trabajadores del servicio solo procesan solicitudes dentro del alcance definido. Como tal, incluso la pregunta básica de "¿esta solicitud es procesada por el trabajador del servicio?" puede generar conversaciones interesantes sobre cuánto nos apoyamos en sus capacidades para generar grandes experiencias.

    Profundicemos en cómo podría verse esto en el código.

    Lógica JS básica utilizada en el sitio para inicializar el trabajador del servicio:

    if ('serviceWorker' in navigator) {navigator.serviceWorker.register('/service-worker.js').then(function (registration) {registration.update(); // immediately start using this sw });}

    Dentro de /service-worker.js, proxy de solicitud/respuesta básico:

    const CACHE_NAME = 'sw-cached-files-v1';self.addEventListener('fetch', function (event) { event.respondWith( // check to see if this request is cached caches.match(event.request) .then(function (response) { // Cache hit - return response if (response) { const updatedHeaders = new Headers(response.headers); updatedHeaders.append('Server-Timing', 'sw_cache; desc="hit";'); const updatedResponse = new Response(respo 




    Tal vez te puede interesar:

    1. 50 herramientas útiles de JavaScript
    2. 50 nuevas herramientas de JavaScript que mejorarán su flujo de trabajo
    3. Herramientas, bibliotecas y complementos útiles de JavaScript y jQuery
    4. Herramientas útiles de HTML, CSS y JavaScript que hacen prácticamente de todo

    Repensar la sincronización del servidor como una herramienta de monitoreo crítica

    Repensar la sincronización del servidor como una herramienta de monitoreo crítica

    ConfiguraciónServer-TimingConsumidorServer-TimingNo es sólo cuestión de tiempoNo se requieren referenciasSolución 1: inspeccionar imágenes y otras respues

    programar

    es

    https://pseint.es/static/images/programar-repensar-la-sincronizacion-del-servidor-como-una-herramienta-de-monitoreo-critica-1142-0.jpg

    2024-06-17

     

    Repensar la sincronización del servidor como una herramienta de monitoreo crítica
    Repensar la sincronización del servidor como una herramienta de monitoreo crítica

    Si crees que alguno de los contenidos (texto, imagenes o multimedia) en esta página infringe tus derechos relativos a propiedad intelectual, marcas registradas o cualquier otro de tus derechos, por favor ponte en contacto con nosotros en el mail [email protected] y retiraremos este contenido inmediatamente

     

     

    Update cookies preferences