Landing Page Speed Kills Conversions: 4 Data Points and How Claude Code Fixes Them in One Pass
A 2-second load time cuts conversions in half. Four speed-to-CVR data points and how to fix them by pasting your Lighthouse report into Claude.
A 2-Second Load Time Is Costing You Half Your Conversions
Here’s a number that should bother you: at 1 second of page load time, the average conversion rate is 3.05%. At 2 seconds, it drops to roughly 1.5%. At 4 seconds, you’re looking at about 0.6%. That’s not a gradual decline — it’s a cliff. And most landing pages are sitting somewhere between 2 and 4 seconds right now, quietly bleeding leads while their owners obsess over headline copy and button colors.
The data comes from a study that Jono Catliff, who built and sold a seven-figure service business largely on the back of high-converting landing pages, cites in a recent walkthrough of his full landing page stack. He spent $171,000 on a single Google Ads campaign. He also drove 1,500 organic clicks per day through SEO. All of that traffic pointed at landing pages. Which means page load speed wasn’t an abstract technical concern — it was a direct multiplier on every dollar he spent acquiring traffic.
The math is brutal when you work it out. If you’re paying $10 per click and your page loads in 4 seconds instead of 1, you’re effectively paying $50 per click in real terms. You haven’t changed your bid. You haven’t changed your audience. You’ve just let your server be slow.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
What’s interesting is that fixing this used to require knowing what “render-blocking requests” and “LCP request discovery” actually mean. Now you paste a report into Claude and iterate until the number moves. Catliff went from a Lighthouse score of 90% to 95% in a single pass. That’s not a complete solution — but it’s a meaningful one, and it took about as long as writing a Slack message.
Here’s how the whole thing works, from the data to the fix.
The Four Numbers You Need to Internalize
The conversion rate curve isn’t linear, and that’s the part people miss. It’s not that each additional second costs you a little more. Each additional second costs you proportionally more than the last.
At 1 second: 3.05% CVR. At 2 seconds: roughly 1.5% — about half. At 3 seconds: roughly 1% — another third gone. At 4 seconds: roughly 0.6% — you’re now at about 20% of what you’d have gotten at 1 second.
Think about what that means in practice. If you’re running a campaign that sends 1,000 visitors to your page per week, a 1-second page earns you about 30 conversions. A 4-second page earns you 6. Same traffic. Same ad spend. Same copy. Just a slower server and some unoptimized images.
The culprits are almost always the same: large images, uncompressed video, JavaScript that loads before the page renders. In the past, diagnosing and fixing these required someone who knew what a “network dependency tree” was. That’s no longer the barrier.
Google Lighthouse Is Already in Your Browser
You don’t need to install anything. Google Lighthouse is built into Chrome DevTools — the same panel you open when you right-click and inspect an element.
To get there: open Chrome, navigate to your landing page, click the three-dot menu, go to More Tools, then Developer Tools. Inside DevTools, click the double-arrow icon (>>) to find the Lighthouse tab. Hit “Analyze page load.” Lighthouse will run a diagnostic and return scores across four categories: Performance, SEO, Accessibility, and Best Practices.
The one you care about right now is Performance. Lighthouse will give you a score from 0 to 100 and a detailed breakdown of what’s dragging it down — things like “Reduce unused JavaScript,” “Improve image delivery,” “Eliminate render-blocking resources,” and a dozen other items that are specific, actionable, and completely opaque if you don’t already know what they mean.
Here’s where the workflow changes. You don’t need to understand any of it.
The One-Pass Claude Fix
Catliff’s method is almost embarrassingly simple. Open all the diagnostic tabs in the Lighthouse report. Scroll to the bottom. Select everything — the entire report output. Copy it. Paste it into Claude Code with a single prompt: “Here’s the Lighthouse report. Can you optimize for page load speed? Can you also optimize for desktop, tablet, and mobile devices?”
That’s it. Claude reads the report, understands which files are causing which problems, and makes the changes. In Catliff’s demo, a page that scored 90% on Performance jumped to 95% after one pass.
If it doesn’t hit 100%, you run it again. You paste the new Lighthouse report back into Claude and say “we’re at 95%, get this to 100%.” You iterate until you’re satisfied. No knowledge of minification, caching headers, or image compression formats required.
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
This is the part that’s genuinely different from two years ago. The Lighthouse report has always been free and always been accurate. The bottleneck was translating its recommendations into code changes. That translation layer is now handled by the model.
For context on how Claude Code handles different levels of complexity in these optimization tasks, the Claude Code effort levels guide is worth reading — some Lighthouse fixes are trivial one-liners; others require the model to reason through dependencies.
The Environment That Makes This Possible Without Coding Experience
The setup Catliff uses is worth spelling out because it’s genuinely accessible to people who have never written a line of code.
The host environment is Antigravity IDE — a free Google desktop app that functions as a coding workspace. Claude Code runs as a plugin inside it. You search for “Claude Code” in the plugin panel, install it, and you’re working in an environment where Claude can read, write, and modify your project files directly.
Every project lives in a folder. Inside that folder, you add a claude.md file — a configuration document that tells Claude how to behave on your project. Think of it as onboarding documentation for a contractor. Catliff makes his available through his free School community, and it’s specifically tuned for web projects: it tells Claude what stack to use, how to structure components, how to handle mobile responsiveness.
The design input comes from Dribbble. You search for a design that fits your industry — “landscaping website,” “service business landing page” — screenshot something you like, and upload it to Claude with a prompt asking it to replicate the design. Claude builds the initial page from the visual reference.
From there, the Lighthouse optimization workflow slots in naturally. You build the page, check the Lighthouse score, paste the report into Claude, iterate. The whole loop runs inside Antigravity without touching a terminal except for one step: installing PostHog, which gets handled by pasting a single line into the terminal and letting the PostHog wizard walk you through the rest.
Mobile Is 64% of Your Traffic — Lighthouse Catches That Too
One thing Lighthouse surfaces that people consistently underweight: mobile performance is not the same as desktop performance. The same page can score 95% on desktop and 70% on mobile, because mobile devices have slower processors, more constrained memory, and often worse network connections.
Catliff cites a traffic split of 64% mobile, 3% tablet, 33% desktop. If you’re only testing your Lighthouse score on desktop, you’re optimizing for a third of your audience and ignoring the majority.
The fix is to run Lighthouse in mobile mode. In DevTools, before you run the analysis, switch the device setting from “Desktop” to “Mobile.” You’ll get a separate score that reflects what a phone user actually experiences. Then paste that report into Claude with the same prompt, adding “optimize for mobile devices” explicitly.
Chrome’s responsive mode (also in DevTools, via the device toggle icon) lets you preview your page at any screen width. You can drag the viewport down to 375px and watch the layout respond — or break. If it breaks, that’s a Claude prompt. “The layout breaks on mobile at 375px width, here’s what’s happening, fix it.”
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
The point is that the diagnostic tools and the fix tool are now part of the same workflow. You find the problem in DevTools, you describe it to Claude, Claude fixes it. The loop is tight enough that you can run through mobile, tablet, and desktop optimization in an afternoon.
Speed Is One Variable in a Larger Conversion System
Page load speed is necessary but not sufficient. Catliff’s 20% conversion rate — ten times the industry average — came from stacking multiple variables: the right copy structure, a founder video (which lifted his CVR from 10% to 15% on its own), video testimonials (which dropped his Google Ads cost-per-conversion from $200 to $30), a form on the page rather than a contact link, call-to-actions positioned for both desktop scroll behavior and mobile thumb reach.
Speed is the floor. If your page loads in 4 seconds, none of the other optimizations matter as much as they should, because a significant portion of your visitors have already left. Get the floor right first.
The deployment stack Catliff uses is worth noting here: GitHub for version control, Vercel for free deployment. You import your GitHub repo into Vercel, select the Next.js preset, add your environment variables (the PostHog API keys that got generated during installation), and the page is live in about 60 seconds. The Lighthouse score you’re optimizing in local development should carry over to production — but it’s worth running the analysis again on the live Vercel URL to confirm.
For teams building more complex tooling around their landing page stack — connecting form submissions to CRMs, routing leads through automated workflows, chaining multiple AI models — MindStudio offers a no-code path with 200+ models and 1,000+ integrations, which can handle the orchestration layer without requiring custom API work.
The Skill That Scales the Whole Thing
Once you have a fast, high-converting page, the next problem is that you need many of them. Catliff’s approach is what he calls the “zipper” method: one axis is geography (Toronto, Manhattan, the Bronx, Vancouver), the other axis is service (tree trimming, tree removal, stump grinding). Every intersection gets its own landing page, because someone searching “tree trimming Toronto” wants to land on a page that says “tree trimming Toronto” — not a generic landscaping page.
To automate this, he creates a Claude Code skill — a reusable workflow triggered by a slash command. The command is /landing-page-generator [city] [service] [traffic-source]. You call it with the parameters you want, and Claude generates a location- and service-specific page that inherits all the optimization work you’ve already done on the base template.
The caveat he’s explicit about: for SEO, you don’t want to generate 1,000 pages at once. Google will notice the spike and penalize you. You ramp up gradually — a few pages a week, then more over time. The skill makes the generation trivial; the pacing is a strategic choice.
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
If you’re thinking about how this kind of spec-driven generation scales to full applications rather than landing pages, Remy takes a related approach: you write your application as an annotated markdown spec, and it compiles into a complete TypeScript stack — backend, database, auth, deployment. The spec is the source of truth; the code is derived output. Different scope than a landing page generator, but the same underlying shift in where the work happens.
For teams managing token budgets across these kinds of generation tasks, the Claude Code token management guide has practical techniques for extending sessions when you’re running multiple page generations in sequence.
What the Numbers Actually Add Up To
The speed-to-CVR data is striking on its own. But the more interesting thing is what it implies about where optimization effort should go.
Most people building landing pages spend their time on things that are visible: the headline, the color scheme, the layout, the copy. These matter. But they’re downstream of whether the page loads. A visitor who bounces at 3 seconds never reads your headline.
The Lighthouse workflow — run the report, paste it into Claude, iterate — takes maybe 20 minutes the first time and less than 5 minutes on subsequent passes. The upside is potentially doubling your conversion rate, which compounds across every dollar of ad spend and every hour of SEO work you’ve ever done or will do.
That’s not a small thing to leave on the table because you didn’t want to open DevTools.
The Claude Code source code leak post has some additional context on how Claude Code handles file modifications under the hood — relevant if you want to understand what’s actually happening when Claude rewrites your image compression settings or restructures your JavaScript loading order.
And if you’re building out the full stack — page generation, A/B testing, lead routing, speed optimization — the animated 3D websites with Claude Code post shows how far the visual side of this can go when you’re not constrained by the technical implementation layer.
The floor is a fast page. Everything else is built on top of it.
