Opened 9 years ago
Closed 9 years ago
#991 closed defect (invalid)
http2 uses suboptimal stream prioritization making http/2 slower than http/1.1
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | other | Version: | 1.11.x |
| Keywords: | Cc: | ||
| uname -a: | Linux mycentosbox 2.6.32-573.18.1.el6.x86_64 #1 SMP Tue Feb 9 22:46:17 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.11.0
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-16) (GCC) built with OpenSSL 1.0.2h 3 May 2016 TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib64/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-openssl=/opt/lib/openssl-1.0.2h --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_xslt_module=dynamic --with-http_image_filter_module=dynamic --with-http_geoip_module=dynamic --with-http_perl_module=dynamic --add-dynamic-module=njs-1c50334fbea6/nginx --with-threads --with-stream --with-stream_ssl_module --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_v2_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' |
||
Description
When using connection with low bandwidth (G2, GPRS...), our page render starts 60% later with HTTP/2 with HTTP 1.1
The problem is that the main (blocking) CSS file is downloaded in parallel with images on HTTP/2. So the CSS download shares bandwidth with a lot of images that should have much lower priority. Our CSS file is 50KB gzipped and our images in total are much more than 50KB.
HTTP 1.1 doesn't download all images in parallel- it's limited by the total number of TCP connections, so the CSS download finishes much faster and page render can start much sooner.
Ilya Grigorik wrote it could be a problem in nginx http/2 implementation. https://twitter.com/igrigorik/status/737649411325468673
One image is worth thousand words, here it is: https://twitter.com/vojtechkurka/status/736212847982583809
The browser I'm using is Chrome 51 on Mac OS.
We can't use HTTP/2 to production because of this behaviour. It would make mobile user experience much worse than now on HTTP/1.1.
Attachments (5)
Change History (12)
by , 9 years ago
| Attachment: | Screen Shot 2016-05-27 at 17.00.55.png added |
|---|
by , 9 years ago
| Attachment: | Screen Shot 2016-05-27 at 17.01.08.png added |
|---|
chrome network debug screenshot
comment:2 by , 9 years ago
Replying to vbart:
Could you provide a debug log?
I'm sorry, I currently don't have nginx compiled --with-debug :(
But if you can't reproduce the described behaviour, let me know and I'll try to install nginx-debug somewhere and simulate the problem.
follow-up: 4 comment:3 by , 9 years ago
I don't have that page to reproduce. Please note, that HTTP/2 prioritization in nginx usually works good with typical pages.
comment:4 by , 9 years ago
Replying to vbart:
I don't have that page to reproduce. Please note, that HTTP/2 prioritization in nginx usually works good with typical pages.
The page is this: http://www.glami.fr/robes-femmes/
It's served over HTTP 1.1 with HTTP/2 CDN for CSS, JS and images.
comment:5 by , 9 years ago
The URL to the page doesn't really help, since your page contains a lot of resources from multiple hosts and it's not easy to save it with all the resources locally.
With Firefox it's good. See the attachment below.
Are you sure that it's not a problem with throttling tool in Chrome?
by , 9 years ago
| Attachment: | firefox.png added |
|---|
by , 9 years ago
| Attachment: | http2_real_2G_connection.png added |
|---|
by , 9 years ago
| Attachment: | http2_network_link_conditioner_Edge.png added |
|---|
comment:6 by , 9 years ago
@vbart: You are absolutely right, the network throttling in Chrome is spoiling the results.
I tried:
1.) real 2G connection (using my phone tethering)
2.) "Network Link Conditioner" on MacOS with "Edge" setting
(see the last two screenshots attached)
In both cases, the page load was OK, CSS was correctly prioritized leading to faster render start.
My apologies for blaming nginx.
Thank you vbart for pointing me in the right direction!
Vojtech
chrome network debug screenshot