Nginx – Why the browser wouldn’t load all image resources at once

nginxstatic-filestime

I am trying to optimize the loading time of a webpage. Currently, the main http request can be done in under a second, however, the consenquent loading of images seems "to cascade":

http://picpaste.novarata.net/pics/320bd387b4988729ad2dbb10f69a7857.png

I am using nginx to serve my static files, with 3 workers. Is there a possiblity that connections are being held by backlog?

I would assume that all of these images would be loaded at the same time. Files are being served over HTTPS, with keepalive set to 65 seconds.

EDIT: Firefox indeed seems to try to load them at once, however, the connection time is gradually increasing up to more than 2 seconds:

http://picpaste.novarata.net/pics/32c28414501d165df3e04b01e3ac3084.png

Best Answer

This behaviour depends on your browser. If you use Chrome, for example, you might find the Timing graph shows the same behaviour, but that things are 'stalled' for a while; this is likely due to [Chrome's] limit of 6 concurrent connections per origin.

You don't say what browser&version you are using.

Here's an extract from https://developer.chrome.com/devtools/docs/network#resource-network-timing

Stalled/Blocking Time the request spent waiting before it could be sent. This time is inclusive of any time spent in proxy negotiation. Additionally, this time will include when the browser is waiting for an already established connection to become available for re-use, obeying Chrome's maximum six TCP connection per origin rule.

Related Solutions

Nginx – POST request is repeated with nginx loadbalanced server (status 499)

Short answer: try this for your location block:

location / {
  proxy_read_timeout 120;
  proxy_next_upstream error;
  proxy_pass http://$backend;
}

Longer explanation:

I think I have just encountered exactly the problem you described:

I use nginx reverse proxy as a load balancer
for long-running requests, the backend receives the same request multiple times
the nginx access logs of the upstream nodes show 499 status for these requests, and the same request appears in different upstream nodes

It turns out that this is actually default behaviour for nginx as reverse proxy, and upgrading it to higher versions will therefore not resolve this issue, although it was given as a possible solution here, but this addresses a different issue.

It happens because nginx as a load balancer chooses an upstream node in round-robin fashion. When the chosen node fails, the request is sent to the next node. The important thing to note here is that node failure is by default classed as error or timeout. Since you did not set a proxy_read_timeout, the default is 60 seconds. So after 60 seconds of waiting, nginx picks the next node and sends the same request.

So one solution is to increase this timeout so that your long-running operation can complete, e.g. by setting proxy_read_timeout 120; (or whatever limit suits your needs).

Another option is to stop the reverse proxy from trying to use the next node, in case of timeout, by setting proxy_next_upstream error;. Or you could set both these options, as suggested above.

Nginx: Leverage browser caching for remote resources (images)

You can't change the headers for remote resources by changing anything on your server. You need to change them on the server that's serving the files.

The only way I can think to achieve this would be to proxy the images through a dedicated path on your server, but that would require changing the HTML to point to that path.

Best Answer

Related Solutions

Nginx – POST request is repeated with nginx loadbalanced server (status 499)

Nginx: Leverage browser caching for remote resources (images)

Related Topic