Analysis of webperf audit results

We regularly see misunderstandings following a performance report analysis produced by Google PageSpeed Insight, GtMetrix, Pingdom or Dareboost. 

These misunderstandings usually come from two points:

1. many recommendations have become obsolete for HTTP / 2 sites
2. these tools report errors related to third-party domains that are out of control of the site owner.

The transition to HTTP / 2 changes the situation.

We hosted a talk from Paris Webperf meetup dedicated to the change made by HTTP / 2. 

https://www.fasterize.com/en/blog/meetup-webperf-http2/

Dareboost summarizes  the impact of the recommendations :

• CSS Sprites, concatenation of CSS or JS files

Any front-end developer will have heard about it: grouping CSS files, JS files, or small images together can limit the number of HTTP requests and thus speed up the loading. What was beneficial in HTTP / 1 may ultimately go against a good user experience in HTTP / 2: the TCP connection is unique and multiplexed, by grouping the files, you will notably lose the benefits of priority on the different streams! 

It should be noted that the first feedback on the use of HTTP / 2 seems to show that the use of micro-files should be avoided anyway. If this is your case, partially apply the concatenation principle can remain interesting!

• Cookie-less Domains

We spoke earlier of the HTTP headers, which are repeated on each request in HTTP / 1, which can be very problematic if the site uses cookies a little bulky. A parade was to use a dedicated domain for all content that did not need the information transmitted via cookies. This simply eliminated superfluous data. With HTTP / 2, on the one hand the problem no longer exists (compressed headers) but most importantly, the hack of the cookie-less domain becomes harmful, since it unnecessarily implies the use of a new TCP connection and an   additional DNS resolution !

• Domain Sharding

Another "hack" HTTP / 1, the domain sharding is to distribute the resources of a web page on several domains, to overcome the limitation of parallelization HTTP requests of web browsers. Because this limit is associated with the domain, not the server, it can be avoided by using multiple domains. Again, this involves TCP connections and additional DNS resolutions. Again, HTTP / 2 solved the initial problem, thanks to multiplexing this time!

• Inlining CSS, JS or base64 images

Recommended for CSS fragments, Javascript or small images, inlining is another technique to reduce the number of HTTP / 1 requests. The need to use this technique is less obvious in HTTP / 2, since the impact of these requests will be less marked thanks to multiplexing. This technique retains the disadvantages already present in HTTP / 1, namely the loss of the benefits of the browser cache for the resources concerned, and we must add that this can be the opposite of the effects sought by the prioritization of multiplexing streams HTTP / 2! 

It should be noted that inlining for the purpose of optimizing the critical path can be eliminated for the use of Server Push, although it must be borne in mind that this mechanism remains relatively experimental.

• Parallelize downloads across hostnames :

This optimization is not applied by the engine in HTTP / 2. The indicator is no longer to be taken into account in this case.