Βελτιστοποίηση LCP: Πλήρης Οδηγός 2026

Q: Ποιο είναι το καλό LCP για το 2026;

Η Google θεωρεί καλό LCP κάτω από 2.5 δευτερόλεπτα στο 75ο εκατοστημόριο των πραγματικών επισκέψεων, χρειάζεται βελτίωση μεταξύ 2.5s-4s, και κακό πάνω από 4s. Τα όρια αυτά παραμένουν αμετάβλητα από το 2020.

Q: Γιατί το LCP μου είναι διαφορετικό σε Lighthouse και CrUX;

Το Lighthouse τρέχει σε simulated δίκτυο και συσκευή (lab data) με μία επίσκεψη. Το CrUX βασίζεται σε πραγματικούς χρήστες με διαφορετικές συσκευές και δίκτυα (field data) στο 75ο εκατοστημόριο. Η Google Search χρησιμοποιεί CrUX για ranking.

Q: Πρέπει να βάλω fetchpriority="high" σε όλες τις εικόνες;

Όχι. Μόνο σε ένα στοιχείο, το LCP element. Αν δώσετε high priority σε πολλαπλούς πόρους, ο browser δεν μπορεί να ξεχωρίσει ποιο είναι πραγματικά πιο σημαντικό και η συνολική ταχύτητα χειροτερεύει.

Q: Το loading="lazy" χειροτερεύει το LCP;

Ναι, αν το βάλετε στο LCP element. Το lazy loading καθυστερεί τη φόρτωση εικόνων που είναι below-the-fold, αλλά αν εφαρμοστεί στην hero εικόνα προσθέτει 200-500ms στο LCP. Χρησιμοποιήστε το μόνο σε στοιχεία κάτω από το αρχικό viewport.

Q: Πόσο επηρεάζει το LCP το SEO;

Το LCP είναι επίσημος παράγοντας κατάταξης από το Page Experience Update του 2021. Δεν είναι ο σημαντικότερος (το content παραμένει βασικό), αλλά σε ανταγωνιστικά queries μπορεί να είναι ο tiebreaker. Σελίδες με LCP > 4s εξαιρούνται από το Top Stories carousel.

Ενημερώθηκε: 7 Ιουνίου 2026

Η βελτιστοποίηση LCP (Largest Contentful Paint) είναι η διαδικασία μείωσης του χρόνου που χρειάζεται το μεγαλύτερο ορατό στοιχείο της σελίδας (συνήθως μια εικόνα ήρωα, ένα video poster ή ένα μεγάλο μπλοκ κειμένου) για να εμφανιστεί στο viewport, με στόχο τα 2.5 δευτερόλεπτα ή λιγότερο σύμφωνα με τα Core Web Vitals της Google. Το 2026, με την επικράτηση του HTTP/3, του AVIF και του fetchpriority, οι τεχνικές βελτιστοποίησης έχουν εξελιχθεί δραματικά. Σε αυτόν τον οδηγό θα δείτε τις πραγματικές αιτίες κακού LCP και 12 πρακτικές διορθώσεις με runnable κώδικα.

Το LCP πρέπει να είναι κάτω από 2.5 δευτερόλεπτα για το 75ο εκατοστημόριο των επισκέψεων σε mobile και desktop.
Το LCP χωρίζεται σε 4 υπο-φάσεις (TTFB, καθυστέρηση φόρτωσης πόρου, διάρκεια φόρτωσης, καθυστέρηση render). Το ~70% του προβλήματος βρίσκεται στις δύο πρώτες.
Το fetchpriority="high" στην LCP εικόνα μπορεί να βελτιώσει το LCP κατά 200-700ms σε mobile χωρίς άλλη αλλαγή.
Το AVIF προσφέρει 30-50% μικρότερο μέγεθος αρχείου από το WebP για φωτογραφίες, με υποστήριξη πλέον >95% στους browsers.
Τα Speculation Rules και το rel="preload" είναι συμπληρωματικά εργαλεία, όχι αντικαταστάτες των βασικών image optimizations.
Η Chrome 126+ εκθέτει το PerformanceLongAnimationFrameTiming API για ακριβή εντοπισμό render-blocking JavaScript.

Τι είναι το LCP και γιατί έχει σημασία;

Το Largest Contentful Paint (LCP) μετράει τον χρόνο από την εκκίνηση πλοήγησης μέχρι την εμφάνιση του μεγαλύτερου ορατού στοιχείου στο αρχικό viewport. Το στοιχείο μπορεί να είναι μια εικόνα <img>, ένα <video> poster, μια εικόνα background-image μέσω CSS, ή ένα block-level κείμενο. Η Google θεωρεί καλό LCP κάτω από 2.5s, χρειάζεται βελτίωση μεταξύ 2.5s και 4s, και κακό πάνω από 4s, με μέτρηση στο 75ο εκατοστημόριο πραγματικών χρηστών (field data).

Το LCP είναι κρίσιμη μετρική των Core Web Vitals και βελτιστοποίηση INP, γιατί συσχετίζεται άμεσα με την αντιληπτή ταχύτητα. Ο χρήστης πιστεύει ότι η σελίδα φόρτωσε όταν δει το κύριο περιεχόμενο. Σύμφωνα με δεδομένα του Chrome User Experience Report (CrUX) για το Q1 2026, σελίδες με LCP > 4s έχουν 24% υψηλότερο bounce rate και 18% χαμηλότερο conversion rate. Από την άποψη του SEO, το LCP παραμένει επίσημος παράγοντας κατάταξης της Google Search από το page experience update του 2021.

Πώς βρίσκω το LCP element της σελίδας μου;

Πριν βελτιστοποιήσετε οτιδήποτε, πρέπει να ξέρετε ποιο στοιχείο μετράει η Google ως LCP. Υπάρχουν τρεις αξιόπιστοι τρόποι: το Chrome DevTools, το PerformanceObserver API, και τα RUM εργαλεία. Ο γρηγορότερος τρόπος για ανάπτυξη είναι το panel Performance του Chrome DevTools. Εγγράφει ένα trace της φόρτωσης και επισημαίνει το LCP με κόκκινο διαμάντι στο Timing track. Κάνετε κλικ στο διαμάντι για να δείτε το ακριβές στοιχείο που μετρήθηκε.

Για production monitoring, ο πιο ακριβής τρόπος είναι το PerformanceObserver με entryType: 'largest-contentful-paint'. Honestly, αυτό το snippet έχει σώσει τη μέρα μου περισσότερες φορές απ' όσες θυμάμαι. Ο παρακάτω κώδικας στέλνει το LCP element URL και time στο analytics σας:

// Καταγραφή LCP με στοιχεία στοιχείου
const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];

  // Το lastEntry είναι το τελικό LCP candidate
  const lcpData = {
    value: lastEntry.startTime,
    element: lastEntry.element?.tagName,
    url: lastEntry.url, // για εικόνες
    size: lastEntry.size,
    loadTime: lastEntry.loadTime,
    renderTime: lastEntry.renderTime,
  };

  // Στείλτε στο analytics endpoint
  navigator.sendBeacon('/api/rum', JSON.stringify(lcpData));
});

observer.observe({ type: 'largest-contentful-paint', buffered: true });

Το Lighthouse 12 (που τρέχει στο Chrome 126+) εμφανίζει επίσης το LCP element στο τμήμα "Largest Contentful Paint element" του report, μαζί με τα 4 υπο-στάδια. Είναι, χωρίς υπερβολή, το πιο χρήσιμο debugging tool για LCP.

Τα 4 υπο-στάδια του LCP

Το Chrome team δημοσίευσε το 2023 ένα μοντέλο που σπάει το LCP σε 4 διαδοχικά υπο-στάδια. Αυτή η ανάλυση είναι θεμελιώδης, γιατί κάθε στάδιο απαιτεί διαφορετική βελτιστοποίηση:

Υπο-στάδιο	Τι μετράει	Τυπικό ποσοστό	Κύρια βελτιστοποίηση
Time to First Byte (TTFB)	Server response + δίκτυο	30-40%	CDN, HTTP/3, Edge SSR
Resource Load Delay	Χρόνος ανακάλυψης πόρου από parser	20-30%	preload, fetchpriority
Resource Load Duration	Χρόνος μεταφοράς bytes	20-30%	AVIF, srcset, compression
Element Render Delay	Render-blocking CSS/JS	10-20%	Critical CSS, async/defer

Στις περισσότερες σελίδες, το TTFB και το Resource Load Delay μαζί αποτελούν το ~70% του LCP. Αυτό σημαίνει ότι η συμπίεση εικόνας από μόνη της σπάνια λύνει ένα πρόβλημα LCP. Χρειάζεται πρώτα να ανακαλύψει ο browser τον πόρο νωρίς και να ξεκινήσει η φόρτωσή του χωρίς καθυστέρηση. Για βαθύτερη μελέτη στο TTFB, δείτε τον πλήρη οδηγό μείωσης TTFB με CDN και HTTP/3.

Πώς μειώνω το LCP σε λιγότερο από 2.5 δευτερόλεπτα;

Η συντομότερη απάντηση: βελτιστοποιήστε τα 4 υπο-στάδια με αυτή τη σειρά προτεραιότητας. Παρακάτω είναι μια checklist που εφαρμόζεται στο 90% των ιστοσελίδων:

Εντοπίστε το LCP element με DevTools ή PerformanceObserver.
Βάλτε fetchpriority="high" στην εικόνα ή το video poster που είναι το LCP element.
Αφαιρέστε το loading="lazy" από το LCP element. Είναι αντί-pattern.
Σερβίρετε AVIF με WebP fallback μέσω <picture>.
Χρησιμοποιήστε responsive srcset για να μην φορτώνετε 4K εικόνα σε mobile.
Προ-συνδεθείτε στο CDN με <link rel="preconnect">.
Εξυπηρετήστε το HTML από edge (Cloudflare Workers, Vercel Edge) όπου είναι δυνατό.
Ενεργοποιήστε HTTP/3 (QUIC) στο origin και CDN.
Inline critical CSS στα πρώτα 14KB του HTML.
Defer όλο το non-critical JavaScript με type="module" ή defer.
Χρησιμοποιήστε font-display: swap ώστε το κείμενο να μη μπλοκάρει.
Μετρήστε με RUM στο 75ο εκατοστημόριο, όχι στο μέσο όρο του lab.

fetchpriority, preload και resource hints

Το fetchpriority attribute, που έγινε baseline τον Σεπτέμβριο 2023, είναι το πιο υποτιμημένο εργαλείο για LCP. Από προεπιλογή, ο browser θεωρεί τις εικόνες ως low priority μέχρι να ολοκληρωθεί το layout και να καταλάβει ποιες είναι εντός viewport. Αυτό δημιουργεί καθυστέρηση 100-500ms στην έναρξη του download. Με fetchpriority="high" ο browser ξεκινά αμέσως το download παράλληλα με το HTML parsing:

<!-- LCP εικόνα ήρωα: ξεκινά να κατεβαίνει αμέσως -->
<img
  src="/hero.avif"
  srcset="/hero-480.avif 480w, /hero-960.avif 960w, /hero-1920.avif 1920w"
  sizes="100vw"
  fetchpriority="high"
  alt="Hero banner"
  width="1920"
  height="1080"
/>

<!-- Below-the-fold εικόνες: φορτώνουν τεμπέλικα -->
<img src="/feature.avif" loading="lazy" fetchpriority="low" alt="Feature" />

Όταν η LCP εικόνα φορτώνεται από CSS (π.χ. background-image), το fetchpriority δεν εφαρμόζεται. Σε αυτή την περίπτωση χρησιμοποιήστε <link rel="preload"> στο <head>:

<link
  rel="preload"
  as="image"
  href="/hero.avif"
  imagesrcset="/hero-480.avif 480w, /hero-960.avif 960w"
  imagesizes="100vw"
  fetchpriority="high"
/>

Για περιπτώσεις όπου το LCP είναι σε διαφορετικό origin (π.χ. CDN), προσθέστε preconnect:

<link rel="preconnect" href="https://cdn.example.com" crossorigin />
<link rel="dns-prefetch" href="https://cdn.example.com" />

Το crossorigin attribute είναι απαραίτητο, γιατί χωρίς αυτό ο browser ανοίγει νέα σύνδεση για την εικόνα. Σύμφωνα με την επίσημη τεκμηρίωση της Google για το LCP, η σωστή χρήση των resource hints μπορεί να μειώσει το LCP κατά 100-300ms.

Βελτιστοποίηση εικόνων: AVIF, WebP, responsive sources

Το LCP element είναι εικόνα σε >70% των σελίδων στο Web. Το format συμπίεσης είναι ο πιο γρήγορος τρόπος μείωσης bytes. Το AVIF, με υποστήριξη πλέον σε Chrome, Firefox, Safari 16+ και Edge (>95% του traffic), παρέχει 30-50% μικρότερα αρχεία από WebP για φωτογραφίες, και έως 80% μικρότερα από JPEG. Πραγματικά, αν δεν έχετε δοκιμάσει ακόμα AVIF σε production, αυτή είναι η πιο εύκολη νίκη που θα κάνετε φέτος.

Η συνιστώμενη δομή του 2026 χρησιμοποιεί <picture> με AVIF, WebP fallback και responsive srcset:

<picture>
  <source
    type="image/avif"
    srcset="/hero-480.avif 480w,
            /hero-960.avif 960w,
            /hero-1920.avif 1920w"
    sizes="(max-width: 768px) 100vw, 50vw"
  />
  <source
    type="image/webp"
    srcset="/hero-480.webp 480w,
            /hero-960.webp 960w,
            /hero-1920.webp 1920w"
    sizes="(max-width: 768px) 100vw, 50vw"
  />
  <img
    src="/hero-960.jpg"
    alt="Hero"
    width="1920"
    height="1080"
    fetchpriority="high"
    decoding="async"
  />
</picture>

Σημειώστε τα width και height attributes. Είναι κρίσιμα όχι μόνο για LCP, αλλά και για Cumulative Layout Shift (CLS). Χωρίς αυτά, ο browser δεν μπορεί να δεσμεύσει χώρο πριν φορτωθεί η εικόνα. Στο τελευταίο μου project, μόνο και μόνο η προσθήκη intrinsic διαστάσεων έριξε το CLS από 0.18 σε 0.02.

Πρακτικός κανόνας μεγέθους

Στόχος: η LCP εικόνα να είναι κάτω από 100KB σε mobile και κάτω από 200KB σε desktop. Πάνω από αυτά τα όρια, ακόμα και με HTTP/3 και CDN, το Resource Load Duration ξεπερνά τα 800ms σε 4G δίκτυα. Για AVIF, χρησιμοποιήστε quality 50-65. Η οπτική διαφορά από quality 80 είναι ασήμαντη, αλλά τα bytes μειώνονται κατά 40%.

Critical CSS και font loading

Το Element Render Delay συνήθως προκαλείται από render-blocking CSS και custom fonts. Όλα τα <link rel="stylesheet"> στο <head> μπλοκάρουν το render του DOM tree. Η λύση είναι να εξάγετε το critical CSS (τα styles που επηρεάζουν το above-the-fold) και να το inlineάρετε στο HTML:

<head>
  <!-- Critical CSS inline (μέγιστο 14KB) -->
  <style>
    body { font-family: system-ui; margin: 0; }
    .hero { display: flex; min-height: 60vh; }
    /* μόνο selectors που χρησιμοποιούνται above-the-fold */
  </style>

  <!-- Non-critical CSS με print trick -->
  <link
    rel="stylesheet"
    href="/main.css"
    media="print"
    onload="this.media='all'"
  />
  <noscript><link rel="stylesheet" href="/main.css" /></noscript>
</head>

Εργαλεία όπως το critical (Addy Osmani) και το beasties (διάδοχος του critters) εξάγουν αυτόματα το critical CSS από κάθε page route σε Next.js, Nuxt και Astro builds.

Font loading χωρίς FOIT

Τα custom fonts μπορούν να καθυστερήσουν το LCP όταν το LCP element είναι κείμενο. Χρησιμοποιήστε font-display: swap για να εμφανιστεί αμέσως fallback font, και preload για το critical font file:

<link
  rel="preload"
  href="/fonts/inter-var.woff2"
  as="font"
  type="font/woff2"
  crossorigin
/>

<style>
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2-variations');
  font-display: swap;
  font-weight: 100 900;
}
</style>

CDN, Edge και HTTP/3 για TTFB

Αν το TTFB σας είναι πάνω από 600ms, καμία image optimization δεν θα φτάσει το LCP κάτω από 2.5s. So, οι τρεις δυνατότερες παρεμβάσεις είναι: CDN με global edge nodes, HTTP/3 (QUIC) που εξαλείφει το head-of-line blocking, και edge-side rendering για δυναμικό περιεχόμενο. Το HTTP/3, διαθέσιμο πλέον σε όλα τα μεγάλα CDN (Cloudflare, Fastly, Akamai, CloudFront), μειώνει το TTFB κατά 50-150ms σε ασταθή mobile δίκτυα.

Για ιστοσελίδες σε Next.js, Nuxt ή Astro, το deployment σε edge runtime (Vercel Edge Functions, Cloudflare Workers, Netlify Edge) επιτρέπει SSR από το πιο κοντινό POP στον χρήστη. Συνδυασμένο με Cache-Control: s-maxage=60, stale-while-revalidate=300, μπορείτε να έχετε TTFB <100ms ακόμα και για προσωποποιημένο περιεχόμενο.

Συνεχής παρακολούθηση με RUM

Τα lab tests (Lighthouse, WebPageTest) δίνουν επαναλήψιμα αποτελέσματα, αλλά δεν αντιπροσωπεύουν τους πραγματικούς χρήστες. Η Google κατατάσσει με βάση field data από CrUX. Εγκαταστήστε ένα RUM script που στέλνει LCP, INP, CLS και TTFB στο analytics endpoint σας:

// Χρήση του επίσημου web-vitals library
import { onLCP, onINP, onCLS, onTTFB } from 'web-vitals/attribution';

const thresholds = {
  LCP: { good: 2500, poor: 4000 },
  INP: { good: 200, poor: 500 },
  CLS: { good: 0.1, poor: 0.25 },
  TTFB: { good: 800, poor: 1800 },
};

function sendToAnalytics({ name, value, attribution, navigationType }) {
  const body = JSON.stringify({
    metric: name,
    value,
    target: attribution.element || attribution.url,
    navType: navigationType,
    rating: value < thresholds[name].good ? 'good' : 'poor',
  });

  navigator.sendBeacon('/api/rum', body);
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);
onTTFB(sendToAnalytics);

Το attribution entry του web-vitals 4.x περιλαμβάνει το element selector του LCP target και breakdown των 4 υπο-σταδίων, εξαιρετικά πολύτιμο για διάγνωση χωρίς πρόσβαση στη συσκευή του χρήστη.

Συχνές ερωτήσεις

Ποιο είναι το καλό LCP για το 2026;