A landing page is fast enough when real mobile visitors see the main content within 2.5 seconds, the layout does not jump around while it loads, and the page responds to taps within 200 milliseconds. Those three targets are Google's Core Web Vitals: Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint. On most slow landing pages, a handful of fixes (the hero image, unused scripts and fonts) solve most of the problem.
Why speed matters for a landing page
Paid and social traffic often arrives on a phone, on a mobile connection, from someone who was doing something else a moment ago. If the page is still blank or jumping around, many of those visitors leave before they read the headline. You pay for the click either way.
Speed also affects how the page feels. A page that loads cleanly and responds immediately when someone taps the button feels trustworthy. One that stutters feels broken, even if the offer is good.
The three Core Web Vitals
Core Web Vitals are three metrics Google uses to describe real-world loading, visual stability and responsiveness. Each has a "good" threshold, a "needs improvement" range and a "poor" range.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | When the main content appears | 2.5 s or less | More than 4.0 s |
| Cumulative Layout Shift (CLS) | How much the layout jumps | 0.1 or less | More than 0.25 |
| Interaction to Next Paint (INP) | How quickly the page responds to taps, clicks and key presses | 200 ms or less | More than 500 ms |
Anything between "good" and "poor" is rated "needs improvement".
Largest Contentful Paint (LCP)
LCP marks the moment the largest visible element in the first screen finishes rendering. On a landing page that is usually the hero image, a background image, a video poster or the main headline block.
For marketers, LCP is the closest thing to "how long until the visitor sees what we are offering". It is affected by server response time, how big the hero image is, and anything that blocks the browser from drawing the page, such as scripts and stylesheets in the page head.
Cumulative Layout Shift (CLS)
CLS measures how much visible content moves unexpectedly while the page is in use. The classic example: you go to tap a button, an image or banner loads above it, the button moves down, and you tap something else.
According to web.dev, common causes are images and videos without set dimensions, web fonts that render larger or smaller than the fallback font, ads and widgets that resize themselves, and content inserted above existing content after the page loads.
Interaction to Next Paint (INP)
INP measures how quickly the page visibly responds when someone clicks, taps or types. It looks across the whole visit and reports one of the slowest interactions, so a page that feels fine on the first tap but freezes when someone opens the menu or types in a form will score poorly.
INP replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024. If you see FID in an older report or plugin, it is out of date. INP is harder to pass than FID was, because it measures the full delay until the screen updates across all interactions rather than only the delay before the first one starts being handled.
The 75th percentile
Google assesses each metric at the 75th percentile of page loads, separately for mobile and desktop. In plain terms, a page passes if at least three out of four visits meet the "good" threshold. This matters because your own test on a fast laptop and office Wi-Fi is not a typical visit. The slower quarter of your real visitors decides your score.
Lab data versus field data
When you test a page you will see two kinds of results, and they often disagree.
Lab data
Lab data comes from a simulated page load under fixed conditions: one device, one network speed, one location, usually an empty cache. Lighthouse, which powers the lab section of PageSpeed Insights and the Lighthouse panel in Chrome DevTools, produces lab data.
Lab data is useful for debugging because it is repeatable. You can make a change, re-run the test and see whether it helped. But it does not include real user behaviour, so it cannot measure INP directly. Instead, Lighthouse reports Total Blocking Time (TBT), which is a lab measure of how long the main thread was busy and is a reasonable proxy for responsiveness problems.
Field data
Field data comes from real Chrome users visiting your page. It is collected in the Chrome User Experience Report (CrUX) and shown at the top of PageSpeed Insights when your page or site has enough traffic. CrUX aggregates data over a rolling 28-day period.
Field data is what counts. It reflects your actual visitors' devices and connections. The trade-off is that it changes slowly: after you fix something, it can take up to four weeks for the improvement to fully show in the field numbers.
Which to trust
Use field data to decide whether you have a problem and how big it is. Use lab data to find the cause and to check that a fix works before it shows up in the field. If a new landing page has too little traffic for field data, rely on mobile lab results and be conservative: lab tests are a reasonable approximation of a mid-range phone on a mobile connection.
The usual culprits on WordPress and page-builder sites
WordPress with Elementor, Divi, WPBakery or similar builders makes landing pages fast to build, but the defaults often make them slow to load. These are the problems that come up again and again.
Oversized hero images
A hero image uploaded straight from a camera or stock site can be several megabytes and thousands of pixels wide, then displayed in a space a fraction of that size. It is often the LCP element, so its size directly delays LCP. Background images set in the builder are particularly easy to miss because they do not go through the normal responsive image handling.
Lazy-loading the hero image
Lazy-loading is good for images further down the page, but if the hero image is lazy-loaded the browser deliberately waits before fetching it. Many optimisation plugins lazy-load every image by default, including the one that matters most.
Render-blocking CSS and JavaScript
Page builders, themes and plugins each load their own stylesheets and scripts, often on every page whether they are used or not. Files loaded in the page head block the browser from drawing anything until they arrive. This delays LCP and adds to blocking time.
Third-party tags
Analytics, ad pixels, heat-mapping tools, chat widgets, cookie banners, review widgets and embedded videos each add scripts from other servers. Individually they look small; together they can dominate loading and blocking time. They are also a common cause of poor INP, because their scripts run on the main thread when visitors interact.
Web fonts
Several font families, each in multiple weights, loaded from an external service, can delay text from appearing and cause layout shifts when the real font replaces the fallback. Icon fonts loaded just for a few icons are a common extra.
Sliders and carousels
Hero sliders load several large images instead of one, often rely on heavy JavaScript, and can shift layout as they initialise. They also tend to hide the headline behind rotating messages. On a landing page, a single static hero is almost always the better choice for both speed and clarity.
Slow hosting
If the server takes a long time to respond, every other metric starts late. Cheap shared hosting without page caching is a common cause. No amount of front-end optimisation can fully compensate for a slow server.
A prioritised fix list
Work through these roughly in order. The early items are usually the quickest wins on a typical WordPress landing page.
- Measure on mobile first. Run PageSpeed Insights on the exact landing page URL. Note the field data if available, the LCP element Lighthouse identifies, and the main opportunities listed.
- Fix the hero image. Resize it to the largest size it is actually displayed at, compress it, and serve a modern format such as WebP or AVIF. Make sure it is not lazy-loaded. If your theme or plugin supports it, mark it as high priority so the browser fetches it early.
- Replace sliders with a single hero. One image, one headline, one button.
- Turn on page caching and check server response. Use your host's caching or a reputable caching plugin. If server response stays slow, consider better hosting.
- Remove unused plugins and third-party tags. Audit every pixel, widget and script. If nobody looks at the heat maps, remove the heat-mapping tool. Load the chat widget only on pages that need it, or after the page has loaded.
- Reduce render-blocking files. Use your optimisation plugin to defer non-critical JavaScript and remove unused CSS where it can be done safely. Test the page afterwards, because aggressive settings can break layouts or forms.
- Simplify fonts. Use one or two font families and only the weights you need. Host them locally if you can, and use a font-display setting that shows text immediately with a fallback.
- Set dimensions on images, videos and embeds. Width and height attributes, or a fixed aspect ratio, let the browser reserve space and prevent layout shifts.
- Reserve space for late-loading elements. Cookie banners, promo bars and review widgets should not push content down after it has appeared. Overlay them or give them a fixed space.
- Re-test and wait for field data. Confirm improvements in lab data straight away, then check field data again after a few weeks.
How speed fits with everything else
Speed is necessary but not sufficient. A fast page with a confusing headline, a hidden button or no proof will still convert poorly. Fix speed problems that are clearly costing you visitors (a hero image that takes many seconds to appear, layout that jumps under the visitor's thumb), then put your effort into the offer, copy and call to action. The landing page checklist covers both sides.
Next step
A free PageScore audit pulls real mobile speed data from Google PageSpeed, including LCP, CLS, blocking time, server response and page weight, and shows it alongside the copy, CTA and trust checks so you can see which fixes matter most.