The Dangers of B2B SaaS Website Bloat

The road for most B2B SaaS companies is long, and over a ten-year horizon, you may likely churn through 5-10 marketing leaders. Which is a lot. At the start, the marketing lead is likely to be pretty green and junior, and as you grow you can afford to move upmarket and increase the salary level attracting more senior marketers. 

Another common theme is that many B2B SaaS companies replatform every few years. This is sometimes linked to new marketing heads wanting to leave their mark, more budget available to retool (perhaps after an investment), or it may be due to growing pains with legacy systems. 

Finally, over the years a typical website journey may be from a custom build to WordPress to Squarespace or Webflow before ultimately turning to a Headless CMS-based solution.

A consequence of the high turnover in marketing, plus decisions made within the marketing team over the years relating to the Content Management System means that as every year passes there is a real danger that ‘under the hood’ the site becomes bloated leading to a degradation in performance.

That might mean the site has had too many third-party JavaScript resources added to the front end over time. This is often the case with sites that install Google Tag Manager and give unrestricted access to it to marketing personnel without having checks and balances in place. Oftentimes a site that has been revamped 3 or 4 times can end up with many widgets running on the front end that are no longer in use and ultimately just slow down the experience for end users.

The same can be true for third-party plugins in the CMS, like in WordPress and many other CMS’ many plugins don’t just add back-end code, they can often affect the front-end of the site as well, and this all adds up.

The growing range of issues with WordPress continue to grow, ranging from security vulnerabilities to lagging performance which also leads to a push factor with companies looking to migrate off WordPress. 

Google Tag Manager is a tag management system that lets you configure and instantly deploy tags on your website or mobile app from an easy-to-use web-based interface.

It is a common tool used on most B2B SaaS websites, and it is used to house 3rd party code and snippets for various applications. And boy do marketers have a choice of applications. A quick look at the Martech 5000 Landscape Portal will help to indicate the sheer array of marketing technology applications on the market.

Scott Brinker, the editor of the chiefmartec.com blog, first published a map of the marketing technology landscape in 2011 containing approximately 150 vendors. Over 10 years, that landscape has grown exponentially to include thousands of solutions from all around the globe.

—Source:Martech 5000

However, despite the benefits of Google Tag Manager, some inherent limitations are rarely discussed. The primary one is that once Google Tag Manager is installed, members of the marketing team can easily drop snippets in without ever considering the wider implications for the site. There is no built-in audit trail so each new arrival can just layer on additional code, and over time you end up with a bloated site where the latest marketing incumbent has no idea as to who installed which tags, why did they install them, and when?

Third-party tracking code is responsible for much of the increase in JavaScript weight on the internet.

—Source: Alex Zito, Software Developer

The popular tool Builtwith.com serves to illustrate the extent of the problem. Add a popular B2B SaaS Scaleup to the Builtwith.com site and you’ll likely find the “known number” of technologies will be within the 50-150 range depending on how well the site is maintained. That is a lot of 3rd party applications running on your site.

Of course, marketing can probably stand over the addition of every one of the technologies but deployment is usually a case of dropping a snippet of code into Tag Manager without any time spent assessing the impact (at the most basic level it could be slowing the site down significantly or conflicting with other code).

Regularly auditing how your website runs, physically runs with respect to your marketing needs, is a really good practice. If you carefully audit what is happening on the front of your site, then that allows you to keep the users of your website front and center.

—Source: Josh Angell, CTO of Contento

He goes on to outline some of the dangers associated with deploying Google Tag Manager without having proper processes in place to manage it.

When you add Google Tag Manager, you're giving admin access to the marketing lead. But what that then does is it creates a hole in the front end of your site for anyone who has access to Tag Manager to put whatever they like in.

A familiar path is that the initial Chief Marketing Officer (CMO), may install Google Tag Manager adding Google Analytics and perhaps an Intercom chat widget. They move on after a year or so and their replacement adds code from the likes of Crazy Egg, Bing, or Linkedin. A year later the new incumbent decides to replace Intercom with Drift (perhaps neglecting to remove the Intercom code.)

Because the developer has punched that hole in the front of the site, they're not getting consulted anymore about what happens inside that hole. It can then explode a huge bunch of front-end JavaScript into the front of the site, and that will inevitably slow down the front of the site drastically. Unless it's managed correctly,  it may even start to violate various things like your cookie policy or GDPR compliance. But you also end up finding that these third-party libraries start conflicting with each other and fighting with each other, which locks up browser resources because you've got two pieces of code that you can't see the results of fighting away. At this point, you have your front-end developers trying to ship a nice animation or something, and the site is juddering around and not working properly and it's because underneath there's all of this code firing away.

—Source: Josh Angell, CTO of Contento

In short, the problem while being a largely hidden one is pretty acute and one which is particularly common for those building on a WordPress base. When you consider a (marketing) function with high staff turnover, the lock-in of legacy CMS’ and a site packed with 3rd party code you are asking for trouble.

When it comes to WordPress, one of the most popular Content Management Systems on the market, the situation can be particularly painful. Common complaints about WordPress from marketing people include; poor site speed, admin access issues, and confusion caused by legacy plug-ins. 

When I first joined one of my jobs was to run the website and I was absolutely terrified. First of all, there were all these admins I didn't know in WordPress. I didn’t know whether I should be deleting these admins or not. There were so many people with access to the site I was thinking I don’t know all these people and that's a risk. One guy had been let go two years ago, and I feared he could just hack in at any stage.

—Source: B2B SaaS CMO

Taking the example of plugins alone. CTO of Contento, Josh Angell is particularly critical. 

You get serious bloat on the backend of the system where people are adding WordPress plugins left, right, and center. They don't understand that they affect the front of the site as well, but the bloat is coming from the back of the site. And the headless CMS model breaks that paradigm because it can't reach the front of the site. After all, it's an API. So the second part of the problem is bloat on the front of the site that's added directly to the front of the site.

Given the above pattern is so common (in terms of staff tenure and addition of 3rd party applications), the knock-on effects can be profound. As mentioned earlier, the issue is particularly pronounced for those running on WordPress. 

We had 70 plugins at one point and the site was so slow. I had to do a lot of work on the Largest Contentful Paint and to figure out why were key pages so slow and I quickly realized that less than half of these plugins, were required, secondly, some were conflicting with each other and thirdly, some were costing us money and we were no longer using them.

—Source: SaaS Head of Marketing

The key point here is that B2B SaaS scale-ups on a WordPress CMS, that have followed the ‘typical journey’ of high CMO turnover, married to the use of Google Tag Manager without constraints means that site performance will likely degrade significantly over time.

So what to do?

The following represents some of the key steps you should take to reduce the site bloat. 

1. Do an initial audit of Google Tag Manager and remove the vast majority of 3rd party code.

2. Lockdown Google Tag Manager so it is not easy for junior marketing people to add code.

3. Put a simple form together where any new code being added needs to include the following:

• Name of the person adding the code

• Date of adding 

• The purpose of the code

• Whether there is a specific duration that it should be added for

NB  GTM has an audit trail capability, but people often don’t fill in the reason why they have added a particular tag. 

1. Undertake Speed tests after any new code is added to ensure no major degradation in site speed.

2. Consider moving to a Headless CMS after you’ve cleaned up the above.  That will allow you to keep the front and back of your site separate, and ultimately stop the problem of third-party WordPress plugins causing bloat on top of Google Tag Manager etc.

At Contento we offer a complimentary migration service off WordPress or any other CMS for those who need a fresh start.

In short, given the common cocktail of a short tenure for most marketers, weak protocol when it comes to using Google Tag Manager, and the array of marketing technology solutions on the market it is all too easy for sites to become bloated and slow. Following the steps outlined above can alleviate the problem and help ensure that any future marketing leads are not having to spend a disproportionate amount of their time cleaning up a mess.