It's a very mysterious bug. Now that I'm actually looking for it, I can't seem to reproduce it. There was a period of a few days where it happened about once an hour, but I thought it had something to do with my ad blocker. However, I'm traveling at the moment, so I'm hitting a different datacenter than when I first encountered the problem.
@mad409, could I bother you to visit
https://namepros.com/cdn-cgi/trace and give me the text from
visit_scheme=https
onward? For example, here's what it shows for me:
Code:
visit_scheme=https
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
colo=ORD
spdy=h2
http=h2
loc=US
When I'm at home, it would normally say
colo=EWR
--that's the code for the airport nearest the datacenter. EWR is Newark Liberty International Airport in Newark, New Jersey, US, whereas ORD is O'Hare International Airport in Chicago, Illinois, US. It's possible that some datacenters are triggering the issue while others aren't.
Another interesting component here is
http=h2
, which indicates my browser connected using HTTP/2.
@aramyus, you mentioned that webpages are bigger and bigger. In most cases, it's not actually the size that slows things down: it's the number of resources, where resources typically include images, scripts, and styling information. For each resource, your browser needs to make a separate request to the server, and this takes a lot of time because it typically needs to make these requests one at a time. HTTP/2 is a brand new protocol that NamePros uses to speed up this process: not only can your browser request multiple resources simultaneously on a single connection, but our servers will actually send your browser the most essential resources even before your browser knows it needs them. Most of these resources are relatively small; it's the back-and-forth that slows things down. By "preloading" resources, we can eliminate much of the back-and-forth. This is particularly effective on slow, unreliable connections, such as those used by smartphones.
If any of that was confusing, just know that
http=h2
means your browser and our servers are working together to load pages faster using a new technology.
This is important because when I experienced the bug, the time it took for text to be visible was roughly the same as the time the page would have taken to load without HTTP/2 preloading.
Three events happened around the time the bug started:
- Chrome v52.x was released.
- We upgraded the forum software.
- We implemented HTTP/2 preloading--note that basic HTTP/2 has been enabled for quite some time; the only addition here was preloading.
- We removed our script that was used to load resources faster on HTTP/1.1, as HTTP/2 obsoletes that script.
- CloudFlare has continually been adding and upgrading datacenters, as well as the software that handles HTTP/2.
Which one is the culprit?