Una guía completa para la inserción del servidor HTTP/2

 

 

 

  • Patrones de diseño de interfaces inteligentes, vídeo de 10h + formación UX
  • Clase magistral de diseño para una interfaz de usuario compleja, con Vitaly Friedman

  • Índice
    1. ¿Qué es exactamente Server Push?
    2. ¿Qué problemas resuelve Server Push?
    3. Cómo utilizar la inserción del servidor
      1. Configuración del Linkencabezado en la configuración de su servidor
      2. Configuración del Linkencabezado en el código back-end
      3. Impulsar múltiples activos
    4. Cómo saber si la inserción del servidor está funcionando
    5. Medición del rendimiento de inserción del servidor
      1. Metodología de prueba
      2. Resultados de la prueba
    6. Advertencias sobre el uso de Server Push
      1. Puedes presionar demasiadas cosas
      2. Puedes enviar algo que no esté en la página
      3. Configure su servidor HTTP/2 correctamente
      4. Es posible que los envíos no se almacenen en caché
    7. Pensamientos finales
      1. Otras lecturas

    En este artículo, Jeremy Wagner le enseñará todo sobre el server push, desde cómo funciona hasta los problemas que resuelve. La inserción del servidor le permite enviar activos del sitio al usuario incluso antes de que los solicite. Es una forma elegante de lograr los beneficios de rendimiento de las prácticas de optimización HTTP/1, como la inserción en línea, pero sin los inconvenientes que conlleva esa práctica. Jeremy también le mostrará cómo usarlo, cómo saber si está funcionando y su impacto en el rendimiento. ¡Vamos a empezar!

     

    El panorama para los desarrolladores con mentalidad de rendimiento ha cambiado significativamente en el último año, siendo la aparición de HTTP/2 quizás el más significativo de todos. HTTP/2 ya no es una característica que anhelamos. ¡Ha llegado, y con él viene el servidor push!

    Además de resolver problemas comunes de rendimiento de HTTP/1 (por ejemplo, bloqueo de encabezados de línea y encabezados sin comprimir), ¡HTTP/2 también nos brinda impulso al servidor! La inserción del servidor le permite enviar activos del sitio al usuario incluso antes de que los solicite. Es una forma elegante de lograr los beneficios de rendimiento de las prácticas de optimización HTTP/1, como la inserción en línea, pero sin los inconvenientes que conlleva esa práctica.

    En este artículo, aprenderá todo sobre el server push, desde cómo funciona hasta los problemas que resuelve. También aprenderá cómo usarlo, cómo saber si está funcionando y su impacto en el rendimiento. ¡Vamos a empezar!

    ¿Qué es exactamente Server Push?

    El acceso a los sitios web siempre ha seguido un patrón de solicitud y respuesta. El usuario envía una solicitud a un servidor remoto y, con cierto retraso, el servidor responde con el contenido solicitado.

    La solicitud inicial a un servidor web suele ser para un documento HTML. En este escenario, el servidor responde con el recurso HTML solicitado. Luego, el navegador analiza el HTML, donde se descubren referencias a otros activos, como hojas de estilo, scripts e imágenes. Tras su descubrimiento, el navegador realiza solicitudes separadas para esos activos, a las que luego se responde de la misma manera.

    El problema con este mecanismo es que obliga al usuario a esperar a que el navegador descubra y recupere activos críticos hasta que se haya descargado un documento HTML. Esto retrasa el renderizado y aumenta los tiempos de carga.

    Con server push, tenemos una solución a este problema. La inserción del servidor permite al servidor "enviar" de forma preventiva los activos del sitio web al cliente sin que el usuario los haya solicitado explícitamente. Cuando se usa con cuidado, podemos enviar lo que sabemos que el usuario necesitará para la página que solicita.

    Supongamos que tiene un sitio web donde todas las páginas se basan en estilos definidos en una hoja de estilos externa denominada styles.css. Cuando el usuario solicita index.htmldesde el servidor, podemos enviarle styles.cssun mensaje justo después de comenzar a enviar la respuesta index.html.

     

    En lugar de esperar a que el servidor envíe index.htmly luego esperar a que el navegador solicite y reciba styles.css, el usuario sólo tiene que esperar a que el servidor responda con ambos index.html y styles.cssen la solicitud inicial. Esto significa que el navegador puede comenzar a mostrar la página más rápido que si tuviera que esperar.

    Como puedes imaginar, esto puede disminuir el tiempo de renderizado de una página. También resuelve algunos otros problemas, particularmente en los flujos de trabajo de desarrollo front-end.

    ¿Qué problemas resuelve Server Push?

    Si bien la reducción de los viajes de ida y vuelta al servidor para contenido crítico es uno de los problemas que resuelve el server push, no es el único. Server push actúa como una alternativa adecuada para una serie de antipatrones de optimización específicos de HTTP/1, como insertar CSS y JavaScript directamente en HTML, así como utilizar el esquema de URI de datos para incrustar datos binarios en CSS y HTML.

    Estas técnicas encontraron valor en los flujos de trabajo de optimización HTTP/1 porque disminuyen lo que llamamos el "tiempo de representación percibido" de una página, lo que significa que si bien el tiempo de carga general de una página puede no reducirse, la página parecerá cargarse más rápido durante el proceso. usuario. Después de todo, tiene sentido. Si inserta CSS en un documento HTML dentro de styleetiquetas, el navegador puede comenzar a aplicar estilos inmediatamente al HTML sin tener que esperar a recuperarlos de una fuente externa. Este concepto es válido al insertar scripts y datos binarios con el esquema de URI de datos.

    Parece una buena forma de abordar el problema, ¿verdad? Claro, para flujos de trabajo HTTP/1, donde no tienes otra opción. Sin embargo, la píldora venenosa que nos tragamos cuando hacemos esto es que el contenido insertado no se puede almacenar en caché de manera eficiente. Cuando un activo, como una hoja de estilo o un archivo JavaScript, permanece externo y modular, se puede almacenar en caché de manera mucho más eficiente. Cuando el usuario navega a una página posterior que requiere ese activo, puede extraerlo del caché, eliminando la necesidad de realizar solicitudes adicionales al servidor.

    Sin embargo, cuando incorporamos contenido, ese contenido no tiene su propio contexto de almacenamiento en caché. Su contexto de almacenamiento en caché es el mismo que el del recurso en el que está integrado. Tomemos como ejemplo un documento HTML con CSS incorporado. Si la política de almacenamiento en caché del documento HTML es obtener siempre una copia nueva del marcado del servidor, entonces el CSS insertado nunca se almacenará en caché por sí solo. Claro, el documento del que forma parte puede estar almacenado en caché, pero las páginas posteriores que contengan este CSS duplicado se descargarán repetidamente. Incluso si la política de almacenamiento en caché es más laxa, los documentos HTML suelen tener una vida útil limitada. Sin embargo, esta es una compensación que estamos dispuestos a hacer en los flujos de trabajo de optimización HTTP/1. Funciona y es bastante efectivo para quienes visitan por primera vez. Las primeras impresiones suelen ser las más importantes.

     

    Estos son los problemas que soluciona el servidor push. Cuando envía activos, obtiene los beneficios prácticos que conlleva la inserción en línea, pero también puede mantener sus activos en archivos externos que conservan su propia política de almacenamiento en caché. Sin embargo, hay una advertencia en este punto, que se trata al final de este artículo. Por ahora, sigamos.

    Ya he hablado bastante sobre por qué debería considerar usar server push, así como los problemas que soluciona tanto para el usuario como para el desarrollador. Ahora hablemos de cómo se usa.

    Cómo utilizar la inserción del servidor

    El uso del servidor push generalmente implica el uso del Linkencabezado HTTP, que adopta este formato:

    Link: /css/styles.css; rel=preload; as=style

    Tenga en cuenta que dije normalmente . Lo que ves arriba es en realidad la preloadsugerencia de recursos en acción. Esta es una optimización separada y distinta de la inserción del servidor, pero la mayoría (no todas) las implementaciones HTTP/2 enviarán un activo especificado en un Linkencabezado que contiene una preloadsugerencia de recurso. Si el servidor o el cliente optan por no aceptar el recurso enviado, el cliente aún puede iniciar una recuperación anticipada del recurso indicado.

    La as=styleparte del encabezado no es opcional. Informa al navegador del tipo de contenido del activo enviado. En este caso, utilizamos un valor de stylepara indicar que el recurso enviado es una hoja de estilo. Puede especificar otros tipos de contenido . Es importante tener en cuenta que omitir el asvalor puede provocar que el navegador descargue el recurso enviado dos veces . ¡Así que no lo olvides!

    Ahora que sabes cómo se activa un evento push, ¿cómo configuramos el Linkencabezado? Puedes hacerlo a través de dos vías:

    • la configuración de su servidor web (por ejemplo, Apache httpd.confo .htaccess);
    • una función de lenguaje de fondo (por ejemplo, headerla función de PHP).

    Configuración del Linkencabezado en la configuración de su servidor

    A continuación se muestra un ejemplo de configuración de Apache (a través httpd.confde o .htaccess) para enviar una hoja de estilo cada vez que se solicita un archivo HTML:

    FilesMatch ".html$" Header set Link "/css/styles.css; rel=preload; as=style"FilesMatch

    Aquí usamos la FilesMatchdirectiva para hacer coincidir solicitudes de archivos que terminan en .html. Cuando llega una solicitud que coincide con este criterio, agregamos un Linkencabezado a la respuesta que le indica al servidor que envíe el recurso en /css/styles.css.

    Nota al margen: el módulo HTTP/2 de Apache también puede iniciar un envío de recursos utilizando la H2PushResourcedirectiva. La documentación de esta directiva establece que este método puede iniciar envíos antes que si Linkse utilizara el método de encabezado. Dependiendo de su configuración específica, es posible que no tenga acceso a esta función. Las pruebas de rendimiento que se muestran más adelante en este artículo utilizan el Linkmétodo del encabezado.

     

    A partir de ahora, Nginx no admite la inserción del servidor HTTP/2, y hasta ahora nada en el registro de cambios del software ha indicado que se haya agregado soporte. Esto puede cambiar a medida que madure la implementación HTTP/2 de Nginx.

    Configuración del Linkencabezado en el código back-end

    Otra forma de configurar un Linkencabezado es mediante un lenguaje del lado del servidor. Esto es útil cuando no puede cambiar o anular la configuración del servidor web. Aquí hay un ejemplo de cómo usar headerla función de PHP para configurar el Linkencabezado:

    header("Link: /css/styles.css; rel=preload; as=style");

    Si su aplicación reside en un entorno de alojamiento compartido donde modificar la configuración del servidor no es una opción, entonces este método podría ser todo lo que tenga que seguir. Debería poder configurar este encabezado en cualquier idioma del lado del servidor. Sólo asegúrese de hacerlo antes de comenzar a enviar el cuerpo de la respuesta, para evitar posibles errores de tiempo de ejecución.

    Impulsar múltiples activos

    Todos nuestros ejemplos hasta ahora solo ilustran cómo impulsar un activo. ¿Qué pasa si quieres empujar a más de uno? Hacer eso tendría sentido, ¿verdad? Después de todo, la Web se compone de algo más que hojas de estilo. A continuación se explica cómo impulsar múltiples activos:

    Link: /css/styles.css; rel=preload; as=style, /js/scripts.js; rel=preload; as=script, /img/logo.png; rel=preload; as=image

    Cuando desee enviar varios recursos, simplemente separe cada directiva de envío con una coma. Debido a que las sugerencias de recursos se agregan a través de la Linketiqueta, esta sintaxis es la forma en que puede combinar otras sugerencias de recursos con sus directivas push. A continuación se muestra un ejemplo de cómo mezclar una directiva push con una preconnectsugerencia de recurso:

    Link: /css/styles.css; rel=preload; as=style, https://fonts.gstatic.com; rel=preconnect

    LinkTambién son válidos varios encabezados. A continuación se explica cómo puede configurar Apache para establecer múltiples Linkencabezados para solicitudes de documentos HTML:

    FilesMatch ".html$" Header add Link "/css/styles.css; rel=preload; as=style" Header add Link "/js/scripts.js; rel=preload; as=script"/FilesMatch

    Esta sintaxis es más conveniente que encadenar un montón de valores separados por comas y funciona igual. El único inconveniente es que no es tan compacto, pero la conveniencia vale los pocos bytes adicionales enviados por cable.

    Ahora que sabes cómo impulsar activos, veamos cómo saber si está funcionando.

    Cómo saber si la inserción del servidor está funcionando

    Entonces, agregó el Linkencabezado para indicarle al servidor que envíe algunas cosas. La pregunta que queda es, ¿cómo saber si está funcionando? Todo sobre Apple, Mac e Iphone

    Esto varía según el navegador. Las versiones recientes de Chrome revelarán un recurso enviado en la columna de iniciador de la utilidad de red en las herramientas de desarrollador.

     

    Además, si pasamos el cursor sobre el activo en la cascada de solicitudes de red, obtendremos información detallada sobre el momento del envío del activo:

    Firefox es menos obvio a la hora de identificar los activos enviados. Si un activo ha sido enviado, su estado en la utilidad de red del navegador en las herramientas de desarrollador se mostrará con un punto gris.

    Si está buscando una forma definitiva de saber si el servidor ha enviado un activo, puede usar el nghttpcliente de línea de comandos para examinar una respuesta de un servidor HTTP/2, así:

    nghttp -ans https://jeremywagner.me

    Este comando mostrará un resumen de los activos involucrados en la transacción. Los activos enviados tendrán un asterisco junto a ellos en la salida del programa, así:

    id responseEnd requestStart process code size request path 13 +50.28ms +1.07ms 49.21ms 200 3K / 2 +50.47ms * +42.10ms 8.37ms 200 2K /css/global.css 4 +50.56ms * +42.15ms 8.41ms 200 157 /css/fonts-loaded.css 6 +50.59ms * +42.16ms 8.43ms 200 279 /js/ga.js 8 +50.62ms * +42.17ms 8.44ms 200 243 /js/load-fonts.js 10 +74.29ms * +42.18ms 32.11ms 200 5K /img/global/jeremy.png 17 +87.17ms +50.65ms 36.51ms 200 668 /js/lazyload.js 15 +87.21ms +50.65ms 36.56ms 200 2K /img/global/book-1x.png 19 +87.23ms +50.65ms 36.58ms 200 138 /js/debounce.js 21 +87.25ms +50.65ms 36.60ms 200 240 /js/nav.js 23 +87.27ms +50.65ms 36.62ms 200 302 /js/attach-nav.js

    Aquí, lo he usado nghttpen mi propio sitio web , que (al menos en el momento de escribir este artículo) ofrece cinco activos. Los activos enviados están marcados con un asterisco en el lado izquierdo de la requestStartcolumna.

    Ahora que podemos identificar cuándo se envían los activos, veamos cómo la inserción del servidor afecta realmente el rendimiento de un sitio web real.

    Medición del rendimiento de inserción del servidor

    Medir el efecto de cualquier mejora del rendimiento requiere una buena herramienta de prueba. Sitespeed.io es una excelente herramienta disponible a través de npm ; automatiza las pruebas de páginas y recopila valiosas métricas de rendimiento. Una vez elegida la herramienta adecuada, repasemos rápidamente la metodología de prueba.

    Metodología de prueba

    Quería medir el impacto del server push en el rendimiento del sitio web de una manera significativa. Para que los resultados fueran significativos, necesitaba establecer puntos de comparación entre seis escenarios distintos. Estos escenarios se dividen en dos facetas: si se utiliza HTTP/2 o HTTP/1. En servidores HTTP/2, queremos medir el efecto del push del servidor en una serie de métricas. En los servidores HTTP/1, queremos ver cómo la incorporación de activos afecta el rendimiento en las mismas métricas, porque se supone que la incorporación es más o menos análoga a los beneficios que proporciona el servidor push. En concreto, estos escenarios son los siguientes:

    • HTTP/2 sin envío de servidor En este estado, el sitio web se ejecuta en el protocolo HTTP/2, pero no se envía nada en absoluto. El sitio web tiene "stock", por así decirlo.
    • HTTP/2 push solo se utiliza CSS Server push, pero solo para el CSS del sitio web. El CSS del sitio web es bastante pequeño y pesa un poco más de 2 KB con la compresión Brotli aplicada.
    • Empujando el fregadero de la cocina . Se envían todos los activos en uso en todas las páginas del sitio web. Esto incluye CSS, así como 1,4 KB de JavaScript repartidos en seis recursos y 5,9 KB de imágenes SVG repartidos en cinco recursos. Todos los tamaños de archivos citados son, nuevamente, después de que se haya aplicado la compresión Brotli.
    • HTTP/1 sin recursos incorporados El sitio web se ejecuta en HTTP/1 y no hay activos incorporados para reducir la cantidad de solicitudes o aumentar la velocidad de procesamiento.
    • Insertar solo CSS . Sólo el CSS del sitio web está incluido.
    • Revestimiento del fregadero de la cocina . Todos los recursos en uso en todas las páginas del sitio web están integrados. CSS y scripts están integrados, pero las imágenes SVG están codificadas en base64 y se incrustan directamente en el marcado. Cabe señalar que los datos codificados en base64 son aproximadamente 1,37 veces más grandes que su equivalente no codificado.

    En cada escenario, inicié las pruebas con el siguiente comando:

     

    sitespeed.io -d 1 -m 1 -n 25 -c cable -b chrome -v https://jeremywagner.me

    Si desea conocer los entresijos de lo que hace este comando, puede consultar la documentación . En pocas palabras, este comando prueba la página de inicio de mi sitio web enhttps://jeremywagner.me con las siguientes condiciones:

    • Los enlaces de la página no se rastrean. Sólo se prueba la página especificada.
    • La página se prueba 25 veces.
    • Se utiliza un perfil de limitación de red "similar a un cable". Esto se traduce en un tiempo de ida y vuelta de 28 milisegundos, una velocidad de bajada de 5.000 kilobits por segundo y una velocidad de subida de 1.000 kilobits por segundo.
    • La prueba se ejecuta utilizando Google Chrome.

    Se recopilaron y graficaron tres métricas de cada prueba:

    • Primera vez que pinto . Este es el momento en el que la página se puede ver por primera vez en el navegador. Cuando nos esforzamos por hacer que una página "se sienta" como si se cargara rápidamente, esta es la métrica que queremos reducir tanto como sea posible.
    • DOMContentTiempo de carga . Este es el momento en el que el documento HTML se carga por completo y se analiza. El código JavaScript síncrono bloqueará el analizador y hará que esta cifra aumente. El uso del asyncatributo en scriptlas etiquetas puede ayudar a evitar el bloqueo del analizador.
    • tiempo de carga de la página . Este es el tiempo que tarda la página y sus activos en cargarse por completo.

    Con los parámetros de la prueba determinados, ¡veamos los resultados!

    Resultados de la prueba

    Se realizaron pruebas en los seis escenarios especificados anteriormente y se graficaron los resultados. Comencemos viendo cómo se ve afectado el tiempo de la primera pintura en cada escenario:

    Primero hablemos un poco sobre cómo está configurado el gráfico. La parte del gráfico en azul representa el tiempo promedio de la primera pintura. La porción naranja es el percentil 90. La parte gris representa el tiempo máximo de primera pintura.

     

    Ahora hablemos de lo que vemos. Los escenarios más lentos son los sitios web controlados por HTTP/2 y HTTP/1 sin ninguna mejora. Vemos que usar server push para CSS ayuda a renderizar la página aproximadamente un 8% más rápido en promedio que si no se usa server push, e incluso aproximadamente un 5% más rápido que insertar CSS en un servidor HTTP/1.

    Sin embargo, cuando impulsamos todos los activos que podemos, el panorama cambia un poco. Los tiempos de la primera pintura aumentan ligeramente. En los flujos de trabajo HTTP/1, donde incorporamos todo lo posible, logramos un rendimiento similar al de cuando impulsamos activos, aunque un poco menos.

    El veredicto aquí es claro: con server push, podemos lograr resultados que son ligeramente mejores que los que podemos lograr en HTTP/1 con inlining. Sin embargo, cuando impulsamos o alineamos muchos activos, observamos rendimientos decrecientes.

    Vale la pena señalar que usar server push o inlining es mejor que no realizar ninguna mejora para quienes visitan el sitio por primera vez. También vale la pena señalar que estas pruebas y experimentos se ejecutan en un sitio web con activos pequeños, por lo que es posible que este caso de prueba no refleje lo que se puede lograr con su sitio web.

    Examinemos los impactos en el rendimiento de cada escenario en el tiempo de DOMContentLoaded:

    Las tendencias aquí no son muy diferentes de lo que vimos en el gráfico anterior, excepto por una desviación notable: la instancia en la que alineamos tantos recursos como sea práctico en una conexión HTTP/1 produce un tiempo de carga de contenido DOM muy bajo. Presumiblemente, esto se debe a que la integración reduce la cantidad de activos necesarios para descargar, lo que permite al analizador continuar con su trabajo sin interrupciones.

    Ahora, veamos cómo se ven afectados los tiempos de carga de la página en cada escenario:

    Las tendencias establecidas a partir de mediciones anteriores generalmente también persisten aquí. Descubrí que presionar solo el CSS generaba el mayor beneficio en el tiempo de carga. Enviar demasiados activos podría, en algunas ocasiones, hacer que el servidor web fuera un poco lento, pero aun así era mejor que no enviar nada en absoluto. En comparación con la inserción en línea, la inserción del servidor produjo mejores tiempos de carga generales que la inserción en línea.

    Antes de concluir este artículo, hablemos de algunas advertencias que debe tener en cuenta cuando se trata de servidor push.

    Advertencias sobre el uso de Server Push

    La inserción del servidor no es una panacea para los problemas de rendimiento de su sitio web. Tiene algunos inconvenientes que debes conocer.

    Puedes presionar demasiadas cosas

    En uno de los escenarios anteriores, estoy impulsando muchos activos, pero todos ellos en conjunto representan una pequeña porción de los datos generales. Enviar muchos activos muy grandes a la vez podría retrasar que su página se pinte o sea interactiva antes, porque el navegador necesita descargar no solo el HTML, sino todos los demás activos que se están enviando junto con él. Lo mejor que puede hacer es ser selectivo en lo que impulsa. Las hojas de estilo son un buen punto de partida (siempre que no sean enormes). Luego evalúe qué más tiene sentido impulsar.

     

    Puedes enviar algo que no esté en la página

    Esto no es necesariamente malo si cuenta con análisis de visitantes para respaldar esta estrategia. Un buen ejemplo de esto puede ser un formulario de registro de varias páginas, en el que envía activos a la página siguiente del proceso de registro. Sin embargo, seamos muy claros: si no sabes si debes obligar al usuario a cargar recursos de forma preventiva para una página que aún no ha visto, entonces no lo hagas . Es posible que algunos usuarios tengan planes de datos restringidos y usted podría costarles dinero real.

    Configure su servidor HTTP/2 correctamente

    Algunos servidores le ofrecen muchas opciones de configuración relacionadas con la inserción del servidor. Apache mod_http2tiene algunas opciones para configurar cómo se envían los activos. La H2PushPriorityconfiguración debería ser de particular interés, aunque en el caso de mi servidor la dejé en la configuración predeterminada. Un poco de experimentación podría generar beneficios de rendimiento adicionales. Cada servidor web tiene un conjunto completamente diferente de interruptores y diales con los que puede experimentar, así que lea el manual del suyo y descubra qué hay disponible.

    Es posible que los envíos no se almacenen en caché

    Ha habido un crujir de dientes sobre si la inserción del servidor podría afectar el rendimiento en el sentido de que a los visitantes que regresan se les pueden volver a enviar activos innecesariamente. Algunos servidores hacen todo lo posible para mitigar esto. Apache mod_http2usa la H2PushDiarySizeconfiguración para optimizar esto un poco. H2O Server tiene una función llamada inserción de servidor Cache Aware que utiliza un mecanismo de cookies para recordar los activos enviados.

    Si no utiliza H2O Server, puede lograr lo mismo en su servidor web o en el código del lado del servidor enviando únicamente recursos en ausencia de una cookie. Si está interesado en aprender cómo hacer esto, consulte una publicación que escribí al respecto en CSS-Tricks . También vale la pena mencionar que los navegadores pueden enviar un RST_STREAMmarco para indicarle a un servidor que no se necesita un activo enviado. A medida que pase el tiempo, este escenario se manejará con mucha más gracia.

    Por triste que parezca, nos acercamos al final de nuestro tiempo juntos. Concluyamos y hablemos un poco sobre lo que hemos aprendido.

    Pensamientos finales

    Si ya ha migrado su sitio web a HTTP/2, tiene pocas razones para no utilizar el servidor push. Si tiene un sitio web muy complejo con muchos activos, comience poco a poco. Una buena regla general es considerar empujar cualquier cosa con la que alguna vez te sentiste cómodo. Un buen punto de partida es impulsar el CSS de su sitio. Si te sientes más aventurero después de eso, considera impulsar otras cosas. Pruebe siempre los cambios para ver cómo afectan el rendimiento. Probablemente obtendrá algún beneficio de esta función si la modifica lo suficiente.

    Si no está utilizando un mecanismo de inserción de servidor con reconocimiento de caché como el de H2O Server, considere rastrear a sus usuarios con una cookie y solo enviarles activos en ausencia de esa cookie. Esto minimizará los envíos innecesarios a usuarios conocidos y, al mismo tiempo, mejorará el rendimiento para usuarios desconocidos. Esto no sólo es bueno para el rendimiento, sino que también muestra respeto hacia los usuarios con planes de datos restringidos.

    Todo lo que te queda ahora es probar el servidor push por ti mismo. ¡Así que salga y vea lo que esta función puede hacer por usted y sus usuarios! Si desea obtener más información sobre la inserción del servidor, consulte los siguientes recursos:

    • “ Server Push ”, “Protocolo de transferencia de hipertexto versión 2 (HTTP/2)”, Grupo de trabajo de ingeniería de Internet
    • " Modernizando nuestra entrega de mejoras progresivas ", Scott Jehl, Filament Group
    • “ Innovando con HTTP 2.0 Server Push ”, Ilya Grigorik

    Gracias a Yoav Weiss por aclarar que el asatributo es obligatorio (y no opcional como decía el artículo original), así como un par de otros problemas técnicos menores. Un agradecimiento adicional para Jake Archibald por señalar que la preloadsugerencia de recursos es una optimización distinta de la inserción del servidor.

    Este artículo trata sobre una característica HTTP/2 denominada server push. Este y muchos otros temas se tratan en el libro de Jeremy Web Performance in Action . ¡Puedes conseguirlo o cualquier otro libro de Manning Publicationssswagner con un 42% de descuento con el código de cupón !

    Otras lecturas

    • Desglosándolo en bits: cómo funcionan Internet, DNS y HTTPS
    • Cómo proteger su aplicación web con encabezados HTTP
    • Compresión de servidores de próxima generación con Brotli
    • Una mirada a la pila de servidores de WordPress moderna

    (rb, vf, al, il, mrn)Explora más en

    • Guías
    • CSS
    • javascript
    • backend
    • HTTPS





    Tal vez te puede interesar:

    1. ¿Deberían abrirse los enlaces en ventanas nuevas?
    2. 24 excelentes tutoriales de AJAX
    3. 70 técnicas nuevas y útiles de AJAX y JavaScript
    4. Más de 45 excelentes recursos y repositorios de fragmentos de código

    Una guía completa para la inserción del servidor HTTP/2

    Una guía completa para la inserción del servidor HTTP/2

    Patrones de diseño de interfaces inteligentes, vídeo de 10h + formación UX Clase magistral de diseño para una interfaz de usuario compleja, con Vitaly Fri

    programar

    es

    https://aprendeprogramando.es/static/images/programar-una-guia-completa-para-la-insercion-del-servidor-http2-913-0.jpg

    2024-05-20

     

    Una guía completa para la inserción del servidor HTTP/2
    Una guía completa para la inserción del servidor HTTP/2

    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

     

     

    Top 20