Page History
Observations with Blueriq 10.5
HTTP 1.1 with disabled cache | HTTP 1.1 with cache | HTTP 2.0 (with TLS) and cache disabled | HTTP 2.0 (with TLS) with cache | |
---|---|---|---|---|
Requests | 38 | 38 | 38 | 38 |
Transferred | 1.4 MB | 16.3 KB | 1.4 MB | 293 KB |
Finish | 1,47 s | 379 ms | 475 ms | 400 ms |
DOMContentLoaded | 663 ms | 261 ms | 321 ms | 271 ms |
Load | 694 ms | 285 ms | 348 ms | 290 ms |
GZIP compression enabled with HTTP 1.1 is 214 percent faster than HTTP 1.1 with GZIP compression disabled | When the resources are in the browser cache the response times between HTTP 1.1 and 2.0 are very similar. Strangely with HTTP 2.0 the CSS stylesheet resources are not loaded from the cache, while this is the case with HTTP 1.1 | When the resources are NOT (yet) in the browser cache HTTP 2.0 is 309 percent faster than HTTP 1.1 | When the resources are in the browser cache the response times between HTTP 1.1 and 2.0 are very similar. Strangely with HTTP 2.0 the CSS stylesheet resources are not loaded from the cache, while this is the case with HTTP 1.1 |
Relevant Blueriq properties
blueriq.web-resources: the location (URL) of additional or overridden webresources
blueriq.web-resources.cache-key-seed:
blueriq.web-resources.cache-period-seconds:the cache period for all static webresources. When null, default behavior is to rely only on 'Last-Modified' header. When 0, caching is disabled. When > 0, the number of seconds to cache a resource client-side (browser).
HTTP 1.1 versus HTTP 2.0
HTTP 1.1. can only perform one request per connection, resulting in latency, HTTP 2.0 fixes this by introducing mulitplexing, which allows for multiple requests and responses to be handled by a single TCP connection at the same time.
In HTTP/1.1 it was quicker to download a single file as opposed to several smaller files. As a result it was best practice to concatenate your site’s CSS and JS. In a HTTP/2 era, HTTP requests are cheap, therefore creating a single concatenated file is often unnecessary and an anti-practice for two reasons:
- The concatenated file would often contain components not required by the current page. For example, your blog page might load components that are only used on your checkout pages.
- If a single component changed then the entire concatenated file would need to be invalidated from the browser cache.
Both of the above increase the amount of data which needs to be downloaded from the server to the browser. However, concatenation still does have its place due to compression ratios. Generally, larger files yield better compression results, thus reducing the total overall file size of your page.
HTTP 2.0 support
Tomcat 8.5 upgrade to HTTP 2.0: http://tomcat.apache.org/tomcat-8.5-doc/config/http.html#HTTP/1.1_and_HTTP/1.0_Support
Tomcat 8.5 Connector configuration: http://tomcat.apache.org/tomcat-8.5-doc/config/http.html
Websphere: it seems that Websphere currenlty does not support HTTP 2.0 (https://github.com/http2/http2-spec/wiki/Implementations)
Gzip compression
Enabling HTTP/2 alone can have a significant impact on your site’s performance, but additional best practices such as gzipping assets ensure optimal load times.Static files such as CSS and JS should be compressed by the server before sending them to the browser. This can reduce file sizes by up to 90%, which can significantly reduce the time it takes to download each asset.
Further reading: https://deliciousbrains.com/performance-best-practices-http2/