Static content pages load much faster than websites containing dynamic pages and visual elements. WordPress is a CMS used by the majority of blog owners. This constitutes PHP code and database queries.
When a WordPress post is served to the visitor, it has to fetch resources from the server. The final front-end version of HTML content is displayed to the visitor. This takes a lot of time in rendering the pages. But WordPress has the benefit of ranking well in search engines.
Caching is a mechanism where most of your resources are stored as static content. When the first visitor requests your page, most of them are stored as cache. This is done using page cache plugins or server cache.
But still the HTML part has to be more close to the visitor location. Otherwise, fetching the content from the origin server will increase the load speed of the site. This is where edge servers and caching play a major role.
Table of Contents
Cloudflare APO – Why you need it
Automatic Platform Optimization (APO) is a new feature from Cloudflare. This was recently announced in 2020. It has the benefit of loading your page more quickly. There are about 200 data centers where the edge servers are residing. Your HTML content is cached in these server locations and distributed to your clients on request.
When the first request is made, all the server locations are updated with your post HTML content. This will make your WordPress site almost like a static site. Instead of doing the PHP code execution and database operations, the first page request is rendered quickly.
What is TTFB
The full form is Time to First Byte. This is the amount of time taken when a visitor makes a web page request to the first byte of data received from the server. This is very significant in page load speed of the site. The quicker is the TTFB, the faster the requested resource will be delivered to the visitor.
This generally consists of 3 components.
- The amount of time required to send the HTTP request from the client.
- The time required by the server to process the code, resources, CSS, JS and convert to HTML.
- The time needed to send back the first byte of the requested resources in HTML form.
The initial server request takes some time to respond. This can also be visualized using the GTMetrix test. The following is the screenshot for one of the web pages.
As you can see the total TTFB time is 116.8ms tested from the San Andreas, Texas location in the USA. The TTFB time consists of the following as measured by the speed testing tool.
- Blocking – 1.4ms
- DNS Lookup – 31.4ms
- Connection request – 38.8ms
- SSL request – 22.8ms
- Send the HTML request – 0.3ms
- Process and Waiting time of HTML – 28.9ms
- Receiving the first byte – 19.4ms
In most cases, when the Cloudflare APO is not enabled, the waiting and receiving time will be higher. This in-turn will increase the amount of TTFB and server response time.
Cloudflare APO – Benchmark Tests
In a recent blog post, it was mentioned that the edge server residing close to the origin server will not give much benefit from Automatic Platform Optimization feature. In order to test the benefit of APO page load speed has to be tested from different server locations.
But no practical metrics or proof were mentioned of the same in the article. Cloudflare blog post says that using APO will improve TTFB and FCP values. These are part of the new web vital statistics.
Without Cloudflare APO – GTMetrix Test Results
The first site was tested without using Cloudflare APO. All the other parameters were kept the same. The number of plugins, CSS, JS, images and are the same. In order to compare the efficiency of TTFB, FCP and other performance metrics, the same page with and without Cloudflare APO was tested using GTMetrix test.
7 different server locations were used for this test also. The following are the results.
TTFB and FCP Values – Different Server Locations
|S.No||Test Server Location||TTFB||FCP||Page Size|
|1||San Antonio, TX, USA||207.8ms||0.9s||24.3KB|
|2||Hong Kong, China||1.38s||1.8s||24.6KB|
|6||Sao Paulo, Brazil||342.9ms||1.7s||24.7KB|
Core Web Vitals
|S.No||Test Server Location||GTMetrix Grade||LCP||TBT||CLS|
|1||San Antonio, TX, USA||E||1.3s||1.0s||0.1|
|2||Hong Kong, China||F||2.2s||1.5s||0.09|
|6||Sao Paulo, Brazil||F||2.2s||0.6s||0.09|
Case Study – With Cloudflare APO
In order to test the above hypothesis, 2 sites were tested from 7 different server locations.
The first site was using Varnish cache and FVM cache plugin. It was on the free cloudflare CDN version. In addition the APO feature was enabled.
The second site did not have the advantage of server cache and premium optimization plugin. It had only free Cloudflare plan and PageSpeed Ninja plugin installed.
The original server was residing in the USA. So it is expected that US traffic will not have much benefit from the APO feature. Only distant server locations like UK, India, China are expected to see better values.
GTMetrix testing tool was used to measure the TTFB and core web vitals. This is a more thorough test giving different performance metrics and has the feasibility of testing the article from server locations around the world.
It was emulating the desktop page on Chrome browser version 86.0.4240.193 and Lighthouse version 6.3.0.
Since there were Google Adsense ads and Video ads displaying on the site, the grade was not that great.
The following were the core web vitals, time to first byte and gtmetrix grade scores.
Site #1 – windowstechit.com
The following is the URL tested.
|Test Server Location||FCP||TTFB||Initial Page size|
|1||San Antonio, TX, USA||1.1s||109.4ms||26KB|
|2||Hong Kong, China||0.6s||132.9ms||25.8KB|
|6||Sao Paulo, Brazil||348ms||142.6ms||26KB|
|Test Server Location||GTMetrix Grade||LCP||TBT||CLS|
|1||San Antonio, TX, USA||C||1.2s||264ms||0.1|
|2||Hong Kong, China||E||1.0s||1.9s||0.1|
|6||Sao Paulo, Brazil||D||0.6s||468ms||0.1|
Site #2 – wpreviewtips.com
The second site url.
|S.No||Test Server Location||FCP||TTFB||Page Size|
|1||San Antonio, TX, USA||1.0s||681.2ms||23.7KB|
|2||Hong Kong, China||1.1s||231.4ms||23.5KB|
|6||Sao Paulo, Brazil||383ms||165.9ms||23.5KB|
|S.No||Test Server Location||GTMetrix Grade||LCP||TBT||CLS|
|1||San Antonio, TX, USA||A||1.0s||68ms||0.33|
|2||Hong Kong, China||A||1.1s||0ms||0.02|
|6||Sao Paulo, Brazil||A||383ms||32ms||0.43|
Improvement in TTFB and FCP
After using Cloudflare APO there was reduction of time to first byte values by 75 to 330%. Without using the Cloudflare APO the values were between 200 to 450ms. Though this is of medium nature as compared to Google recommended values, they still could be reduced.
On enabling the Cloudflare APO, values decreased between 85 to 230ms. Except for 1 erroneous value, all the other server locations were displaying improvement in TTFB values.
The FCP values were also showing great performance. The values decreased from 800ms to 350ms in some cases. From 3 server locations the FCP metrics were higher using Cloudflare APO compared to not using it. The reduction in FCP was between 25% to 500%. The increase was between 20% to 30%.
In some cases, the values decreased to 373ms. Without using this service from Cloudflare the values were between 800ms to 1700ms. On using the APO feature, they reduced to 360 to 600ms in some cases. A clear pattern could not be seen. So the conclusive evidence that FCP values will reduce cannot be deduced.
- All the GTMetrix grade scores were either D or E for site 1. The second site had a perfect grade of A. The video ads and display ads were spoiling a perfect score for first site.
- Time to First Byte (TTFB) times were between 65ms to 365ms. There was a lot of variation in these values when tested from different server regions.
- Though both sites were having the same initial page size, the first site was displaying lower TTFB values compared to the second site. This can be attributed to the Varnish and FVM cache plugins installed on the first site.
- TTFB values were less when using the APO service. The least value was from the London server. The maximum value was from a Canada server. This was for the first site.
- Though Canada was next to the USA, it is surprising that a higher value was recorded.
- Sydney and London were having the least TTFB values for both the sites.
- The size of the initial page was almost equal from all the server locations.
- FCP values were also lower, but were showing variation like TTFB values.
- FCP metrics were lower from London and Brazil locations for the second site.
- The least FCP were from Brazil and Sydney for the first site.
- CLS values were almost constant from any server location.
As seen above, TTFB values decreased when using the Cloudflare APO. But change of test server location had significant influence on those values. Some of the Core Web Vitals were also difficult to understand based on the server location.
Even though there are 200 data edge centers around the world, the same performance metrics were not recorded. This is an interesting observation from a server location point of view. Also, the theory that an edge server close to the origin will have better TTFB is also not correct.
In order to better understand TTFB and FCP values, tests need to be conducted without APO from the same server locations. This will give a better idea of the benefit of using Cloudflare APO.