Page speed is a direct response problem
With paid traffic, every second of load time costs money. The biggest offenders on VSLs and landing pages, and how to fix each one.
By Pedro Craveiro · · 4 min read
On a corporate website, a slow page is an annoyance. On an offer running paid traffic, it's a loss: you already paid for the click, and every second of waiting raises the chance the lead closes the tab before seeing the offer.
Where direct response pages usually get heavy
Video players loaded too early
The VSL player is usually the heaviest thing on the page. Loading player scripts, thumbnails and fonts before they're needed delays what the lead sees first.
What to do: prioritize the first fold, use a lightweight thumbnail as a placeholder and load the player without blocking rendering.
Unoptimized images
Huge images exported straight from the design file are common on advertorials and long landing pages.
What to do: serve modern formats (WebP/AVIF), responsive sizes and lazy loading for everything below the fold. In Next.js, the Image component handles most of this.
Too many third-party scripts
Pixels, heatmap tools, chats and A/B testing scripts pile up with every campaign.
What to do: regularly review what's still in use, load non-critical scripts after interaction and centralize your tags.
Render-blocking fonts and CSS
Multiple font families and unused CSS delay the first paint.
What to do: limit fonts, self-host them and ship only the CSS the page actually uses.
Measure before and after
Lighthouse and Core Web Vitals help you see the problem, but the metric that matters is the operation's: play rate, VSL retention and conversion. Optimize, ship and compare.
Speed isn't a technical detail. In direct response, it's part of the offer.