Reduce the impact of third-party code

Reduce the impact of third-party code

Your site is beautiful, your marketing department is on fire, you’ve got a rocking online presence, and you know it because of all of the tracking and retargeting pixels that you’ve placed in your site.

There’s just one problem, your site is taking forEVer to load.  And, upon closer inspection, Google PageSpeed Insights is telling you that third-party code blocked the main thread for a reDICulously long period of time.  What the… blazes is going on?

Third Party Code: So Much Functionality, at a Cost

So you’ve got yourself a Google Tag Manager… that’s loading in Google Analytics, and a couple of other things your marketing team absolutely HAD to have.  Oh, and you added that one plugin to change your phone numbers to a special phone-number tracking service.  Can’t forget that you added the Facebook Pixel as well, for retargeting purposes.  Gosh, there was also Hotjar that you added, and Yandex…  and… and… and the list goes on and on.

So much functionality!

But with much functionality comes many CPU cycles.  That magic doesn’t come without a cost.  And that cost is CPU cycles that block the main execution thread of the web browser.

Each third-party service that you add in likely loads a javascript file, which then itself probably loads a number of other files, sets cookies, modifies the web page, and all sorts of other executions which tie up the web browser.

And that is why we get this warning about third-party code blocking the main thread.

Reducing the Impact: Can we?

The short story is “YES! WE CAN!”, but there’s a catch.

First, you should probably go through and audit your page, and first get rid of all the third-party scripts you absolutely don’t need.  But once you’re done THAT, then how do we go about reducing the impact?

Well, the obvious answer is “delay it”.  If it’s a service that does not modify the DOM (web page), then it probably doesn’t really matter when the code finishes executing.  Many third party scripts already have the async attribute applied, which means “finish when you finish, it matters not to me, but just finish quickly”.  Really, “async” means, load in a non-blocking manner, in parallel with the rendering of the web page, and then execute when you’re done with the loading of the Javascript file.

So, what if we “delayed” the execution of that script for a brief period, to allow the critical rendering of the page to complete?  Would there be really any impact to the usability of the third-party script?  Probably not.

Reducing the Impact: We did.

This is what we do in our Pegasaas Accelerator WP plugin for WordPress.  We tell those scripts to “wait just a second (sometimes a bit longer)”, and then load.  This allows the main thread to quiet down, and those third party scripts can still collect all of their data as necessary.  We even build in the ability to turn this feature off for a number of known third-party services if you find that it impacts the usability of that service.

So, if you are experiencing this warning, and you’re running WordPress, I’d recommend signing up with our free trial to see how fast Pegasaas can make your website.  If you find it isn’t absolutely amazing, you can cancel at any time.

Photo by Saad Chaudhry on Unsplash

Comments are closed.