Tonight I have given a presentation regarding the issue, showing HTTP/2 performance of H2O HTTP server at shibuya.pm, a popular technology meetup at Tokyo. This blog post is a summary of the presentation at the meetup, following my recent blog post about the prioritization logic of HTTP/2 and web browser implementations.
Test Scenario:
- a modified version of http2rulez.com (<script> tags moved into <head>)
- contains 5 CSS files
- 8 script files in <head>, including a minified version of jquery.js
- contains 18 not-blocking assets (e.g. images files), both small and large
- client: Chrome/43 and Firefox/38
- server: Nginx/1.9.1 and H2O/HEAD
- network: dedicated virtual network to avoid noise; 100ms latency (typical for 4G mobile) added artificially using
tc disccommand
Benchmark Results:
Analysis:
When using H2O (and HTTP/2) with optimal settings, the first-paint times are reduced by about 30% when compared to HTTP/1.1 or SPDY/3.1.
First-paint time is a good index of user experience; it shows the timing when the user sees the page being rendered for the first time (or when all assets that block rendering arrives at the client side) since he/she triggered the navigation.
The improvements are due to the fact that Firefox (or Chrome with H2O's
http2-reprioritize-blocking-assets configuration directive set to ON) downloads assets files that block rendering (e.g. CSS or JS files) before other asset files (e.g. images).Conclusion:
With the benchmark showing 30% reduction in first-paint time, it is obvious that HTTP/2 (implemented by H2O) is offering superior performance against the protocols of previous generations. However, implementations might not be mature enough to offer such boost in performance (as discussed in recent blog post, Chrome has issues with its prioritization logic which is worked around by the configuration directive of H2O; Nginx does not prioritize the streams even though such feature is available in SPDY).
For the time being it is suggested that users conduct benchmarks to see if their applications actually become faster, or consult the developers of the HTTP servers for benchmark results.
Or, you can use H2O, which has been hereby shown to provide good performance under the described scenario :-)
No comments:
Post a Comment