flare.page

The table below shows how long it took for your device to download this page through Cloudflare.

The origin is hosted on an Amazon Lightsail instance in Tokyo, Japan and can be accessed directly at origin.flare.page.

The table below shows how long it took for your device to download this page which is hosted on an Amazon Lightsail instance in Tokyo, Japan.

It is also available through Cloudflare at flare.page.

What do the values in the table mean?

DNS (Domain Name System) shows how long it took for your device to perform a query to resolve either flare.page or origin.flare.page.

TCP (Transmission Control Protocol) shows how long it took for your device to connect to either Cloudflare for flare.page or AWS (Amazon Web Services) for origin.flare.page.

TLS (Transport Layer Security) shows how long it took for your device to negotiate a secure connection with either Cloudflare or AWS.

TTFB (Time To First Byte) shows how long it took for your device to receive the first byte of the HTTP (Hyper Text Transfer Protocol) response.

TTLB (Time To Last Byte) shows how long it took for your device to receive the last byte of the HTTP response.

Why do the values drop or rise when I reload the page and why are some values at zero?

If this is the first time you have connected to flare.page or origin.flare.page, your device needs to perform a DNS query and then connect to either Cloudflare or AWS. These steps don't need to be repeated for subsequent requests until the TTL (Time To Live) value for the DNS record expires or a new TCP/TLS connection needs to be opened.

When the DNS TTL value expires and/or a new TCP/TLS is opened, you'll see the values increase temporarily before dropping again. Try reloading the page a few times, wait 5 minutes and then reload again to see this happen.

When you see the DNS, TCP and TLS values at zero, you will also notice that the TTFB and TTLB values decrease. If there isn't a copy of flare.page cached in the Cloudflare location you are connected to, the page needs to be retrieved from the origin.

Once the page has been retrieved another request for that page will result in Cloudflare serving the copy stored in its cache. Cloudflare doesn't need to fetch the page from the origin for subsequent requests unless the page gets evicted from the cache or the Edge Cache TTL expires. Eviction happens when more popular content fills up the cache in that location.

Is it the exact same page that's being served when accessing through Cloudflare and direct from the origin?

Yes.

Although the two pages look different, they are exactly the same. Client-side JavaScript changes the colour and some of the content depending on what hostname is visible in the address bar of your browser.

How is your Cloudflare account configured?

The account is on the Free tier with a Cache Rule configured with an override for the Edge Cache TTL set at 2 hours.

Although suitable for this demonstration (the browser won't cache anything but Cloudflare will), it's probably sub-optimal for a production site.

How is your origin configured?

The Amazon Lightsail instance is running an Nginx web server on Linux (Ubuntu 20.04 LTS).

It has it's cache-control header set to no-store along with basic Let's Encrypt TLS configuration.

This site is only for demonstration purposes so there are no firewall rules preventing direct access. Doing the same for a production site is not a good idea as it would allow the security and acceleration services provided by Cloudflare to be bypassed.

Why is your origin in Japan?

The location was chosen as it is easier to illustrate the timing differences with somewhere that is far away from my base in Europe.

Why is flare.page faster?

flare.page is delivered through Cloudflare who cache content physically closer to end users in over 270 locations around the world.

Let's assume we're both based in London and no one else in our location has viewed the site. If I am first to view it, I ask Cloudflare for it, Cloudflare asks the origin (in this case in Japan) for it, the origin sends back the page to Cloudflare, Cloudflare keeps a copy and then sends it back to me. When you view the page, you ask Cloudflare for it, but, rather than have to go and get it from the origin, Cloudflare can respond with the copy it has stored in its cache.

Can I see which Cloudflare location I am connected to?

Yes.

In Chrome (on your desktop), whilst on flare.page, open DevTools (F12) and then reload the page. Within the Network tab, under Name, select flare.page and then Headers. Under Response Headers you'll see a header named cf-ray. The last three letters of its value denotes the closest airport to the Cloudflare edge location that you're connected to. For example, LHR is the IATA (International Air Transport Association) code for Heathrow. This would indicate that you're connected to Cloudflare in London.

Alternatively (in any browser), you can append /cdn-cgi/trace to any site that is proxied by Cloudflare and note the three letters after colo=. Visit flare.page/cdn-cgi/trace to see for yourself.

You can find a list of Cloudflare locations at cloudflarestatus.com.