I’ve previously discussed when to use
<link rel="preconnect"> and how it’s often used incorrectly. I thought I’d give a more concrete example with Google AdSense.
AdSense is deployed on almost 12 million websites, according to BuiltWith figures for . Yet, only 352 websites out of the top 1 million websites deploy this optimization, according to a crawl of the Tranco list performed on .
Google’s page-loading performance review tools, including Google PageSpeed Insights and Lighthouse, agree that Google AdSense is terrible for page-load performance. However, there is one thing publishers can do to reduce its initial impact on page-load times.
For clarification, I’m talking about the modern asynchronous AdSense script and not any of the older variants. You should first update your implementation to use the modern async variant before thinking about reading this article. Your implementation should look like this:
As a quick reminder of what I wrote about
preconnect: web browsers will discover the above address as part of their normal preload document scanning/pre-processing. However, 510 out of the top 1 million websites scanned still included instructions to preconnect to this domain. This is 45% more websites than implemented the optimization properly.
The browser connects to and fetches the AdSense script as early as possible. However, the AdSense script then needs to connect to and fetch resources from at least five other origins. There may be additional origins required, but the following four are required globally.
These are the origins you should preconnect to:
In my web crawl, I only found 352 websites that implemented the above optimization. Interestingly, the majority of these websites were news websites from regions with low internet adoption.
You shouldn’t blindly implement the above pre-load list, however. You’ll need to perform periodic testing to confirm that the list is still accurate. Remember than an unnecessary preconnect negatively impacts performance.
Why not prefetch?
The above optimization should be okay with Google AdSense’s policies. You’re not allowed to modify their ad loading in any way. However, preconnecting to the required origins just primes the browser to more quickly fulfill an expected future task. It doesn’t change the final outcome or any properties of AdSense’s ad requests.
I’d recommend against switching the
preconnect directive for a
prefetch directive. The latter directive doesn’t just connect to a remote origin early, it tries to fetch a specific resource from that origin.
Prefetching resources improves performance even more than preconnecting. However, that approach might interfere with the request order and cookies that AdSense requires to fulfill an ad request.
The exact performance gain will vary greatly based on visitors’ network links. High-latency connections can be expected to benefit the most. This includes satellite connections, rural areas, and mobile connections in congested public areas, to name a few.
I implemented this optimization here on Ctrl blog in 2018. I don’t record detailed precise performance metrics on individual resource-loads. I can’t say for sure what impact this had on specific resources (such as the resources used by AdSense).
However, the mean page-load-time (including ad-loads) fell 402 milliseconds on mobile devices. It also fell 360 ms on other device categories.
Does such a small saving matter, though? Well, yes. Publishers are paid per impression. An impression requires the majority of an advert to be shown on screen for at least one second.
Google’s new performance goals as of require pages to load and be responsive in no more than 1 second to be considered fast. Page load speed impacts page ranking and revenue. 0,4 seconds saved is 40% of the total time budget!