The Problem
A particularly difficult issue facing developers is the liberal use of third-party scripts for marketing purposes or third-party content. For example, Google Analytics might be added to provide marketers insight on how their users are interacting with their product. Another example, which will be our focus, is when there is embedded content like a form from a digital marketing service like HubSpot.
The Impact on SEO
We use Google’s PageSpeed Insights for useful, detailed breakdowns of page performance. The service gives your page an overall performance score (out of 100) and provides suggestions for improvement. Google takes page performance into account when ranking sites for search results, so it’s crucial to optimize page load.
Third-party scripts may have a negligible file size, but they are still scripts that need to be evaluated. Google weighs its score heavily on how long it takes to load and execute these scripts during the initial page load. Unfortunately, third-party scripts can subsequently load even more scripts, each of which needs to be downloaded and executed as well.
The Solution
At Imarc we’ve seen as much as 20-30 point improvements in PageSpeed scores when optimizing how third-party scripts are loaded. One of the worst culprits we’ve had to contend with is a video streaming service called Wistia, a service built for marketers that comes with tools to track and convert users that interact with their videos.
Wistia uses a more modern embed code that doesn’t utilize an iframe. Wistia’s embed code is a script tag that, once loaded, fetches a lot of other scripts that slow down the initial page load. The solution here is to only load this script when a user requests a video, then, using Wistia’s API, request the specific video the user wishes to view.
For example, let’s assume the site is on a CMS and the content manager simply pastes a video ID to be used. Note that while not all content creators know how to grab and paste only the video ID for the corresponding video, a variation of the following method could still be implemented in a similar fashion by extracting the ID out of the URL in code.
We store the video ID in a data attribute on a button or thumbnail which we tie to a click event. We are also tying this to Wistia’s own popover content embed trigger so that after the first request, resources aren’t requested again should a user watch the video a second time.
Now we insert the dependant scripts Wistia requires and populate it to the DOM. We make sure to add a conditional checker for later so the script knows whether it has already requested its dependencies.
Finally, after the dependent scripts are loaded, the Wistia API will emit an event saying it’s ready. We can then hook on to load the requested video using Wistia’s own API methods. We’re also triggering a modifier class on the button to show some loading feedback while it fetches the resources it needs.
Success!
The page now has the resources it needs to play the video while avoiding any of the legwork on initial page load. This is a good example of how we go about solving these performance problems and how it relates to third-party, embedded content.
