Back in the days, when improving the performance of our business CMS, we wanted to cut away as much overhead as possible. No necessary resources or DNS lookups, but also reducing cookies.
Once the server sets a cookie for a particular domain, all subsequent HTTP requests for that domain must include the cookieKinsta.com
Without getting to technical, this involves extra time while loading all resources, called network latency. For every new pagehit! The median amount of resources within a mobile website is 69. This will result in network latency equal to 69 times the total amount of cookie-bytes;
How to solve network latency due to cookies
Whoever tested their website on sitespeed will recognize the advice of GTmetrix to serve static content from a cookieless domain. A Content Delivery Network (CDN) can be an example of such a domain. This may cost an extra bit of money and work for custom resources, as you need another server and extra configuration for optimal synchronization of your static resources.
You may want to use a CDN, when having a big or international webshop or millions of visitors.
Easy performance fix against cookies
So, is there an easier way to fix this network latency due to cookies, without radical or additional maintenance? Yes, there is. For websites build on top of the Blue 2 Blond CMS, we configured the following:
- Send your dynamic content (like productpages, articles and other content) over the www subdomain;
- Send your static resources over the naked domain (domain without www prefix).
Cookies set on your www environment, aren't allowed to be send along with your static content. No more network latency due to cookie transfer!
But one can configure cookies in such a way, it may only be set and thus send with file request within the same (sub)domain. And the best part: this is even feasible on average hosting: no special hosting, htaccess or external configuration required.
When this gets interesting
Applying this technique gets interesting when your website or webshop is serving a lot of cookies and your shop has a lot of resources from the same domain.
Although HTTP/2 technique will handle multiple requests simultaneously (multiplexing), HTTP/2 itself will not necessarily fix your network latency due to cookie-usage. For example:
- Your website should be served over the https protocol;
- Combination of browser and device used by your visitors have to support HTTP/2 as well.
As HTTP/2 support is quite wide for some time, the impact will be quite limited as well. Moreover, the combination of cookie-bytes served in combination with the amount of (own) resources, will be responsible for the level of impact on network latency and thus the performance of your website or webshop.
This means this might be interesting for either:
- bigger and more international shops where one doesn't always know what kind of devices are used by their visitors, or;
- dev teams and Web Performance Optimization specialists who want to address every aspect of web performance.
In a case study I did last year, a webshop productpage was sending 303 bytes of cookies. With a total of 174 requests, 117 own requests were accompanied with cookies. This could add up to a network latency of about 117ms, on slow internet connection.
That's a shame, as Amazon found that a 100ms increase in response time resulted in a 1% decrease in sales. Easy way of fixing this conversion drop!
Want to know more about cookies and network latency? Check this explanation of the cookie impact on your performance.
Set it up yourself
You want to achieve this too while using a CMS? Do the following:
- Let your CMS handle your www redirects for content pages;
- Be sure to Serve all static resources over the naked domain within your HTML source. You could use regular expressions or DOM manipulation to replace this;
- Pro tip: add a DNS-prefetch or preconnect resource hint to your naked domain.
Naked domain looks better
Are you in the naked domain camp, because of estethic reasons? Get prepared to leave the camp, as Google Chrome already stopped showing the www prefix altogether once again. They did it before in 2018 (version 69), rolling it back after negative feedback.
As Google Chrome rolled it out in version 79 again, the naked domain is a fact, even when the website itself is on the www subdomain. So
So, even when you don't have a big webshop, soon there is no reason for having a slow or less converting website due to high network latency with the advice above!