Impact of HTTP /1 and HTTP /2 on front-end performance optimization policies

Http1.x problem: queue head blocking, uncompressed header

1. Queue-first blocking: It is generally impossible to process more than six requests in parallel at the same time. For example, new requests cannot be downloaded until all six requests are processed

Current solution: merge resources, bundle files (Sprite chart), reduce requests. Domain name sharding (distributing requests across domains to bypass maximum restrictions)

This is an anti-pattern, with disadvantages: bundle content, as soon as part of the change, the entire cache is useless, must be downloaded

2. Uncompressed head

   Some cookie caching sessions, for example, are really long. And then you have a lot of resources like 60. For each of these 60 requests, the cookie should be repeated, and the response header should also be repeated. Comparing wasted bandwidth

Http2

(1) You don’t need to bundle resources.

(2) There is no need to inline resources (which will break the cache, and the key CSS can be pushed by the server), keeping the granularity of resources matching the workflow.

1. Resolve queue header blocking: multiple requests can be processed in parallel on a single connection without restriction

   1. The principle is to use stream: a two-way communication channel between the server and the client. A single flow consists of a pair of requests and responses. Streams are encapsulated by connections, so you can download multiple resources in parallel on the same connection by using multiple streams

2. Header compression: The HPACK algorithm compresses headers and creates a table to store duplicate headers to remove redundant headers

3. Server push

• When the server responds with the HTML content, the two resources are pushed to the client simultaneously (multiple resources can be pushed), and the effect is inline, reducing TTFP time. You can also take advantage of caching.

Question 1: How can the server not push the cached resource?

• For example, if serverPush=1, the user will not push the cookie. SetCookie not written to push at the same time

Question 2: How to make server push take effect immediately if resources change?

• At this time, you can not arbitrarily set the cookie serverPush field, serverPush can record the file name of the cache, and then on the server side can compare the contents of serverPush and the file name to be pushed. If not, the resource has changed, and push directly. If so, do not push

Compatible with HTTP 1 and 2

If you have a large user base with a large number of browsers that do not support HTTP /2, you may want to be compatible with BOTH HTTP 1 and HTTP 2

Reference scheme (PHP) :

1. $_server.server_protocol $_server.SERVER_PROTOCOL $_server.
2. On the front end, different configuration files are packaged once and each generates a directory with its own index. HTML entry

(Original collation, there are questions or errors can leave a message. If it works, thank you.

Part reference: Web Performance In Action by Jeremy Wagner

Performance optimization collection quick entry:

• How to determine the best caching strategy for front-end resources?
  • Start of browser Cache- > cache-control
  • Browser caching mechanisms (combined with response headers)
  • Impact of HTTP /1 and HTTP /2 on front-end performance optimization policies
• The relationship between <link> and <script> and DOM parsing rendering
  • Introduction to the browser multi-process architecture
• Understand Web performance concepts and common analysis tools
  • Web performance analysis tool PageSpeed Insights and Lighthouse Use tutorial
• Web performance – White screen time detail and optimization
  • Web performance -HTML and CSS optimization
  • Web performance – Image optimization
  • Web performance – Font optimization
  • Web performance-JS optimization
  • Web performance – Optimizing DOM operations (rearrange redraw)
  • Description and optimization of the basic principles of TCP transmission