6 ms·

1 could, only faster

38 points by pgjones 8y ago

est 8y ago
but can h2 do websocket?
- nickexyz 8y ago
  First sentence: "Recently WebSocket support has been added to HTTP/2 (in RFC 8441)"
  - deleted 8y ago
    [deleted]
- deleted 8y ago
  [deleted]
mankyd 8y ago
One important difference: HTTP/2 requires* encryption. This makes getting up and running for local development and small deployments more difficult. * https://http2.github.io/faq/#does-http2-require-encryption https://http2.github.io/faq/#does-http2-require-encryption "[...] currently no browser supports HTTP/2 unencrypted."
- crankylinuxuser 8y ago
  I'm guessing they're not carving out a niche for self-signed certs? I think that would have been a fair balance, of setting a "this is a self-signed cert" instead of the current "YoUr WeBsIte IS UNSECURED" (which isn't actually true). Accepting and indicating self signed would also be handy in Tor's onion sites, since the only companies that will issue certs require EV2 and all your info and a pile of money. And Onioncerts are pretty much only Facebook's area :/
  - pilif 8y ago
    > (which isn't actually true) how would I discern your self-signed certificate from the one served by the person arp-spoofing the gateway in a Starbucks?
    - crankylinuxuser 8y ago
      No cert chain for starters. The better answer here is some sort of "self signed standard data" for non-CA certs. But right now, testing in a NAT using HTTP2 is a ugly nonstarter.
      - pilif 8y ago
        > No cert chain for starters. why would the person who arp-spoofs the gateway in the Starbucks not be able to fetch your self-signed cert chain and mint their own matching chain with the exact same metadata (but of course differing keys)?
        crankylinuxuser 8y ago
        Then what's your proposal for NATted, self-contained (no gateway), and Tor Onion networks? Sure, if I have a public IP and DNS records pointing towards it, I'm served by LE or a multitude other vendors. But that's a small number of machines on any network.
        nybble41 8y ago
        If you have a public DNS entry then you can get a certificate from Let's Encrypt using the DNS verification method, even if the name points to a private IP address. DANE would also be an option if it (and DNSSEC) were more widely implemented. Local name resolution (mDNS) could take a page from what Tor already does and encode the public key fingerprint into the domain name. If the key uniquely matches the domain (perhaps just the first part, e.g. b32-key-hash.friendly-name.local) then you automatically get the equivalent of domain validation. While, by itself, this doesn't prove that you're connected to the right domain, by bookmarking the page and visiting it only through that bookmark you would get the equivalent of trust-on-first-use. Browsers would just need to recognize this form of domain name and validate the key against the embedded hash instead of an external CA.
- kevin_b_er 8y ago
  As such, we know this statement to be false: "With WebSocket HTTP/2 support there is nothing that HTTP/1.1 can do that HTTP/2 cannot"
  - deleted 8y ago
    [deleted]
bpicolo 8y ago
Aha, this article is by the creator of Quart[0]! I'm a big fan - one of my favorite new python packages. It's essentially a super zippy, flask-compatible asyncio python server. I switched a flask app over recently and saw an immediate 10-20x throughput gain (the app is entirely io-bound). pgjones was a pleasure to work with when I had a few issues and had to contribute a few compat fixes as well. Thanks for the awesome package! [0]: https://gitlab.com/pgjones/quart/ https://gitlab.com/pgjones/quart/
- pgjones 8y ago
  Wow, any chance you could write up the throughput gain? It would be great to see some real production numbers. Thanks for the comments.
  - bpicolo 8y ago
    It's an internal dashboard, so that was a stress testing figure - afraid it wouldn't be a terribly interesting write up. It was still exciting for me, because I'd been looking for more or less flask-with-asyncio for quite some time.
  - hultner 8y ago
    I’ve looked at quart and it looks interesting but is there much point to running an async webserver for APIs mainly reliant on db-access if we use SQLAlchemy for database connections? I’m under the impression that since the db stuff still is sync/blocking we won’t win much by running an asgi server instead of WSGI.
    - bpicolo 8y ago
      Give peewee-async as shot if you'd like async DB access as well. https://peewee-async.readthedocs.io/en/latest/ https://peewee-async.readthedocs.io/en/latest/ Looks like Gino is a new project trying to bake asyncio ORM on top of sqlalchemy core: https://github.com/fantix/gino https://github.com/fantix/gino
      - 8y ago
the_other_guy 8y ago
pathetic that you only make people pay attention using clickbaity and angry titles
- pgjones 8y ago
  I think my articles in the past have been too dull; I think people would like to read something interesting and entertaining so I'm trying to improve in this regard. Was the article a good read or did the title put you off?
  - dirkt 8y ago
    I am not the one you answered, but the title DID put me off, and therefore I didn't read the article (and I probably won't read it, even if it is good). I loathe the tendency to pack emotion and opinion into everything, and exaggerate everything, just because people think they'll get readers that way. Please don't.
  - the_other_guy 8y ago
    It wasn't a criticism against you specifically, I meant that it's just pathetic that using titles like "X should die" is the only way to get people's attention these days, I know how hard it is to make people pay attention on the internet and it's just sad that provoking them is the only way to do it
  - nindalf 8y ago
    Folks generally click baity articles more, but are unhappy about the fact they were baited into clicking a low quality article. It's a dilemma - do you want people to be happy or do you want more readers? Feedback on the article - haven't you chosen a pathological case of a single click triggering 20 API calls that don't depend on each other? Wouldn't it be simpler to batch these calls on the server?
- berry_sortoro 8y ago
  Pathetic how offended you get because someone over this supposedly "angry and clickbaity" title. He used the word die. So what? Would you make the same comment if it would be about flash? I do not perceive this as angry at all and not even really click-bait. There are so many actually good examples for true clickbait, this is not one of them.
deleted 8y ago
[deleted]
jabart 8y ago
Yes and no, because it is complicated. This is a fairly naive example of HTTP/2 to illustrate a point, while most websites I am called in on to optimize the load time are not built like this. This example only shaved off around 60ms for 20 requests, if your website has 20 requests to load, you have ads or you have a resource problem. HTTP/2 spec says it should not share a connection across a host/port combo, any content you have loaded on a CDN, or a your own cdn.mydomain.com will be a separate connection. The reason CDNs are faster is because they are closer(lower latency) or it is common and already cached in your browser. HTTP/2 still suffers from latency and TCP Window sizes, so no your 8mb website will still be slow after you enable HTTP/2, you still have to push 8mb out to the client. If you have a site loading over 80 resources, concat and minify that first before asking your server admin to turn on HTTP/2. HTTP/1 clients gets around some network latency issues by issuing more than one TCP socket, just like SFTP clients using more than one thread. Because it is hard to overload a single socket when your latency for your ACK packets is 200ms+. If this wasn't true, Google would not be spending the time on a UDP based version of HTTP. HTTP/2 Overall, lower you content size, lower the number of requests it takes to load your initial website, THEN turn on HTTP/2.
- eeeeeeeeeeeee 8y ago
  Yep. I haven't seen more recent studies on this, but I do remember a lot of use cases and benchmarks I read where if your user base was on high-latency or unreliable internet connections (packet loss, even minor), HTTP/2 would be slower than 1. Here is a good summary of the issue: https://www.twilio.com/blog/2017/10/http2-issues.html https://www.twilio.com/blog/2017/10/http2-issues.html Like you mentioned, HTTP is slowly moving towards UDP instead of TCP (QUIC protocol) to combat this. Cloudflare covers it a bit here too: https://blog.cloudflare.com/the-road-to-quic/ https://blog.cloudflare.com/the-road-to-quic/ I'm a fan of HTTP/2, and I think most people will benefit, but I really hate these kind of posts that only highlight the best case scenario to prove a point that has wide-ranging consequences. I can go on google and type "HTTP/2 is fast" and be reaffirmed in everything I thought about HTTP/2 -- I just did -- and almost every single blog mentioned zero downsides to using HTTP/2.
  - jabart 8y ago
skywhopper 8y ago
Actually, no. HTTP/2 cannot be easily read or written by a human with a telnet or s_client connection without some additional tools. It also can't be supported by a lot of old software without some additional layer of indirection. This may or may not be important to you, but it is a thing that HTTP/2 cannot do.
- eeeeeeeeeeeee 8y ago
  I'm not sure why you're being downvoted. The financial/resource burden of learning new technologies should be considered and weighed against the advantages it delivers over the old technology.
  - Kalium 8y ago
    You're right! Technology should under no circumstances by adopted blindly. Costs and opportunities should always be weighed carefully. Given that TLS is mention in-line as also breaking this point, I think it perhaps possible that some readers might be of the opinion that the decision-making process you call for has already been conducted. Since TLS breaks the standard of "it is human-eyeball-friendly with telnet/netcat", HTTP/2 is little different in the minds of many. Your caution is right and apt. The history of computing is littered with technologies that were unready, unsuitable, or otherwise not fit for purpose when adopted.
- acdha 8y ago
  > HTTP/2 cannot be easily read or written by a human with a telnet or s_client connection without some additional tools This is, of course, why we also don't use chunked encoding and compression with HTTP 1 rather than writing better tools. I mean, you even have the example in that sentence about how the solution for using TLS was not to say “it doesn't work with telnet” but to use s_client, ncat, socat, etc. > It also can't be supported by a lot of old software without some additional layer of indirection This part is true but it's also the classic legacy computing problem: old software which cannot be upgraded will increasingly have security and compatibility issues which favor putting it behind a proxy anyway. This should factor into the cost of choosing not to maintain those systems rather holding back the future.
Proven 8y ago
Whatever. Not everyone supports or needs /2. Case closed.
rqs 8y ago
I rather believe HTTP/2 will die when HTTP/3 is available. After all HTTP/1 is very simple to implement and already widely used and optimized. It is usable for most of cases. Plus, maybe in the future, CDN can serve HTTP/2 to client while use HTTP/1 to read the source. And currently web browsers still need to send Upgrade request in HTTP/1 to know whether or not a unknown HTTP server supports HTTP/2. I guess this will still be true after HTTP/3 comes out (alt-svc).
- pmalynin 8y ago
  Actually HTTP2 upgrade isn’t done with an “Upgrade:” request, but rather with TLS protocol negotiation.
  - rqs 8y ago
    Oh silly me. I've implemented my own HTTP/2 server according to RFC 7540[0]. I forgot in the real world web browsers just send "h2" TLS-ALPN. [0] https://tools.ietf.org/html/rfc7540#section-3.2 https://tools.ietf.org/html/rfc7540#section-3.2
commandlinefan 8y ago
Same can be said about IPv6 - and could have been said about IPv6 20 years ago. Still waiting...
- acdha 8y ago
  That's a tricky comparison because using IPv6 required updates to the client, server, and every box in between whereas HTTP/2 only requires the endpoints to be updated and has a graceful degradation path in most cases. Unsurprisingly, it's already far more common than IPv6 because you don't have to go to every enterprise on the planet and tell them to fix things even their network team is afraid to touch. In contrast, HTTP/2 rapidly hit much higher numbers thanks to Firefox and Chrome shipping support via automatic updates. When CloudFlare deprecated SPDY about a year ago they were already seeing adoption numbers just under 70%: https://blog.cloudflare.com/deprecating-spdy/ https://blog.cloudflare.com/deprecating-spdy/
rando231 8y ago
This can't be true, can it? I was under the impression that HTTP/2 used a persistent connection w/ multiplexing. This seems like it would be very nice in a web-browser to front-end situation, but what about for internal service calls? Seems like persistent connection between services would mess w/ common load balancing schemes.
- bastawhiz 8y ago
  There's nothing stopping you from having one connection per request with HTTP/2. You could build your software to simply have the same behavior as HTTP/1.1 with keep-alive
atemerev 8y ago
So, Websockets over HTTP/2 are only available in latest Firefox (or experimentally in Chrome, if you manually turn on a flag for it). Almost no servers support HTTP/2 Websockets, too. Sorry, it is a little too early to switch.
xena 8y ago
Except websockets.
- pgjones 8y ago
  This is now possible, the article talks about what impact HTTP/2 WebSockets can make. (See also RFC 8441).
antoinevg 8y ago
Speed. It is not everything.
deleted 8y ago
[deleted]
peterwwillis 8y ago
If you want HTTP/2 to succeed, you're going to have to start making little wins. Find a tiny, easy market and get them to use it. Then find a giant customer (Google never counts) and get them to use it. If it seems more complicated, nobody's going to pick it up unless they have to. The alternative is to create big sexy splash pages, create a lots of hype, and lie to people about how easy it is to implement. When they're finally caught up in the complexity of implementation, it'll be too late to back out.
deleted 8y ago
[deleted]
altmind 8y ago
Time will show what unknown challenges and problems http/2 carries. So far, the protocol is studied mostly by google(and less by cloudflare), there is limited research by independent parties. From the article, i see that the author heavily relies on the chrome devtools to demonstrate the performance benefit, relying on chrome connection statuses. My spdy and http/2 tests in 2016 did not show much imrovment in perceived load speed for our e-commerce site. optimizing delivery(for us - caching the pre-rendered javascript components and pre-loading some ajax) yield better results. ymmv.

38 points by pgjones 8y ago

est 8y ago

but can h2 do websocket?

nickexyz 8y ago
First sentence: "Recently WebSocket support has been added to HTTP/2 (in RFC 8441)"
- deleted 8y ago
  [deleted]
deleted 8y ago
[deleted]

mankyd 8y ago

One important difference: HTTP/2 requires* encryption. This makes getting up and running for local development and small deployments more difficult. * https://http2.github.io/faq/#does-http2-require-encryption https://http2.github.io/faq/#does-http2-require-encryption "[...] currently no browser supports HTTP/2 unencrypted."

crankylinuxuser 8y ago
I'm guessing they're not carving out a niche for self-signed certs? I think that would have been a fair balance, of setting a "this is a self-signed cert" instead of the current "YoUr WeBsIte IS UNSECURED" (which isn't actually true). Accepting and indicating self signed would also be handy in Tor's onion sites, since the only companies that will issue certs require EV2 and all your info and a pile of money. And Onioncerts are pretty much only Facebook's area :/
- pilif 8y ago
  > (which isn't actually true) how would I discern your self-signed certificate from the one served by the person arp-spoofing the gateway in a Starbucks?
  - crankylinuxuser 8y ago
    No cert chain for starters. The better answer here is some sort of "self signed standard data" for non-CA certs. But right now, testing in a NAT using HTTP2 is a ugly nonstarter.
    - pilif 8y ago
      > No cert chain for starters. why would the person who arp-spoofs the gateway in the Starbucks not be able to fetch your self-signed cert chain and mint their own matching chain with the exact same metadata (but of course differing keys)?
      - crankylinuxuser 8y ago
        Then what's your proposal for NATted, self-contained (no gateway), and Tor Onion networks? Sure, if I have a public IP and DNS records pointing towards it, I'm served by LE or a multitude other vendors. But that's a small number of machines on any network.
        nybble41 8y ago
        If you have a public DNS entry then you can get a certificate from Let's Encrypt using the DNS verification method, even if the name points to a private IP address. DANE would also be an option if it (and DNSSEC) were more widely implemented. Local name resolution (mDNS) could take a page from what Tor already does and encode the public key fingerprint into the domain name. If the key uniquely matches the domain (perhaps just the first part, e.g. b32-key-hash.friendly-name.local) then you automatically get the equivalent of domain validation. While, by itself, this doesn't prove that you're connected to the right domain, by bookmarking the page and visiting it only through that bookmark you would get the equivalent of trust-on-first-use. Browsers would just need to recognize this form of domain name and validate the key against the embedded hash instead of an external CA.
kevin_b_er 8y ago
As such, we know this statement to be false: "With WebSocket HTTP/2 support there is nothing that HTTP/1.1 can do that HTTP/2 cannot"
- deleted 8y ago
  [deleted]

bpicolo 8y ago

Aha, this article is by the creator of Quart[0]! I'm a big fan - one of my favorite new python packages. It's essentially a super zippy, flask-compatible asyncio python server. I switched a flask app over recently and saw an immediate 10-20x throughput gain (the app is entirely io-bound). pgjones was a pleasure to work with when I had a few issues and had to contribute a few compat fixes as well. Thanks for the awesome package! [0]: https://gitlab.com/pgjones/quart/ https://gitlab.com/pgjones/quart/

pgjones 8y ago
Wow, any chance you could write up the throughput gain? It would be great to see some real production numbers. Thanks for the comments.
- bpicolo 8y ago
  It's an internal dashboard, so that was a stress testing figure - afraid it wouldn't be a terribly interesting write up. It was still exciting for me, because I'd been looking for more or less flask-with-asyncio for quite some time.
- hultner 8y ago
  I’ve looked at quart and it looks interesting but is there much point to running an async webserver for APIs mainly reliant on db-access if we use SQLAlchemy for database connections? I’m under the impression that since the db stuff still is sync/blocking we won’t win much by running an asgi server instead of WSGI.
  - bpicolo 8y ago
    Give peewee-async as shot if you'd like async DB access as well. https://peewee-async.readthedocs.io/en/latest/ https://peewee-async.readthedocs.io/en/latest/ Looks like Gino is a new project trying to bake asyncio ORM on top of sqlalchemy core: https://github.com/fantix/gino https://github.com/fantix/gino
    - 8y ago

the_other_guy 8y ago

pathetic that you only make people pay attention using clickbaity and angry titles

pgjones 8y ago
I think my articles in the past have been too dull; I think people would like to read something interesting and entertaining so I'm trying to improve in this regard. Was the article a good read or did the title put you off?
- dirkt 8y ago
  I am not the one you answered, but the title DID put me off, and therefore I didn't read the article (and I probably won't read it, even if it is good). I loathe the tendency to pack emotion and opinion into everything, and exaggerate everything, just because people think they'll get readers that way. Please don't.
- the_other_guy 8y ago
  It wasn't a criticism against you specifically, I meant that it's just pathetic that using titles like "X should die" is the only way to get people's attention these days, I know how hard it is to make people pay attention on the internet and it's just sad that provoking them is the only way to do it
- nindalf 8y ago
  Folks generally click baity articles more, but are unhappy about the fact they were baited into clicking a low quality article. It's a dilemma - do you want people to be happy or do you want more readers? Feedback on the article - haven't you chosen a pathological case of a single click triggering 20 API calls that don't depend on each other? Wouldn't it be simpler to batch these calls on the server?
berry_sortoro 8y ago
Pathetic how offended you get because someone over this supposedly "angry and clickbaity" title. He used the word die. So what? Would you make the same comment if it would be about flash? I do not perceive this as angry at all and not even really click-bait. There are so many actually good examples for true clickbait, this is not one of them.

deleted 8y ago

[deleted]

jabart 8y ago

Yes and no, because it is complicated. This is a fairly naive example of HTTP/2 to illustrate a point, while most websites I am called in on to optimize the load time are not built like this. This example only shaved off around 60ms for 20 requests, if your website has 20 requests to load, you have ads or you have a resource problem. HTTP/2 spec says it should not share a connection across a host/port combo, any content you have loaded on a CDN, or a your own cdn.mydomain.com will be a separate connection. The reason CDNs are faster is because they are closer(lower latency) or it is common and already cached in your browser. HTTP/2 still suffers from latency and TCP Window sizes, so no your 8mb website will still be slow after you enable HTTP/2, you still have to push 8mb out to the client. If you have a site loading over 80 resources, concat and minify that first before asking your server admin to turn on HTTP/2. HTTP/1 clients gets around some network latency issues by issuing more than one TCP socket, just like SFTP clients using more than one thread. Because it is hard to overload a single socket when your latency for your ACK packets is 200ms+. If this wasn't true, Google would not be spending the time on a UDP based version of HTTP. HTTP/2 Overall, lower you content size, lower the number of requests it takes to load your initial website, THEN turn on HTTP/2.

eeeeeeeeeeeee 8y ago
Yep. I haven't seen more recent studies on this, but I do remember a lot of use cases and benchmarks I read where if your user base was on high-latency or unreliable internet connections (packet loss, even minor), HTTP/2 would be slower than 1. Here is a good summary of the issue: https://www.twilio.com/blog/2017/10/http2-issues.html https://www.twilio.com/blog/2017/10/http2-issues.html Like you mentioned, HTTP is slowly moving towards UDP instead of TCP (QUIC protocol) to combat this. Cloudflare covers it a bit here too: https://blog.cloudflare.com/the-road-to-quic/ https://blog.cloudflare.com/the-road-to-quic/ I'm a fan of HTTP/2, and I think most people will benefit, but I really hate these kind of posts that only highlight the best case scenario to prove a point that has wide-ranging consequences. I can go on google and type "HTTP/2 is fast" and be reaffirmed in everything I thought about HTTP/2 -- I just did -- and almost every single blog mentioned zero downsides to using HTTP/2.
- jabart 8y ago

skywhopper 8y ago

Actually, no. HTTP/2 cannot be easily read or written by a human with a telnet or s_client connection without some additional tools. It also can't be supported by a lot of old software without some additional layer of indirection. This may or may not be important to you, but it is a thing that HTTP/2 cannot do.

eeeeeeeeeeeee 8y ago
I'm not sure why you're being downvoted. The financial/resource burden of learning new technologies should be considered and weighed against the advantages it delivers over the old technology.
- Kalium 8y ago
  You're right! Technology should under no circumstances by adopted blindly. Costs and opportunities should always be weighed carefully. Given that TLS is mention in-line as also breaking this point, I think it perhaps possible that some readers might be of the opinion that the decision-making process you call for has already been conducted. Since TLS breaks the standard of "it is human-eyeball-friendly with telnet/netcat", HTTP/2 is little different in the minds of many. Your caution is right and apt. The history of computing is littered with technologies that were unready, unsuitable, or otherwise not fit for purpose when adopted.
acdha 8y ago
> HTTP/2 cannot be easily read or written by a human with a telnet or s_client connection without some additional tools This is, of course, why we also don't use chunked encoding and compression with HTTP 1 rather than writing better tools. I mean, you even have the example in that sentence about how the solution for using TLS was not to say “it doesn't work with telnet” but to use s_client, ncat, socat, etc. > It also can't be supported by a lot of old software without some additional layer of indirection This part is true but it's also the classic legacy computing problem: old software which cannot be upgraded will increasingly have security and compatibility issues which favor putting it behind a proxy anyway. This should factor into the cost of choosing not to maintain those systems rather holding back the future.

Proven 8y ago

Whatever. Not everyone supports or needs /2. Case closed.

rqs 8y ago

I rather believe HTTP/2 will die when HTTP/3 is available. After all HTTP/1 is very simple to implement and already widely used and optimized. It is usable for most of cases. Plus, maybe in the future, CDN can serve HTTP/2 to client while use HTTP/1 to read the source. And currently web browsers still need to send Upgrade request in HTTP/1 to know whether or not a unknown HTTP server supports HTTP/2. I guess this will still be true after HTTP/3 comes out (alt-svc).

pmalynin 8y ago
Actually HTTP2 upgrade isn’t done with an “Upgrade:” request, but rather with TLS protocol negotiation.
- rqs 8y ago
  Oh silly me. I've implemented my own HTTP/2 server according to RFC 7540[0]. I forgot in the real world web browsers just send "h2" TLS-ALPN. [0] https://tools.ietf.org/html/rfc7540#section-3.2 https://tools.ietf.org/html/rfc7540#section-3.2

commandlinefan 8y ago

Same can be said about IPv6 - and could have been said about IPv6 20 years ago. Still waiting...

acdha 8y ago
That's a tricky comparison because using IPv6 required updates to the client, server, and every box in between whereas HTTP/2 only requires the endpoints to be updated and has a graceful degradation path in most cases. Unsurprisingly, it's already far more common than IPv6 because you don't have to go to every enterprise on the planet and tell them to fix things even their network team is afraid to touch. In contrast, HTTP/2 rapidly hit much higher numbers thanks to Firefox and Chrome shipping support via automatic updates. When CloudFlare deprecated SPDY about a year ago they were already seeing adoption numbers just under 70%: https://blog.cloudflare.com/deprecating-spdy/ https://blog.cloudflare.com/deprecating-spdy/

rando231 8y ago

This can't be true, can it? I was under the impression that HTTP/2 used a persistent connection w/ multiplexing. This seems like it would be very nice in a web-browser to front-end situation, but what about for internal service calls? Seems like persistent connection between services would mess w/ common load balancing schemes.

bastawhiz 8y ago
There's nothing stopping you from having one connection per request with HTTP/2. You could build your software to simply have the same behavior as HTTP/1.1 with keep-alive

atemerev 8y ago

So, Websockets over HTTP/2 are only available in latest Firefox (or experimentally in Chrome, if you manually turn on a flag for it). Almost no servers support HTTP/2 Websockets, too. Sorry, it is a little too early to switch.

xena 8y ago

Except websockets.

pgjones 8y ago
This is now possible, the article talks about what impact HTTP/2 WebSockets can make. (See also RFC 8441).

antoinevg 8y ago

Speed. It is not everything.

deleted 8y ago

[deleted]

peterwwillis 8y ago

If you want HTTP/2 to succeed, you're going to have to start making little wins. Find a tiny, easy market and get them to use it. Then find a giant customer (Google never counts) and get them to use it. If it seems more complicated, nobody's going to pick it up unless they have to. The alternative is to create big sexy splash pages, create a lots of hype, and lie to people about how easy it is to implement. When they're finally caught up in the complexity of implementation, it'll be too late to back out.

deleted 8y ago

[deleted]

altmind 8y ago

Time will show what unknown challenges and problems http/2 carries. So far, the protocol is studied mostly by google(and less by cloudflare), there is limited research by independent parties. From the article, i see that the author heavily relies on the chrome devtools to demonstrate the performance benefit, relying on chrome connection statuses. My spdy and http/2 tests in 2016 did not show much imrovment in perceived load speed for our e-commerce site. optimizing delivery(for us - caching the pre-rendered javascript components and pre-loading some ajax) yield better results. ymmv.