4 ms·

Yes I believe the article is suggesting exactly that. Even with that header users will still hit that latency on the first request. If the goal is to lower lat

Yes I believe the article is suggesting exactly that. Even with that header users will still hit that latency on the first request. If the goal is to lower latency on first page load then that won’t help. Although it should definitely help after that.

conradfr 5y ago
Is it still that much important with http2 for most webapps? You can answer the options request at the webserver level or even Varnish which should be quick enough and the http connection reused.
- masklinn 5y ago
  > Is it still that much important with http2 for most webapps? Yes? The overhead of a full request/response cycle is still overhead, even if it's lowered by not having to duplicate establishing the connection itself.
jakub_g 5y ago
Sometimes it's very difficult to use same domain if e.g. API is on different tech stack. IIRC you could then do something like <link rel=preconnect crossorigin=anonymous href="https://api.example.com https://api.example.com"> or <link rel=preload crossorigin=anonymous href="https://api.example.com/emptyendpoint https://api.example.com/emptyendpoint"> just to initiate the connection/CORS dance early one before your JS kicks in. In my prev job we'd do a request to empty endpoint from inlined JS. Poor hack but it worked.
- jakub_g 5y ago
  Note that if you send any non standard request headers, for the CORS response to be cached and reused, you need to make an initial request with exactly same set of headers, which means it is only possible via JS (preload request can't have extra headers). Hence inlined JS to send the "warmup" request. You can wrap it in a promise which resolves on response, and only then do the actual app request.
- richardwhiuk 5y ago
  Just because they are on different tech stacks doesn't mean you can't do this.
- mixedCase 5y ago
  I'm having trouble thinking of a web stack where you can't set up a reverse proxy either via Nginx colocated with the frontend web server, through any of the usual suspects for termination (e.g. CDNs or load balancers), or worst case scenario, through the frontend web server itself. Can you share any examples?
  - jakub_g 5y ago
    I'm not an expert because I only work on front-end but scale ops folks in my prev job had their reasons. We had legacy www http/1 monolith and api http/2 geodistributed in the cloud. Making the two go through the common proxy wouldn't probably make sense and/or would be quite expensive.

conradfr 5y ago

Is it still that much important with http2 for most webapps? You can answer the options request at the webserver level or even Varnish which should be quick enough and the http connection reused.

masklinn 5y ago
> Is it still that much important with http2 for most webapps? Yes? The overhead of a full request/response cycle is still overhead, even if it's lowered by not having to duplicate establishing the connection itself.

jakub_g 5y ago

Sometimes it's very difficult to use same domain if e.g. API is on different tech stack. IIRC you could then do something like <link rel=preconnect crossorigin=anonymous href="https://api.example.com https://api.example.com"> or <link rel=preload crossorigin=anonymous href="https://api.example.com/emptyendpoint https://api.example.com/emptyendpoint"> just to initiate the connection/CORS dance early one before your JS kicks in. In my prev job we'd do a request to empty endpoint from inlined JS. Poor hack but it worked.

jakub_g 5y ago
Note that if you send any non standard request headers, for the CORS response to be cached and reused, you need to make an initial request with exactly same set of headers, which means it is only possible via JS (preload request can't have extra headers). Hence inlined JS to send the "warmup" request. You can wrap it in a promise which resolves on response, and only then do the actual app request.
richardwhiuk 5y ago
Just because they are on different tech stacks doesn't mean you can't do this.
mixedCase 5y ago
I'm having trouble thinking of a web stack where you can't set up a reverse proxy either via Nginx colocated with the frontend web server, through any of the usual suspects for termination (e.g. CDNs or load balancers), or worst case scenario, through the frontend web server itself. Can you share any examples?
- jakub_g 5y ago
  I'm not an expert because I only work on front-end but scale ops folks in my prev job had their reasons. We had legacy www http/1 monolith and api http/2 geodistributed in the cloud. Making the two go through the common proxy wouldn't probably make sense and/or would be quite expensive.