Core Web Vitals με απλά λόγια: LCP, INP και CLS

Τα Core Web Vitals δεν είναι τεστ προσωπικότητας για τον ιστότοπό σας

Τα Core Web Vitals αντιμετωπίζονται συχνά σαν ένας μυστηριώδης πίνακας βαθμολογίας. Μια σελίδα παίρνει έναν κόκκινο αριθμό, κάποιος ανεβάζει ένα screenshot στο Slack και η ομάδα αρχίζει να διαφωνεί για JavaScript frameworks.

Αυτό δεν είναι ιδιαίτερα χρήσιμο.

Ο καλύτερος τρόπος να σκεφτείτε τα Core Web Vitals είναι πιο απλός: είναι τρεις μετρήσεις για το αν μια σελίδα φαίνεται εύχρηστη σε έναν πραγματικό άνθρωπο, σε μια πραγματική συσκευή. Δεν αποτυπώνουν κάθε πλευρά της απόδοσης, της προσβασιμότητας ή της ποιότητας. Αλλά εντοπίζουν τρεις συνηθισμένες πηγές εκνευρισμού:

• Το κύριο περιεχόμενο αργεί υπερβολικά να εμφανιστεί.
• Η σελίδα αντιδρά αργά όταν ο χρήστης προσπαθεί να κάνει κάτι.
• Η διάταξη μετακινείται ενώ ο χρήστης διαβάζει ή πατάει.

Αυτά είναι τα τρία Core Web Vitals: LCP, INP και CLS.

Η Google τα χρησιμοποιεί ως μέρος των σημάτων εμπειρίας σελίδας, αλλά η οπτική του SEO δεν είναι ο καλύτερος λόγος για να σας ενδιαφέρουν. Ο καλύτερος λόγος είναι ότι οι αργές, ασταθείς και μη αποκρίσιμες σελίδες σπαταλούν τον χρόνο των χρηστών. Τείνουν επίσης να έχουν χειρότερες μετατροπές, να υποστηρίζονται πιο δύσκολα και να γερνούν άσχημα.

Οι τρεις μετρικές σε μία πρόταση η καθεμία

Πριν μπούμε στις λεπτομέρειες, εδώ είναι η εκδοχή με απλά λόγια:

• LCP, ή Largest Contentful Paint, μετρά πόσο χρόνο χρειάζεται για να φορτώσει το κύριο ορατό περιεχόμενο.
• INP, ή Interaction to Next Paint, μετρά πόσο γρήγορα ανταποκρίνεται η σελίδα στις αλληλεπιδράσεις του χρήστη σε όλη τη διάρκεια της επίσκεψης.
• CLS, ή Cumulative Layout Shift, μετρά πόσο μετακινείται απροσδόκητα η σελίδα.

Τα συνήθη όρια είναι:

| Μετρική | Καλή | Χρειάζεται βελτίωση | Κακή | |---|---:|---:|---:| | LCP | 2.5s ή ταχύτερα | 2.5s–4.0s | Πάνω από 4.0s | | INP | 200ms ή ταχύτερα | 200ms–500ms | Πάνω από 500ms | | CLS | 0.1 ή χαμηλότερο | 0.1–0.25 | Πάνω από 0.25 |

Αυτοί οι αριθμοί αξιολογούνται συνήθως στο 75ο εκατοστημόριο των πραγματικών επισκέψεων χρηστών. Αυτό έχει σημασία. Δεν προσπαθείτε να πετύχετε μία τέλεια εργαστηριακή εκτέλεση. Προσπαθείτε να κάνετε την εμπειρία καλή για τους περισσότερους χρήστες, συμπεριλαμβανομένων ανθρώπων με πιο αργά τηλέφωνα και πιο ασταθή δίκτυα.

Αν κοιτάζετε μια αυτοματοποιημένη αναφορά και δεν είστε σίγουροι από πού να ξεκινήσετε, βοηθά να ξεχωρίσετε τη διάγνωση από τον πανικό. Έχουμε έναν ξεχωριστό οδηγό για το πώς να διαβάζετε μια αναφορά Lighthouse χωρίς πανικό, που καλύπτει αυτή τη ροή εργασίας με περισσότερες λεπτομέρειες.

LCP: πότε η σελίδα φαίνεται φορτωμένη;

Το Largest Contentful Paint μετρά τον χρόνο απόδοσης του μεγαλύτερου ορατού στοιχείου περιεχομένου στο viewport. Στην πράξη, αυτό είναι συχνά:

• μια hero image,
• ένας μεγάλος τίτλος,
• μια εικόνα επιλεγμένου άρθρου,
• μια εικόνα προϊόντος,
• ένα μεγάλο μπλοκ κειμένου.

Το LCP δεν ρωτά πότε ολοκλήρωσε τη φόρτωσή του κάθε script, tracking pixel και εικόνα κάτω από το fold. Ρωτά: πότε έγινε ορατό το κύριο πράγμα που ήρθε να δει ο χρήστης;

Αυτό κάνει το LCP μια πιο ανθρώπινη μετρική από τον παλιό «χρόνο φόρτωσης σελίδας». Μια σελίδα μπορεί τεχνικά να ολοκληρώσει τη φόρτωσή της αργά, αλλά να φαίνεται γρήγορη αν το κύριο περιεχόμενο εμφανιστεί γρήγορα. Ισχύει και το αντίστροφο: μια σελίδα μπορεί να ενεργοποιήσει το συμβάν load ενώ η hero περιοχή παραμένει κενή, θολή ή μπλοκαρισμένη από καθυστέρηση render.

Συνηθισμένες αιτίες κακού LCP

Τα περισσότερα προβλήματα κακού LCP προέρχονται από λίγα προβλέψιμα σημεία:

1. Αργή απόκριση server

Αν το έγγραφο HTML φτάσει αργά, όλα τα υπόλοιπα ξεκινούν αργά.

1. CSS ή JavaScript που μπλοκάρουν το render

Ο browser έχει το περιεχόμενο, αλλά δεν μπορεί ακόμη να το ζωγραφίσει.

1. Μη βελτιστοποιημένες hero images

Το μεγαλύτερο στοιχείο είναι υπερβολικά μεγάλο, σε λάθος μορφή, δεν έχει προτεραιοποιηθεί ή φορτώνεται κατά λάθος με lazy loading.

1. Web fonts που καθυστερούν την απόδοση κειμένου

Ένας μεγάλος τίτλος μπορεί να είναι το στοιχείο LCP, και η φόρτωση γραμματοσειρών μπορεί να τον καθυστερήσει ή να τον αλλοιώσει οπτικά.

1. Καθυστερήσεις client-side rendering

Αν η σελίδα χρειάζεται ένα μεγάλο JavaScript bundle πριν μπορέσει να εμφανίσει ουσιαστικό περιεχόμενο, το LCP υποφέρει.

Πώς να βελτιώσετε το LCP

Ξεκινήστε από το πραγματικό στοιχείο LCP. Μη βελτιστοποιείτε τυχαία assets μέχρι να ξέρετε τι μετρά ο browser.

Πρακτικές διορθώσεις περιλαμβάνουν:

• Σερβίρετε HTML γρήγορα: κάντε cache όπου χρειάζεται, μειώστε τη δουλειά στο backend, αποφύγετε αργά redirects.
• Βελτιστοποιήστε την εικόνα LCP: χρησιμοποιήστε τις σωστές διαστάσεις, συμπίεση και μορφή.
• Μην κάνετε lazy-load την hero image πάνω από το fold.
• Χρησιμοποιήστε fetchpriority="high" προσεκτικά για την κύρια εικόνα όταν είναι πραγματικά η προτεραιότητα.
• Κάντε inline το critical CSS μόνο όταν μειώνει ουσιαστικά την καθυστέρηση render.
• Μειώστε το JavaScript που απαιτείται πριν από το πρώτο ουσιαστικό render.
• Χρησιμοποιήστε font-display: swap ή άλλη σκόπιμη στρατηγική για γραμματοσειρές.

Οι εικόνες και οι γραμματοσειρές είναι συχνοί ένοχοι. Για τις εικόνες, ο συμβιβασμός δεν είναι απλώς «μικρό αρχείο καλό». Η επιλογή μορφής, η προσπάθεια κωδικοποίησης και η υποστήριξη από browsers έχουν όλα σημασία, γι’ αυτό διατηρούμε ένα πρακτικό δέντρο αποφάσεων για το πότε το AVIF ξεπερνά το WebP και πότε όχι. Για σελίδες με πολύ κείμενο, τα web fonts παραμένουν ένα από τα ευκολότερα performance wins, επειδή πολλοί ιστότοποι στέλνουν περισσότερα αρχεία γραμματοσειρών από όσα χρησιμοποιούν.

INP: ανταποκρίνεται η σελίδα όταν την αγγίζετε;

Το Interaction to Next Paint μετρά την αποκρισιμότητα. Πιο συγκεκριμένα, εξετάζει την καθυστέρηση μεταξύ μιας αλληλεπίδρασης χρήστη και της επόμενης οπτικής ενημέρωσης αφού ο browser επεξεργαστεί αυτή την αλληλεπίδραση.

Οι αλληλεπιδράσεις περιλαμβάνουν πράγματα όπως:

• κλικ σε ένα κουμπί,
• πάτημα σε ένα μενού,
• επιλογή ενός checkbox,
• πληκτρολόγηση σε ένα πεδίο φόρμας,
• άνοιγμα ενός accordion.

Το INP αντικατέστησε το First Input Delay ως Core Web Vital το 2024. Ήταν μια καλή αλλαγή. Το First Input Delay εξέταζε μόνο την πρώτη αλληλεπίδραση. Το INP είναι ευρύτερο: λαμβάνει υπόψη αλληλεπιδράσεις σε όλη την επίσκεψη στη σελίδα και αναφέρει μια αλληλεπίδραση υψηλής καθυστέρησης ως τη βαθμολογία αποκρισιμότητας της σελίδας.

Με απλά λόγια: το INP εντοπίζει σελίδες που φαίνονται φορτωμένες αλλά δίνουν την αίσθηση ότι έχουν κολλήσει.

Πιθανότατα έχετε χρησιμοποιήσει μια τέτοια σελίδα. Φαίνεται έτοιμη. Πατάτε το μενού. Δεν συμβαίνει τίποτα για μισό δευτερόλεπτο. Πατάτε ξανά. Μετά συμβαίνουν δύο πράγματα ταυτόχρονα. Αυτό είναι πρόβλημα INP.

Συνηθισμένες αιτίες κακού INP

Το INP είναι συνήθως πρόβλημα main thread. Ο browser θέλει να ανταποκριθεί, αλλά JavaScript, εργασίες rendering ή υπολογισμοί layout βρίσκονται στη μέση.

Τυπικές αιτίες περιλαμβάνουν:

• μεγάλα JavaScript bundles,
• ακριβά event handlers,
• εργασίες hydration σε client-rendered apps,
• third-party scripts που ανταγωνίζονται για το main thread,
• μακρόχρονες εργασίες μετά τη φόρτωση της σελίδας,
• σύνθετες ενημερώσεις DOM που ενεργοποιούνται από μικρές αλληλεπιδράσεις,
• layout thrashing, όπου ο κώδικας διαβάζει και γράφει επανειλημμένα τιμές layout.

Marketing tags, analytics, chat widgets και consent banners μπορούν όλα να συμβάλουν. Αυτό δεν σημαίνει «αφαιρέστε τα πάντα». Σημαίνει ότι κάθε script στη σελίδα έχει κόστος, και η καθυστέρηση αλληλεπίδρασης είναι το σημείο όπου αυτό το κόστος γίνεται συχνά ορατό.

Πώς να βελτιώσετε το INP

Η βελτίωση του INP αφορά λιγότερο ένα μαγικό attribute και περισσότερο τη μείωση του ανταγωνισμού στο main thread.

Χρήσιμες προσεγγίσεις περιλαμβάνουν:

• Σπάστε μεγάλες JavaScript εργασίες σε μικρότερα κομμάτια.
• Αναβάλετε μη απαραίτητες εργασίες μέχρι η σελίδα να είναι χρησιμοποιήσιμη.
• Αφαιρέστε αχρησιμοποίητο JavaScript αντί απλώς να το κάνετε minify.
• Κρατήστε τους event handlers μικρούς και προβλέψιμους.
• Αποφύγετε το re-rendering μεγάλων τμημάτων της διεπαφής για μικροσκοπικές αλλαγές κατάστασης.
• Χρησιμοποιήστε CSS για απλές οπτικές καταστάσεις όπου είναι δυνατό.
• Ελέγξτε τα third-party scripts και φορτώστε τα μόνο όπου χρειάζονται.

Κοιτάξτε επίσης τον σχεδιασμό αλληλεπίδρασης. Ένα κουμπί που δίνει άμεσο οπτικό feedback μπορεί να φαίνεται πιο αποκρίσιμο, ακόμη κι αν η επόμενη εργασία διαρκεί περισσότερο. Αυτό δεν υποκαθιστά την απόδοση, αλλά είναι μέρος της καλής μηχανικής διεπαφών. Η λίστα ελέγχου μας για προσβάσιμα web buttons επικαλύπτεται με αυτό: σαφείς καταστάσεις, σωστή σημασιολογία και προβλέψιμη συμπεριφορά βοηθούν τόσο τους χρήστες όσο και τους browsers.

CLS: μένει η σελίδα εκεί όπου την περιμένει ο χρήστης;

Το Cumulative Layout Shift μετρά την απροσδόκητη μετακίνηση ορατών στοιχείων. Αν ένας χρήστης αρχίσει να διαβάζει μια παράγραφο και μια διαφήμιση, εικόνα ή banner φορτώσει από πάνω της, σπρώχνοντας το κείμενο προς τα κάτω, αυτό συμβάλλει στο CLS.

Το CLS δεν μετριέται σε δευτερόλεπτα. Είναι μια βαθμολογία με βάση το πόσο περιεχόμενο μετακινήθηκε και πόσο μακριά μετακινήθηκε. Όσο χαμηλότερο, τόσο καλύτερα.

Η λέξη-κλειδί είναι απροσδόκητη. Οι αλλαγές layout που προκαλούνται από ενέργεια χρήστη συνήθως δεν μετρώνται με τον ίδιο τρόπο. Αν κάποιος πατήσει «εμφάνιση περισσότερων» και το περιεχόμενο επεκταθεί, αυτό είναι αναμενόμενο. Αν ένα newsletter banner εμφανιστεί στην κορυφή μετά από τρία δευτερόλεπτα και σπρώξει τα πάντα προς τα κάτω, αυτό δεν είναι.

Συνηθισμένες αιτίες κακού CLS

Οι αποτυχίες CLS είναι συχνά πεζές:

• εικόνες χωρίς attributes width και height,
• διαφημίσεις ή embeds χωρίς δεσμευμένο χώρο,
• cookie banners που εισάγονται πάνω από το περιεχόμενο,
• web fonts που αλλάζουν με διαφορετικά metrics,
• promotional bars που φορτώνουν αργά,
• δυναμικά εισαγόμενο περιεχόμενο κοντά στην κορυφή της σελίδας.

Η διόρθωση είναι συνήθως να δεσμεύσετε χώρο πριν φτάσει το περιεχόμενο. Ο browser πρέπει να γνωρίζει το σχήμα της σελίδας όσο το δυνατόν νωρίτερα.

Πώς να βελτιώσετε το CLS

Ξεκινήστε από τις ορατές μετατοπίσεις. Παρακολουθήστε μια εγγραφή ή χρησιμοποιήστε εργαλεία browser για να εντοπίσετε ποια στοιχεία μετακινούνται.

Μετά εφαρμόστε τις βαρετές διορθώσεις:

• Προσθέστε ρητά attributes width και height στις εικόνες.
• Χρησιμοποιήστε CSS aspect-ratio για responsive media containers.
• Δεσμεύστε σταθερό ή ελάχιστο χώρο για διαφημίσεις, embeds και iframes.
• Αποφύγετε την εισαγωγή banners πάνω από υπάρχον περιεχόμενο μετά τη φόρτωση.
• Επιλέξτε font fallbacks με παρόμοια metrics με την τελική γραμματοσειρά.
• Αποφύγετε animations που αλλάζουν ιδιότητες layout όπως top, left, width ή height; προτιμήστε transforms.

Το CLS είναι μία από τις λίγες μετρικές απόδοσης όπου η πειθαρχία κερδίζει την εξυπνάδα. Αν η σελίδα έχει σταθερά πλαίσια, συνήθως θα έχει καλή βαθμολογία.

Τα field data και τα lab data είναι και τα δύο χρήσιμα, αλλά απαντούν σε διαφορετικές ερωτήσεις

Μια συνηθισμένη πηγή σύγχυσης είναι ότι διαφορετικά εργαλεία δείχνουν διαφορετικούς αριθμούς. Αυτό είναι φυσιολογικό.

Field data προέρχονται από πραγματικούς χρήστες. Αντανακλούν πραγματικές συσκευές, δίκτυα, τοποθεσίες και συνθήκες browser. Το Chrome User Experience Report της Google είναι παράδειγμα field data.

Lab data προέρχονται από ένα ελεγχόμενο περιβάλλον δοκιμών. Το Lighthouse είναι το γνωστό παράδειγμα. Είναι επαναλήψιμο και χρήσιμο για debugging, αλλά δεν είναι το ίδιο με τη βιωμένη εμπειρία των χρηστών σας.

Χρησιμοποιήστε field data για να αποφασίσετε αν οι χρήστες έχουν πραγματικό πρόβλημα. Χρησιμοποιήστε lab data για να αναπαράγετε και να debugάρετε αυτό το πρόβλημα.

Θυμηθείτε επίσης ότι τα Core Web Vitals συνήθως αξιολογούνται ανά URL ή ομάδα URL, όχι ως μία αφηρημένη ιδιότητα του brand σας. Η αρχική σας σελίδα, το άρθρο blog, η σελίδα τιμών και το checkout μπορεί να έχουν πολύ διαφορετικά bottlenecks.

Μια λογική σειρά εργασιών

Αν και οι τρεις μετρικές είναι κακές, ο πειρασμός είναι να ξεκινήσετε παντού. Αντισταθείτε.

Μια πρακτική σειρά είναι:

1. Διορθώστε πρώτα τα προφανή CLS

Οι διαστάσεις εικόνων που λείπουν και τα ασταθή banners είναι συχνά γρήγορες νίκες.

1. Βελτιώστε το LCP για σημαντικά templates

Εστιάστε στις σελίδες που έχουν σημασία: σελίδες προϊόντων, landing pages, άρθρα, ροές εγγραφής.

1. Διερευνήστε το INP με πραγματικές αλληλεπιδράσεις

Κάντε κλικ σε όσα πραγματικά κάνουν κλικ οι χρήστες. Μενού, φίλτρα, φόρμες και στοιχεία ελέγχου checkout συχνά αποκαλύπτουν περισσότερα από το αρχικό load trace.

1. Ελέγξτε τα third-party scripts

Κρατήστε όσα δικαιολογούν το κόστος τους. Αφαιρέστε ή καθυστερήστε όσα δεν το κάνουν.

1. Θέστε ένα performance budget

Χωρίς budget, οι βελτιώσεις απόδοσης φθείρονται. Νέα scripts, εικόνες και design components θα αναιρέσουν σιωπηλά τη δουλειά.

Το σημαντικό σημείο: μη βελτιστοποιείτε για ένα badge. Βελτιστοποιήστε για το user journey. Μια οριακή βελτίωση βαθμολογίας σε μια σελίδα χαμηλής επισκεψιμότητας μπορεί να έχει μικρότερη σημασία από μια ελαφρώς ατελή αλλά πολύ ταχύτερη αλληλεπίδραση checkout.

<!-- tool-cta:start -->

💡 Δοκιμάστε αυτό: Επειδή το LCP είναι συνήθως πρόβλημα εικόνας, μικρύνετε το κύριο οπτικό στοιχείο σας με το Image Compressor ως μια πρώτη, εύκολη νίκη.

<!-- tool-cta:end -->

Τι δεν σας λένε τα Core Web Vitals

Τα Core Web Vitals είναι χρήσιμα, αλλά ελλιπή.

Δεν σας λένε αν το περιεχόμενό σας είναι καλό. Δεν σας λένε αν η πλοήγησή σας βγάζει νόημα. Δεν εγγυώνται προσβασιμότητα. Δεν μετρούν ιδιωτικότητα, ασφάλεια, εμπιστοσύνη, αναγνωσιμότητα ή αν η σελίδα απαντά στην ερώτηση του χρήστη.

Επίσης, δεν αντικαθιστούν την κρίση. Μια σελίδα μπορεί να περνά τα Core Web Vitals και παρ’ όλα αυτά να είναι δυσάρεστη. Μια σύνθετη εφαρμογή μπορεί να μην πιάνει ένα όριο και παρ’ όλα αυτά να είναι υπεύθυνα σχεδιασμένη για τους περιορισμούς της.

Αντιμετωπίστε τα LCP, INP και CLS σαν συναγερμούς καπνού. Όταν χτυπούν, διερευνήστε. Όταν είναι ήσυχα, συνεχίστε να συντηρείτε το κτίριο.