dcsimg

Best Practices for HTTP1.1 Becoming Bad Practices for HTTP/2

  • Best Practices for HTTP1.1 Becoming Bad Practices for HTTP/2-

    Resource In-Lining

    Another best practice that was commonly used for HTTP 1.1 was in-lining of objects (like CSSs and Java Scripts) into the HTML code, again, reducing the number of resources and thus requests that need to be separately fetched per page. When using in-lining, objects cannot be stored in the browser cache, which means their payload has to be sent over and over again, therefore hurting performance.

    With HTTP/2, this practice should be avoided. Since HTTP/2 is much more efficient with its ability to multiplex transactions over a single TCP connection and compress their headers, sending each resource separately increases the caching efficiency and the overall performance of a web application.

1 | 2 | 3 | 4 | 5 | 6 | 7

Best Practices for HTTP1.1 Becoming Bad Practices for HTTP/2

  • 1 | 2 | 3 | 4 | 5 | 6 | 7
  • Best Practices for HTTP1.1 Becoming Bad Practices for HTTP/2-4

    Resource In-Lining

    Another best practice that was commonly used for HTTP 1.1 was in-lining of objects (like CSSs and Java Scripts) into the HTML code, again, reducing the number of resources and thus requests that need to be separately fetched per page. When using in-lining, objects cannot be stored in the browser cache, which means their payload has to be sent over and over again, therefore hurting performance.

    With HTTP/2, this practice should be avoided. Since HTTP/2 is much more efficient with its ability to multiplex transactions over a single TCP connection and compress their headers, sending each resource separately increases the caching efficiency and the overall performance of a web application.

The Internet has evolved significantly since HTTP 1.1 was introduced 17 years ago. During this evolution, we've seen many enhancements to improve a user's online experience, such as the development of rich content. However, delivering these improvements came at one particular cost: performance. These evolving performance challenges were something that HTTP 1.1 was not designed to handle.

In February 2015, the Internet Engineering Task Force (IETF), an international community of network designers, operators, vendors and researchers concerned with the evolution of Internet architecture, released a new HTTP/2 version to address those challenges and adapt to the progression that Internet content has undergone.

As HTTP/2 took a long time to arrive, many interim best practices were developed to bypass the performance bottlenecks of HTTP 1.1. However, we learned that many of those HTTP 1.1 performance-enhancing practices would actually contribute to slowing web application delivery rather than accelerating it when using the new HTTP/2 protocol. In this slideshow, Radware's Yaron Azerual takes a look at a few examples organizations should consider.