More often than I'd like I encounter a bit of the internet that either isn't clear, isn't useful, or isn't working properly. Occasionally I get frustrated enough to write about it. This week: the Boots.com login page.
This one isn't entirely the fault of Boots. But it raises some interesting questions about how websites are maintained over time.
The page in question is the log in/register page, which can be found from the link 'Log in/register' at the top of most of the pages on boots.com. The problem I was having was that it wasn't loading correctly. The site header and footer were present, but no content appeared between them. It looked like this.
Jump straight to... the actual problem
The cause of the missing page content was an adblocker that I was using on my network. When I disabled the adblocker, the Boots login page appeared correctly.
This isn't good. Lots of people use adblockers, which means there are lots of potential Boots customers that could find this problem, assume the Boots site is broken, and go straight to a competitor instead.
The good news (for Boots) is that the login page doesn't appear to be essential functionality. If you add a product to your basket and attempt to checkout you get sent to a different login/checkout as guest page, which isn't affected by my adblocker.
This still raised some questions. Why would an adblocker prevent the login page from rendering correctly? And what exactly was being blocked that was causing this problem?
Console output
The first thing I did was open Chrome dev tools to have a look and see whether there were any console errors. There were pages of things in there.
- 7 cross origin requests that had been blocked, mostly to a domain called dpm.demdex.net but also to ct.pinterest.com
- 20 ERR_CONNECTION_REFUSED messages, referring to requests from a wide range of domains
- a single 404 error from a URL on example.com
- numerous errors presumably relating to the refused connections (some of the messages contained text similar to the domain names)
- a lot of XHR failed messages
- 9 groups of console.log output saying no match punctuated by the other messages, each containing 48 duplicate messages
- one final group of log output no match messages, which seemed to be endlessly repeating (in the time it's taken me to write this list the count has reached 35,000)
- other miscellaneous messages, including a series of messages that seemed to be counting up from -7 to 0 for no obvious reason
These messages seemed to be unrelated to my adblocker - when I disabled it and the page loaded as expected, it was all still there.
Page size
None of this got me any closer to an answer but I was interested enough to dig a little deeper. Next I checked the Chrome dev tools Network tab. There was a lot of stuff in there too.
- 173 total requests (this number occasionally varied when reloading the page)
- 3.5 MB transferred (the compressed size of the data received)
- 14.3 MB resources (the uncompressed size of the data received)
- numerous failures
These numbers were unsurprisingly higher when I disabled my adblocker.
- 228 total requests
- 5.1 MB transferred (compressed)
- 19.1 MB resources (uncompressed)
Since these kinds of problems are often related to JavaScript, here's the same details for the JavaScript alone.
- 88 requests
- 2.8 MB transferred (compressed)
- 10.6 MB resources (uncompressed)
That is a lot of JavaScript.
Other page sizes
Turns out that this page size is fairly normal for the Boots site. Here are the numbers from the homepage (for all request types).
- 233 requests. No wait, 234. No wait... (I'll come back to this)
- 5.2 MB transferred (compressed)
- 16.3 MB resources (uncompressed)
- numerous failures
The number of requests kept slowly ticking up as I read the data. The homepage appears to make a request to a domain called edge.curalate.com every ten seconds, for what looks like a PNG file, which could be for tracking purposes. If it does relate to tracking it's unusual - things like this normally trigger in response to user behaviour. Making endless requests like this after a page loads is a little strange.
I'd expect the homepage to be larger than the login page, as homepages for shop sites are usually filled with images and other content. However the images made up only 1.5 MB of the total page size of 5.2 MB. The majority of the page weight was again taken up by JavaScript.
Request origins
Chrome dev tools has a nice little feature to show only 3rd party requests. That means assets that are requested by the page that do not belong to the page, such as external trackers or plugins.
The Boots login page makes 173 requests and 91 of them are 3rd party requests. This included a few things I knew about, like PayPal and Google Tag Manager, but many I didn't recognise.
Builtwith
I then turned to BuiltWith, an online tool that can quickly find out a lot about how a site is put together. You can read BuiltWith's complete profile of boots.com here, but here are some observations.
To start with, there's a very large amount of analytics. Fifteen different trackers, including Adobe Marketing Cloud, Google Analytics, Google Conversion Tracking, Facebook Signal, Facebook Pixel, and Google's Global Site Tag. I'd really like to know why Boots needs 15 trackers. For comparison, www.gov.uk (with over 500,000 pages) uses just one tracker.
BuiltWith also identifies fifteen JavaScript libraries and functions on the page. Some are small and common, like html5shiv, but others are larger and more heavyweight:
BuiltWith doesn't report it, but the JavaScript also includes jQuery. It's an old version (1.11.3) and it's being hosted on the Boots site (rather than being pulled in from a CDN).
Again, that's a lot of JavaScript. What I find strange about this list is the number of tools that would ordinarily be enough to build a site on their own - for example, React.
Some very rough performance testing
On my (decent) wired broadband connection it takes nearly four seconds for the content of the page to appear. Artifically throttling my connection using Chrome's dev tools to slow 3G resulted in a time of more than 45 seconds before the page header and footer appear. But it takes more than one and a half minutes before the actual page content appears.
That's not fast, and it's definitely not as fast as it could be.
Thoughts
Making an online shop of any size can be a complicated task, often requiring complex solutions to complex problems. I am sympathetic - I've worked on similar sites. But there are a lot of things here that immediately cause concern. Companies need to understand that the speed of their site matters - especially if a competitor is faster.
I don't know anything about the Boots site other than what I've written above so I can't explain anything that I've observed. My only comment would be that maybe someone in the company should be asking some questions, like are all of those JavaScript libraries and analytics products really necessary?
But what was actually causing the problem?
Sadly I wasn't able to discover the cause of the original problem, partly because wading through all those requests and files was a huge task but mainly because during my investigations the login page started loading properly even with my adblocker enabled. I don't know why.
I'll leave you with more more observation. The Boots site sets 26 cookies in your browser before it asks for permission to do so. If you accept cookies, it sets another 16.