You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Current »

Measurements in Google Chrome with Blueriq 10.5

 HTTP 1.1 with disabled cacheHTTP 1.1 with cacheHTTP 2.0 (with TLS) and cache disabledHTTP 2.0 (with TLS) with cache
Requests38383838
Transferred1.4 MB16.3 KB1.4 MB293 KB
Finish1,47 s379 ms475 ms400 ms
DOMContentLoaded663 ms261 ms321 ms271 ms
Load694 ms285 ms348 ms290 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.cache-key-seed

blueriq.web-resources.cache-period-seconds

HTTP 1.1 versus HTTP 2.0

HTTP 1.1. can only perform one request per connection, resulting in additional latency, HTTP 2.0 mitigates this by introducing multiplexing, 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 often considerably faster to download one large file as opposed to several smaller files. As a result it was best practice to concatenate your site’s CSS and JS resources. 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:

  1. 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.
  2. If a single component changes 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

JBoss EAP 7.0: https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Enterprise_Application_Platform/7.0/pdf/Configuration_Guide/Red_Hat_JBoss_Enterprise_Application_Platform-7.0-Configuration_Guide-en-US.pdf

Websphere: it seems that Websphere currenlty (november 2017) does not support HTTP 2.0 (https://github.com/http2/http2-spec/wiki/Implementations)

Gzip compression

Enabling HTTP 2.0 alone can have a significant impact on your site’s performance, but additional best practices such as gzipping assets ensure optimal load times. Static text based 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.

Concatenation

In HTTP 2.0, concatenation isn't required any more to improve performance. We can now send (potentially) hundreds of requests in one connection, so we don't have to bundle files together any more. Concatenation was a way to cheat the 6-connections-open-at-one-time limit. That limit doesn't exist in HTTP 2.0. In fact, concatenation could be counter productive--what if you're loading a bunch of CSS that doesn't get used on a some of your pages? You're just loading extra bytes and that can slow down rendering of your page. In HTTP 1.1, it was often worth avoiding an extra round trip, but in HTTP 2.0 it probably isn't.

Further reading: https://deliciousbrains.com/performance-best-practices-http2/

 

  • No labels