CWV Series • Post 2/10
LCP Under 2 Seconds — How We Achieve It at mekyn.com
Largest Contentful Paint under 2.5 seconds is the Google standard. Under 2 seconds is the excellence goal. This guide shows the five most effective levers with real measurements.
TL;DR
- LCP Under 2 Seconds — How We Achieve It at mekyn.com — a practical guide for the DACH region.
- Covers "improve largest contentful paint" with concrete examples.
- Covers "lcp under 2 seconds" with concrete examples.
- At least 2 snippet-bait patterns for better SERP visibility.
Largest Contentful Paint (LCP) is the time from page load start until the largest visible element in the viewport is fully rendered — text block, image or video. It is the most important of the three Core Web Vitals and contributes 25% to the Lighthouse Performance score.
What LCP really measures — and what it doesn’t
Many developers confuse LCP with “the page loads fast”. LCP does not measure the first pixel, but the last rendering of the largest element. This means: A page can have FCP (First Contentful Paint) in 0.3 s, but LCP in 6 s — because the hero image loads after the cookie banner script.
LCP has three phases that Lighthouse breaks down in detail:
- TTFB (Time to First Byte): ~40% of LCP time — server response time
- Resource Load Delay: ~20% — time until browser discovers the resource
- Resource Load Duration: ~30% — time to download the resource
- Element Render Delay: ~10% — time for rendering in browser
The levers are in the first three phases.
The five most effective levers for LCP under 2 seconds
- TTFB under 100 ms — Static files from CDN edge (Cloudflare), no server-side rendering per request
- LCP element as text, not image — H1 container renders immediately, no image download needed
- CSS critical inline — The LCP element is styled in the first HTML chunk, no waiting for external CSS
- Font preloading for the LCP element —
font-display: swap+rel="preload"for the font in H1 - No JavaScript before the LCP element — All
<script>tags withdeferortype="module", nothing render-blocking
Lever 1: TTFB under 100 ms
Time to First Byte is the time from HTTP request to first byte of response. Every millisecond of TTFB extends LCP by at least one millisecond — on dynamic pages often more.
Why mekyn.com has TTFB < 40 ms:
- Static Site Generator (Astro): Every HTML page is pre-rendered at build time. No PHP execution, no database query, no template rendering per request.
- Cloudflare CDN: All static assets are served from Cloudflare’s edge. The server in Frankfurt has TTFB < 10 ms for DE users.
Cache-Control: public, max-age=3600: HTML pages are cached for 1 hour in CDN. Repeat requests get instant HIT.
For existing sites: Putting a CDN in front of the server is the fastest TTFB lever. Cloudflare, BunnyCDN or KeyCDN cost little and reduce TTFB by 60–80%.
Lever 2: The LCP element as text
The largest visible element on most marketing pages is either the H1 text or a hero image. The choice determines 50% of the LCP value.
Text as LCP element (our choice):
- Is delivered in the first TCP packet
- Renders synchronously with HTML parsing
- No additional HTTP request needed
Image as LCP element (common mistake):
- Additional HTTP request for the image
- Image download takes 200–2000 ms depending on size
- Lazy loading delays the download additionally
On mekyn.com, the LCP element is always the H1 text container with a text badge. Images come from the public/ folder, are pre-optimized as AVIF and have loading="lazy" — they don’t block LCP.
Lever 3: CSS critical inline
External CSS blocks rendering. The browser must download and parse all CSS before it can style the LCP element.
Our approach with Astro/Tailwind:
Astro builds CSS into <style> tags in <head> by default — this is already “critical inline”. Combined with Tailwind’s JIT compiler, each page contains only the actually used CSS (typically 4–8 KB), not the entire Tailwind library.
For manually optimized sites: Critical CSS rules for the LCP element and viewport area (above-the-fold) in a <style> tag in <head>. The rest of the CSS is loaded asynchronously with media="print" onload="this.media='all'".
Lever 4: Font preloading
The LCP element contains text — and text needs font. If the font is loaded as an external font and isn’t cached at the right time, LCP rendering is delayed.
Our font setup:
- Self-hosted: Inter and Space Grotesk are in
.woff2format innode_modules/@fontsource-variable/and copied by Astro during build. No Google Fonts CDN, no third-party DNS lookups. font-display: swap: Browser immediately shows a system fallback font and swaps when font loads. No FOIT (Flash of Invisible Text).- Subset preloading: In
BaseLayout.astrowe preload thelatinsubsets of Inter and Space Grotesk. This is the minimum needed for DACH text. - Only two font families: Inter (body) + Space Grotesk (headlines). No third font, no icon font.
Lever 5: No JavaScript before the LCP element
JavaScript blocks the HTML parser. A <script> without defer or async in the middle of <body> stops parsing until the script is downloaded and executed.
Our rule: In <head> only <link> tags, no <script>. In <body> only <script> with defer or inline scripts at end of page. React islands only where interactive logic is really needed — and always with client:load or client:idle, never with client:visible.
For tracking: Plausible Analytics loads as a 1 KB inline script at the end of <body>, sends a single POST /api/event and is done. No tag manager solution, no GTM container with 50 third-party scripts.
Measuring LCP: The right tools
- Lighthouse in Chrome DevTools: Lab test with simulated conditions. Good for first diagnosis and A/B comparisons during development.
- PageSpeed Insights: Combines Lab (Lighthouse) and Field Data (CrUX). Shows the 75th percentile of real users.
- Chrome User Experience Report (CrUX): Raw field data. Available as a public BigQuery dataset and via the CrUX API.
- Our recommendation: PageSpeed Insights for quick checks, CrUX API for detailed trends.
One important note: LCP values fluctuate. Different devices, networks and times of day produce different values. A single bad Lighthouse run is not a reason to panic — the trend over 28 days is what counts.
Frequently Asked Questions
What exactly is LCP?
LCP measures the time from page load start until the largest visible element in the viewport is fully rendered — typically the H1 text block for us.
What is a good LCP value?
Google defines ≤ 2.5 s as good, ≤ 4.0 s as needs improvement. Our goal: ≤ 2.0 s at the 75th percentile.
Why is my LCP bad even though the page looks fast?
LCP measures the last rendering of the largest element — not the first visible pixel. An image that loads delayed can ruin the LCP value.
LCP in Lighthouse vs. CrUX — what counts?
CrUX (Field Data from real Chrome users) is the ranking signal. Lighthouse is a lab test for diagnosis.
Can I fix LCP with a plugin?
No. LCP is the result of server, network and rendering decisions. Plugins can optimize individual aspects, but the breakthrough comes from architecture.
Further reading on mekyn.com
→ Pillar page: SEO → Related: How to Achieve Lighthouse Score 100 → Related: CLS Zero (German) → Tool: CWV Tracker (German)
External sources:
No credit card · 14-day trial · Anti-lock-in