Above the fold: what belongs there, and what it does for search
Where the fold sits on real devices, the five things that earn a place in the first viewport, how it drives Largest Contentful Paint and layout shift, and how to measure yours.
Published by AI Knows Us · Updated 13 October 2026
Above the fold is everything a visitor sees before scrolling. There is no fixed pixel height for it, because it is set by the device, the browser chrome and the orientation, so you design for the viewport sizes your own analytics report rather than a number from a blog post. It matters to search in three measurable ways. The Largest Contentful Paint element is almost always above the fold, so what you put there sets your LCP score. Layout shift is almost always caused by above the fold content arriving late, so what you put there sets your CLS score. And the first paragraph is the text a search engine quotes in a snippet, which is why the answer belongs in it rather than three screens down.
This page covers the first viewport: what belongs in it, the code that makes it fast and stable, and how to measure it. For the three Core Web Vitals metrics and their thresholds in full, see Core Web Vitals.
Find your own fold before designing for it
Open your site on the devices your visitors actually use and read the viewport back:
console.log(window.innerWidth + ' x ' + window.innerHeight);
Then draw the line temporarily so the whole team can see it. Add this to your stylesheet while you work, and delete it before you ship:
/* temporary: a dashed line at the bottom of the first viewport */
body::after {
content: "";
position: absolute;
top: 100vh;
left: 0;
right: 0;
border-top: 2px dashed red;
pointer-events: none;
z-index: 9999;
}
On phones, use the dynamic viewport unit so the line matches what the browser actually shows once its toolbars collapse: replace 100vh with 100dvh. Most arguments about the fold end the moment somebody sees the line on a mid range Android handset.
The five things that earn a place
- What this page is, in words. An h1 plus one sentence. A hero image with no text tells a reader nothing and gives a search engine nothing to quote.
- The answer, or the offer. On an informational page, the direct answer to the query. On a commercial page, what you sell, to whom, and where.
- One primary action. One. Two equal buttons is a question, not an invitation.
- One trust marker. A registration number, an accreditation, a named client, a count of years. Something checkable.
- The LCP element, prioritised. Normally the hero image or the headline block. Whatever it is, it should load first.
What does not earn a place: a rotating carousel, a full bleed image that pushes all text below the line, a cookie banner that covers the content, an interstitial over the main text, or stacked ad slots above the headline. Google's page experience guidance is direct about main content being easy to reach, and a reader who has to dismiss two overlays to read a sentence leaves.
The code that makes the first viewport fast
Give the LCP image explicit dimensions and a high fetch priority, and never lazy load it:
<img src="/img/hero-1200.webp"
srcset="/img/hero-800.webp 800w, /img/hero-1200.webp 1200w"
sizes="(max-width: 900px) 100vw, 1200px"
width="1200" height="630"
alt="Leather Chelsea boots on a workbench"
fetchpriority="high"
decoding="async">
If the image is referenced from CSS rather than markup, preload it in the head so the browser does not have to parse a stylesheet to discover it:
<link rel="preload" as="image" href="/img/hero-1200.webp" fetchpriority="high">
Reserve space for anything that arrives late. Layout shift above the fold is almost entirely a missing dimensions problem:
.hero-media { aspect-ratio: 1200 / 630; }
.ad-slot { min-height: 250px; }
.notice-bar { min-height: 48px; }
@font-face {
font-family: "SiteSans";
src: url("/fonts/sitesans.woff2") format("woff2");
font-display: swap;
font-weight: 400;
}
Then confirm which element Google is actually timing, rather than guessing. Paste this into the console on the live page:
new PerformanceObserver(function (list) {
for (const entry of list.getEntries()) {
console.log('LCP', Math.round(entry.startTime), entry.element);
}
}).observe({ type: 'largest-contentful-paint', buffered: true });
The element it logs is the one worth optimising. Teams routinely spend a week compressing an image that was never the LCP element, and web.dev's guide to optimising LCP covers the sequence once you know which element it is.
Above the fold and the snippet
| Element | What it affects | Practical rule |
|---|---|---|
| Title tag | The blue link text | Primary query near the front, brand at the end |
| H1 | What the page claims to be | One per page, matching the title in substance |
| First paragraph | Snippet and quoted text | Answer the query in the first two sentences |
| Hero image | LCP, and image results | Sized, prioritised, with real alt text |
| Overlays | Whether the content is reachable | Dismissible, small, never over the main text |
The pattern that works on both counts is the same one: say the thing, then show the thing. Mobile SEO covers the parity checks that stop a desktop first viewport from collapsing into a wall of padding on a phone.
How to measure it properly
- Run the URL through PageSpeed Insights and read the field data first. Lab scores are diagnostic; field data is what Google has.
- Note the LCP element it names and compare it to what the observer logs in your own browser.
- Check CLS on mobile specifically. Desktop rarely shows the shift that a phone does.
- Screenshot the first viewport on three real devices and ask one question of each: can a stranger tell what this page is and what to do next.
- Recheck after any hero redesign, banner addition or tag manager change, because all three land above the fold.
Asked and answered: above the fold
Is 600 pixels still the fold?
No. Treat the fold as a range set by your own visitors' devices, measure it with the viewport readout above, and design the first screen so it works at the smallest common height.
Does content below the fold still count for ranking?
Yes. Google indexes the whole page. The first viewport matters because it sets your speed and stability scores and supplies the text that gets quoted, not because the rest is ignored.
Should the hero image be lazy loaded?
Never, when it is above the fold. Lazy loading the LCP image delays the exact paint Google is timing. Lazy load everything below the line instead.
Do cookie banners hurt Core Web Vitals?
They hurt CLS when they are injected after paint and push content down. Reserve their height in CSS, or render them as an overlay that does not move the layout.
How many calls to action belong in the first viewport?
One primary, with a quieter secondary link if you need it. A single clear action above the fold outperforms a row of equally weighted buttons.
What about long form articles?
The first viewport carries the h1, the one sentence summary and the opening answer. Site speed and SEO covers keeping the rest of a long page from slowing that first paint.
Your first viewport, read aloud by a machine
Everything this page says about the fold assumes a person scrolling. Put the same question to an assistant and nobody scrolls at all. It reads the page, lifts a sentence or two and writes its own answer, and that answer may rank the five elements in an order you never chose. Check what comes back before you redesign a hero section around any list. AI Knows Us puts questions like this to ChatGPT, Gemini, Perplexity and Claude and records which sites are named in the reply, so you can set the result beside the page you built.