Why do recipe sites load so slowly?

The text arrives. Then the layout shifts as an ad loads in. Then another shift as the video unit appears. Then a cookie banner. Then, several seconds after you tapped the link, the page is more or less stable — until you scroll down and the next set of ads fires. On a slow mobile connection it can feel like the page never fully settles. The recipe is there, technically, just buried under everything else finishing its load.

How ad tech slows the page

Header bidding: before a single ad appears, the page runs a real-time auction among multiple ad networks to find the highest-paying buyer for each slot. This happens in milliseconds but involves requests to several external servers simultaneously. The auction has to finish before the ad loads, and the ad has to load before that section of the page is stable.

Multiple networks, multiple scripts: most large recipe sites connect to several ad networks at once to maximise fill rate and CPM. Each network ships its own JavaScript, which runs in the background whether or not it wins the auction. Five networks means five scripts, each making its own set of requests.

Tracking layers on top: analytics, audience segmentation, and retargeting scripts sit on top of the ad stack. These run separately from the ads themselves and add their own weight to the initial load.

Layout shift: ads load after the article content because they depend on auction results that are not known when the page first renders. The content draws, then moves as ad containers fill in — which is why the page jumps under your finger while you are trying to read it.

Why it keeps getting worse

• CPM compression drove density up: as static display rates fell over the past decade, publishers added more units per page to maintain revenue. More units means more requests per visit, which means slower pages.
• Mobile traffic grew but mobile pays less: more readers switched to phones, where CPMs are lower. Sites responded by adding units rather than reducing them, compounding the problem on the devices where page weight hurts most.
• Ad tech consolidated and added complexity: header bidding itself was an improvement on the old waterfall model, but it added latency in exchange for higher yields. Every optimisation in the ad stack tends to add a layer rather than remove one.
• Google Core Web Vitals pressure is partial: there is some ranking incentive to improve page speed, but it competes directly with ad revenue. Most sites have found a floor they can live with rather than optimising past it.

What you can do

Ad blocker on desktop: uBlock Origin removes most third-party ad scripts before they load, which substantially reduces both the number of network requests and the layout instability. On desktop with a supported browser, the difference is significant.

Reader mode on mobile: iOS Safari and Firefox for Android have reader modes that strip the page down to article content only. The page still has to load first, but you can escape the shifting layout once it does.

The structural fix is a site that does not run ad tech at all. NoAdsCooking loads what the page needs — text, a few images — without the auction layer underneath it. There is nothing to bid, nothing to track, nothing to shift.