4 ms·
> we may get it Which I think is the key statement here. This is all fantastic work, from both Google and those working on the draft, but this is years from be
by maratd 14y ago
> we may get it
Which I think is the key statement here. This is all fantastic work, from both Google and those working on the draft, but this is years from being standardized properly and years more before it's ubiquitous on all browsers.
Also, while its performance is very impressive when comparing against vanilla HTTPS, I haven't seen any impressive numbers of it vs vanilla HTTP?
- coldtea 14y ago>This is all fantastic work, from both Google and those working on the draft, but this is years from being standardized properly and years more before it's ubiquitous on all browsers. Just like CSS3 and HTML5. But you can start using it now, all the same, and many people do, all the same. >Also, while its performance is very impressive when comparing against vanilla HTTPS, I haven't seen any impressive numbers of it vs vanilla HTTP? It's not supposed to be used with HTTP. And the web of the future is not supposed to have much HTTP without S, either.
- ProblemFactory 14y agoAs far as I understand, it's not necessary to wait until SPDY is ubiquitous on all browsers. By enabling SPDY support in Nginx and setting one header in HTTP responses, you can serve your content via both protocols. Any SPDY-enabled visitors would discover the feature, and switch after the first HTTP request. On the browser side, Chrome supports SPDY, and has market share of somewhere between 25-50%. So if I'm not mistaken, enabling this module would make things faster for a large fraction of your visitors, while being backwards-compatible with any browser.