How do we address high availability of web projects? And why are we leaving CloudFlare?
After years of using CloudFlare as our preferred solution for ensuring high availability and speed of websites, we are leaving this service and replacing it with our own resources.
What is CloudFlare?
CloudFlare helps to speed up the loading of websites. One of the main ways it achieves this speedup is by reducing the amount of data transferred between the user’s browser and the server where the website is hosted. CloudFlare downloads individual pages, images and other files from the original server. These are then cached on powerful servers. The nearest server then provides the user with the web content in the shortest possible time. CloudFlare is distributed globally, so it ensures very high availability of websites from anywhere.
How have we used CloudFlare at TRITON IT?
From time to time we are approached by companies who want us to take over and manage their existing website, portal or online service. If the owners of these websites did not want newer ones created, but only existing ones serviced and made faster, deploying CloudFlare has helped eliminate many performance ailments and improve Google Page Speed rankings. Another case was deploying CloudFlare on any new web portals, presentations or microsites we created. We first set all Page Speed parameters without CloudFlare deployed and then activated it.
Why are we leaving CloudFlare?
CloudFlare has evolved over its lifetime. Today it is a robust service with paid tariffs. While there is one plan on offer that is free, it is very underpowered for the needs of customers. In fact, only the pay-as-you-go tariffs deliver real benefits and significant data speeds. For a few projects, we started to see that from a certain scale of web presence onwards, CloudFlare’s unpaid plan becomes more of a liability than a benefit.
To get a better idea of this change, here are a few specific examples where switching from CloudFlare to in-house tools has meant a significant shift forward for clients.
Case study 1: LPP Group website
The LPP Group’ s web-based product catalogue is hosted in 12 countries, contains 17 languages and thousands of different web pages generated from up-to-date product information. The input requirements were limiting for the performance of this website:
- The client required a widely known CMS system to provide administration of the products and pages of the site.
- But it also needed to create complicated, dynamic links between such products and other content.
CMS systems typically store data in a very generic data model that cannot capture such complex links efficiently. To achieve good site speed, it was therefore necessary to use object caching.
What is a CMS?content management system, the name given to software that allows you to organize, create, and efficiently maintain text and pages of a website
The hardest part of working with a cache is always sorting out its so-called invalidation, which means making the right decision when the cache is already obsolete and needs to be replaced with a new one. CloudFlare’s free plan was able to solve this, but only up to a certain number of pages on the site. When it reached approximately 500 different pages in the cache, CloudFlare Worker no longer had enough time to run invalidation. As a result, visitors could be shown outdated versions of individual products. The solution would have been to switch to a paid CloudFlare plan, but since the LPP web application runs on 6 different web domains, the cost of running the paid plan would have multiplied 6 times. Under such conditions, it was more profitable for LPP to resort to a solution on its own hardware, which we built for it on a turnkey basis.
Specific example 2: MISURA website
The website hosted on the misura.store domain serves as the official information website of the MISURA brand, a guide for users of MISURA products, and last but not least, the main source of organic traffic.
In order for its ever-growing number of pages in 7 languages to be displayed at the top positions despite the high competition, it is necessary to keep the TTFB (time to first byte) and FCP (first contentful paint) metrics and FID (first input delay) values in Pagespeed and Search Console as low as possible.
It turns out that TTFB in particular is closely related to server load and availability. By repeated measurements over a 14-day period, we demonstrated correlations between server load and the number of web page views in search results reported by Google PageSpeed. However, TTFB did not change significantly after moving to a more powerful server. CloudFlare was again to blame, as it prioritizes site availability according to the level of the paid plan. Thus, the non-paid plan doesn’t get enough priority to significantly reduce TTFB, even when full-page caching is enabled. Again, it was more beneficial for the client to back out of using CloudFlare.
Specific example 3: RI OKNA website
For the RI OKNA website, CloudFlare helped bridge a period when a new website was being developed and an older version of the website had to be maintained for which there was no documentation. CloudFlare’s anti-spam protection service successfully helped us fend off form spammer attacks without having to interfere with the website code.
Unfortunately, after the transition to the new website, we again faced the same situation as MISURA – a limitation in the TTFB metric. Since RI Okna, like LPP, was planned to operate on 6 different domains, each of which was to work for one market and language, we had to abandon the idea of using a paid plan.
Building our own resources
By giving illustrative examples for each client, we can declare that CloudFlare does help bridge the period when certain specific websites are outdated and very difficult to work with, but on the other hand, it also brings some disadvantages. A significant disadvantage is that CloudFlare prioritizes the availability of sites according to the level of the paid plan, and thus the non-paid plan does not get enough priority to significantly reduce TTFB. Even in the case of caching, CloudFlare did not perform well in the free plan because it was only able to address cache invalidation up to a certain volume of sites. After that, it was again necessary to switch to the cost-ineffective paid plan. This is not the only reason why we at TRITON IT decided to invest in our own high-performance hardware, which we host in cooperation with Czech Radio Telecommunications. For more demanding clients and clients who care about excellent organic results in search engines, we are thus able to provide high web availability as a turnkey service. And thus provide customers with greater benefits, not only in terms of performance, but also financially.