Optimizing for speed using Cloudflare workers

Performance is a very critical part of an e-commerce business, for example:
Walmart found that for every 1-second improvement in page load time, conversions increased by 2%.

This blog post tells the story of some of the optimizations we learned/applied over the years for our e-commerce solutions Nisnass and Ounass respectively, starting with Cloudflare workers.

Problem

During the sales campaign (eg: White Friday), the load on the server will be huge and we used to get 504 Gateway Timeout impacting the sales. Also scaling up increases the cost factor as well.

Solution

We can either cache at the server-side or at Cloudflare itself, the latter will allow us not to worry about the load. You can read more about the worker from Cloudflare site.

Server-side cache

We already had a caching library in place and was working very well for us. The below diagram depicts how server-side cache works.

Caching using Cloudflare worker

We were already using the Cloudflare enterprise plan and it had the worker feature enabled, so we decided to experiment with Cloudflare workers.

It is better to read about Cache-control, as Cloudflare respects this header for deciding the cache and we make use of that to cache whatever we want.

First basic configuration in the Cloudflare fetch method

There is another useful option resolveOverride, which we are using, but am skipping as that is not related to caching.

In order for Cloudflare to cache, the backend must set the cache-control header in the response. So we created a function which when invoked will set the header. The below code sets the response header:

I am not explaining any of the above because you can read from Cache-control

res.removeHeader('set-cookie')

This remove header is added because Cloudflare does not cache when the set-cookie header is present in the response. Read the specification below to understand why

Set-Cookie

Now we got the page without any customer data, but we need to show the customer data as well. We make an XHR call that gets the customer data and renders after the page load.

After getting the response we update the state and since we use react and redux, the page will automatically re-render.

The below diagram depicts how caching is done.

Before Caching response time - taken by disabling the worker cache

The response time after caching

After cache response time

Do we need to handle any other use case?

Yes, we need to handle device type, marketing campaigns which appends parameters like (sub_id, cake_o, _ga, clickref, gclid, gclsrc, utm_) with unique value to the URL, filters which users apply, redirects. So now our worker code looks like this.

Cloudflare woker implementation

How long we should cache?

The cache duration depends on how frequent the update happens and how critical are those changes generally. So it is up to the business requirements and for us 10 mins for product details page and 3hrs for product listing page worked well.

Pagination

When a cached page supports infinite scroll, then all pages must expire at the same time. For this, we need to modify the backend logic where we set the cache-control header.

Conclusion

Kindly note that the post intentionally omitted much complexity of the worker code to keep it brief. Thank you for reading and stay tuned!!