03 - LCP Optimization: Image Preloading, Critical CSS and SSR

LCP Optimization: Image Preloading, Critical CSS and SSR

The Largest Contentful Paint (LCP) measures the time it takes for the main content of the page is visible to the user. For Google, the "Good" threshold is 2.5 seconds: beyond this threshold, the organic ranking is penalized. According to CrUX data from March 2026, the 35% of websites still have LCP in the "Needs Improvement" or "Poor" range, often for reasons that can be avoided with targeted interventions.

The LCP element is typically the hero image, main banner, or multiple text block large above the fold. The optimization strategy depends on the type of item: an image requires different approaches to a text. In both cases, there are four ad techniques high impact covering 90% of real cases: LCP image preloading, inlining the Critical CSS, font preloading with font-display: swap, and Server-Side Rendering.

Identify the LCP Element

The first step is always knowing which element is your LCP. You can identify it in two ways:

• Chrome DevTools: in the Performance panel, after a load recording page, look for the "LCP" marker in the timeline. Click on it to see which item triggered the LCP and how many dependent resources it requested.
• web-vitals.js: the property entries of the LCP metric object contains the LargestContentfulPaint entry with the corresponding DOM element.

import { onLCP } from 'web-vitals';

onLCP((metric) => {
  const lcpEntry = metric.entries[metric.entries.length - 1];
  console.log('Elemento LCP:', lcpEntry.element);
  console.log('Valore LCP:', metric.value, 'ms');
  console.log('Rating:', metric.rating); // 'good' | 'needs-improvement' | 'poor'
});

Strategy 1: Image Preloading with fetchpriority

If your LCP element is an image, the most impactful improvement is the preloading explicit with high priority. By default, the browser only discovers images when the HTML parser encounters the tag <img>, which can happen long after the document has started loading. With <link rel="preload">, the browser start downloading the image as soon as possible.

<!-- Nel <head> dell'HTML, prima di altri tag -->
<link
  rel="preload"
  as="image"
  href="/images/hero.webp"
  fetchpriority="high"
  imagesrcset="/images/hero-400.webp 400w,
               /images/hero-800.webp 800w,
               /images/hero-1200.webp 1200w"
  imagesizes="100vw"
/>

The attribute fetchpriority="high" (Baseline 2023, 92% support) communicates to browser that this resource is critical and must be downloaded before prioritized resources normal. On slow networks, this can make a difference of 0.5-1.5 seconds on the LCP.

Responsive Images: imagesrcset and imagesizes

If you use responsive images with srcset, you have to add imagesrcset e imagesizes to the preload link to have the browser preload the correct variant for the current viewport, not the larger version.

WebP and AVIF format

Image format optimization is complementary to preloading. WebP typically reduces the weight of images by 25-35% compared to JPEG. AVIF reduces by 50-55% but has times of higher decoding on older hardware. For LCP image, WebP and optimal format in 2026, with AVIF for progressive improvement on modern browsers.

<picture>
  <source
    srcset="/images/hero.avif"
    type="image/avif"
  />
  <source
    srcset="/images/hero-400.webp 400w, /images/hero-800.webp 800w"
    type="image/webp"
    sizes="100vw"
  />
  <img
    src="/images/hero.jpg"
    alt="Hero image"
    width="1200"
    height="600"
    fetchpriority="high"
    loading="eager"
  />
</picture>

Strategy 2: Critical CSS Inline

By default, the browser does not begin rendering the page until it has downloaded and viewed it all the CSS linked in the<head>. If your CSS file is large (100KB+) e served on a slow CDN, this can add 0.5-2 seconds to the LCP. The solution is the Critical CSS: Extract only the CSS needed to render the content above the fold and include them inline in the HTML.

<!-- INVECE DI: -->
<link rel="stylesheet" href="/styles/main.css">

<!-- USA: -->
<style>
  /* Critical CSS inline - solo quello necessario above the fold */
  body { margin: 0; font-family: sans-serif; }
  .hero { width: 100%; height: 60vh; background: #f5f5f5; }
  .hero h1 { font-size: 2.5rem; color: #333; }
  nav { display: flex; justify-content: space-between; padding: 1rem; }
</style>

<!-- Carica il CSS completo in modo non-bloccante -->
<link
  rel="preload"
  as="style"
  href="/styles/main.css"
  onload="this.rel='stylesheet'"
/>
<noscript><link rel="stylesheet" href="/styles/main.css"></noscript>

Tools for Extracting Critical CSS

Manually extracting Critical CSS is not practical on large sites. Use automatic tools:

• Critters (webpack/Vite plugin): Extracts and inlines critical CSS automatically
• critical (npm): CLI tool to extract critical CSS from any URL
• PurgeCSS + Critters: ideal combination for reducing total CSS before inlining

// vite.config.ts - con Critters per Critical CSS automatico
import { defineConfig } from 'vite';
import critters from 'vite-plugin-critters';

export default defineConfig({
  plugins: [
    critters({
      // Inline il critical CSS, carica il resto in modo asincrono
      strategy: 'critical',
      // Non rimuovere i CSS non usati (lascialo a PurgeCSS)
      pruneSource: false,
    }),
  ],
});

Strategy 3: Font Preloading with font-display: swap

Web fonts can block text rendering (FOIT - Flash of Invisible Text) up to 3 seconds on slow connections, delaying the LCP if the text and the LCP element. Two optimizations combine to eliminate this problem:

1. font-display: swap tells the browser to show the text immediately with the fallback font, then replace it with the web font when it is available. Eliminate FOIT.

/* In @font-face o nel parametro di Google Fonts */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap; /* Critico per LCP */
  font-weight: 400 700;
}

/* Con Google Fonts: aggiungi &display=swap all'URL */
<link
  href="https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap"
  rel="stylesheet"
/>

2. Preconnect + Preload reduces font discovery and download latency:

<!-- Preconnect: stabilisce la connessione con il font server in anticipo -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

<!-- Preload: scarica il file font prima che il CSS venga parsato -->
<link
  rel="preload"
  as="font"
  type="font/woff2"
  href="/fonts/inter-400.woff2"
  crossorigin
/>

Strategy 4: Server-Side Rendering

The previous four strategies optimize resources; SSR optimizes the fundamental structure of the page. In a Single Page Application (SPA), the browser receives almost HTML empty and must download, parse and execute JavaScript to render the content. With SSR, the browser receives HTML already rendered: the LCP element is immediately visible without waiting for JavaScript.

The LCP improvement with SSR is typically 0.5-2 seconds:

• SPA without SSR: HTML shell → JS download (300-800ms) → JS execution (100-500ms) → API calls (200-800ms) → render → LCP
• With SSR: Full HTML → Instant LCP (download time only of the HTML and the server's TTFB)

Frameworks like Next.js, Angular Universal (SSR), Nuxt.js, and SvelteKit include native SSR. For Angular, configuration is managed by angular.json and from the Express server:

// angular.json - abilita SSR
{
  "projects": {
    "app": {
      "architect": {
        "build": {
          "configurations": {
            "production": {
              "server": "src/main.server.ts",
              "prerender": false,    // SSR on-demand
              "ssr": true
            }
          }
        }
      }
    }
  }
}

Measuring LCP Improvement

After implementing optimizations, measure the improvement with these tools:

1. Lighthouse CI: create baselines before optimizations and compare after. Run more runs (5+) and use the median to reduce variance.
2. WebPageTest.org: get filmstrip and detailed loading waterfall on real devices and real connections.
3. web-vitals.js in production: monitors users' real LCP P75 for 7-14 days after deployment.

import { onLCP } from 'web-vitals';

// Monitora LCP in produzione
onLCP({ reportAllChanges: true }, (metric) => {
  // Invia solo il valore finale (quando la pagina e in background)
  if (metric.entries.length > 0) {
    navigator.sendBeacon('/api/vitals', JSON.stringify({
      metric: 'LCP',
      value: metric.value,
      rating: metric.rating,
      url: window.location.pathname,
      device: navigator.connection?.effectiveType || 'unknown',
    }));
  }
});

Conclusions

LCP optimization is an area where a few targeted interventions produce enormous impacts. 35% of sites with LCPs in the "Needs Improvement" or "Poor" range almost certainly have one or more of these four problems: hero image not preloaded, rendering-blocking CSS, font that delay text, or SPA without SSR.

The correct workflow is: 1) measure the real LCP with web-vitals.js, 2) identify the LCP element, 3) analyze the loading waterfall to find the bottleneck, 4) apply the relevant optimizations, 5) verify the improvement with Lighthouse CI and field data.