My company's site uses Google Publisher Tags (GPT) to display Google ads on our pages. As we've been trying to improve our page speed lately (trying to improve our PageSpeed Insights/Lighthouse metrics), I noticed we're getting this "opportunity":
Remove unused JavaScript
/gpt/pubads_impl_2021030801.js?XXXXXXXX (securepubads.g.doubleclick.net)
Our situation is that we show our ads (Google or otherwise) based on screen size: on a given page, we may show a Google ad on mobile-sized screens in a given space on the page, but show no ad--or a non-Google ad--on larger screens.
What I'd like to prevent is loading the GPT library altogether on pages at screen sizes where we show no Google ads, since it will not be used. We currently load the library statically (and asynchronously), per Google's recommendation: <script async src="https://securepubads.g.doubleclick.net/tag/js/gpt.js"></script>.
Is it possible to conditionally load this library based on screen size (via JS/media queries/Accept-CH??) without flagging the "Load ad scripts statically" audit? Or is breaking this "rule" and injecting the script inline in the based on a viewport size check less egregious than the PageSpeed Insights "Remove unused JavaScript" fail?
I'm leaning toward prioritizing page speed (and trying the injection), but I don't really understand the consequences of not loading the GPT library "statically."
There is no issue adding a script based on screen size, you can still add the async (or defer) attribute to it so it isn't blocking.
There is no impact (other than the library may load slightly later depending on where you place the JavaScript below, I would recommend having it within inline script tags on the page so you don't have to wait for a network request before the script is added) on how the library operates.
The main issue is if you have a Content Security Policy you may have to use a different solution.
I will assume you are not using a strict Content Security Policy in the following code snippet.
The only other thing to be aware of is that if you do load this in the wrong place in the document (too early or too late) or via an external script, that may negatively impact performance so you just need to keep an eye on that. As such I would put it in the exact place where the script would have sat before inside inline <script></script> tags.
const screenWidth = window.innerWidth || document.documentElement.clientWidth || document.body.clientWidth;
if(screenWidth < 1024){
let script = document.createElement("script");
script.src = "https://securepubads.g.doubleclick.net/tag/js/gpt.js";
script.setAttribute('async', true);
document.body.appendChild(script);
console.log("Added script");
}You have things back to front from a performance perspective.
Smaller screen sizes tend to be less powerful devices and possibly on 4G / 3G connection.
Showing adverts to smaller screens and not on larger screens is the exact opposite of what you should be doing from a performance perspective. Adverts tend to be very resource heavy!
If you rely on ads for revenue, you might as well show them at all screen sizes, if your viewership is 50% mobiles, 50% tablets desktop then you may consider reversing that decision so that ads show on desktop and not on mobiles.
If performance is key to you but ads have to stay on mobile, then I would consider delaying the ads script (not the analytics script shown) using a very similar method to the above but with a setTimeout delaying the script being added by 3-5 seconds instead of checking for screen width.
This let's the page render and become interactive before adding heavy lifting such as adverts.
Obviously if you do this then you must ensure you have allocated enough space on the page for the advert(s) to avoid Cumulative Layout Shifts.