51–60 of 72 posts
From the project page:
Key features of QUIC over existing TCP+TLS+HTTP2 include
* Dramatically reduced connection establishment time
* Improved congestion control
* Multiplexing without head of line blocking
* Forward error correction
* Connection migration
I thought that HTTP/2 didn't fix head-of-line blocking and this was why QUIC ( https://www.chromium.org/quic ) existed. From the project page: Key features of QUIC over existing TCP+TLS+HTTP2 include * Dramatically reduced connection establishment time * Improved congestion control * Multiplexing without head of line blocking * Forward error correction * Connection migration
However it doesn't have abilities that will allow individual streams to proceed if some packets are lost that only hold information for a single stream.
I did not do any real tests and I might be completely wrong etc. but it seems to me that http2 is going to perform poorly over wireless links like 3g. With http1 one had N tcp connections, and with the way tcp slowly increases the bandwidth used, and rapidly decreases it when packet is lost, even if any packet were dropped (which will happen quite a lot on 3g) other tcp streams were not delayed, or blocked, and can e…
One way to "solve" the time to visual completion would be to make all the images, but especially the larger images, progressive scan. For very large images, the difference in visual quality between 50% downloaded and 100% downloaded on most devices isn't noticeable, so the page would appear complete in half the time.
Doesn't that increase the file size though? They're looking at 3G load speeds, so any increase in file size is probably unwelcome.
Some solutions: - Serve less data. The best speedup is when there's no more data to download and if the throughput for clients is maxed out, then decreasing page weight helps. - Use async bootstrap JS code to load in other scripts once images are done loading or other page load events have fired. - Load less images in parallel, use JS to load one row of images at a time. - Use HTTP/2 push (which CloudFlare offers) to…
We've recently moved to Google Cloud Storage from AWS because of http/2. We had a bottleneck of the browser waiting when serving multiple large (8+files * 10mb+each). I'm wondering if 99designs looked at any sort of domain sharding to get around the timing issues. If I understand correctly, wouldn't this get around the priority queue issue? Your js,fonts, etc. coming from a different address than your larger images,…
Founder of NuevoCloud here. If I read this right, you guys used Cloudflare for http 2. So let me ask you this, when you did your comparison, were all of the images cached (ie: x-cache: hit) at the edge? The reason I ask is because cloudflare, last I checked, still hasn't implemented http2's client portion. So when a file is not cached, it does this: client edge node origin server. Http2 is only used for the short hop…
Founder of NuevoCloud here. If I read this right, you guys used Cloudflare for http 2. So let me ask you this, when you did your comparison, were all of the images cached (ie: x-cache: hit) at the edge? The reason I ask is because cloudflare, last I checked, still hasn't implemented http2's client portion. So when a file is not cached, it does this: client edge node origin server. Http2 is only used for the short hop…
Earlier quoted context omitted.
although cloudflare doesn't manage caches on a per account basis. Each PoP has a single LRU cache that's used for all customers. In other words, even if you've primed it, your files may have been pushed out of the cache by a larger customer. In order to know this hasn't occurred, you really have to check the hit rate cloudflare is reporting (for static files that rarely change, this should be near or at 100%)... and…
>Each PoP has a single LRU cache that's used for all customers. Is this true for all tiers of paid accounts? Can someone from CF chime in here?
> We cache as much as possible, for as long as possible. The more requested a file, the more likely it is to be in the cache even if you're on the Free plan. Lots of logic is applied to this, more than could fit in this reply. But importantly; there's no difference in how much you can cache between the plans. Wherever it is possible, we make the Free plan have as much capability as the other plans.
This does not confirm the exact statement but at least points in this direction.