Core Web Vitals: τι μετράει η Google και πώς βελτιώνονται.

Ανοίγετε το PageSpeed Insights, γράφετε τη διεύθυνση του site σας και βλέπετε ένα πορτοκαλί 54. Είναι αυτός ο λόγος που δεν ανεβαίνετε στη Google; Η απάντηση είναι πιο σύνθετη, και ξεκινά από τα Core Web Vitals: τρεις μετρήσεις με τις οποίες η Google αποτιμά πώς ζουν οι πραγματικοί επισκέπτες τη φόρτωση και τη χρήση μιας σελίδας.

Παρακάτω θα δείτε τι μετράει η καθεμία, ποια όρια ισχύουν, πόσο βαραίνουν πραγματικά στην κατάταξη και ποιες αλλαγές σε ένα WordPress site αξίζουν πρώτες. Είναι και οι διορθώσεις που κάνουμε πιο συχνά στα sites που συντηρούμε.

01Τι είναι τα Core Web Vitals: LCP, INP και CLS

Τα Core Web Vitals είναι το βασικό υποσύνολο των Web Vitals, των μετρήσεων της Google για την εμπειρία χρήστη. Είναι τρεις, και η καθεμία απαντά σε μια απλή ερώτηση:

• LCP (Largest Contentful Paint), φόρτωση. Πόσο γρήγορα εμφανίζεται το μεγαλύτερο στοιχείο της πρώτης οθόνης, συνήθως η κεντρική εικόνα ή ο τίτλος. Είναι η στιγμή που ο επισκέπτης νιώθει ότι η σελίδα «ήρθε».
• INP (Interaction to Next Paint), απόκριση. Πόσο γρήγορα αντιδρά η σελίδα όταν πατάτε ένα κουμπί, ανοίγετε ένα μενού ή γράφετε σε ένα πεδίο, σε όλη τη διάρκεια της επίσκεψης. Το INP αντικατέστησε το παλαιότερο FID στις 12 Μαρτίου 2024.
• CLS (Cumulative Layout Shift), σταθερότητα. Πόσο «πηδάει» το περιεχόμενο ενώ φορτώνει. Το κλασικό παράδειγμα: πάτε να πατήσετε έναν σύνδεσμο και την τελευταία στιγμή κατεβαίνει, επειδή από πάνω φόρτωσε μια εικόνα ή ένα banner.

Τα όρια, όπως τα δείχνει η αναφορά Core Web Vitals του Search Console:

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

02Πραγματικοί χρήστες ή εργαστήριο: ποιο νούμερο μετράει

Υπάρχουν δύο ειδών μετρήσεις, και η σύγχυση ανάμεσά τους είναι η πιο συχνή παρεξήγηση που ακούμε.

Δεδομένα πεδίου (field data) είναι μετρήσεις από πραγματικούς επισκέπτες με Chrome, συγκεντρωμένες στο Chrome User Experience Report (CrUX). Αυτά δείχνει η αναφορά του Search Console. Μια σελίδα θεωρείται «καλή» όταν τουλάχιστον το 75% των επισκέψεων είναι μέσα στο όριο (75ο εκατοστημόριο), χωριστά για κινητά και για υπολογιστές, και περνάει μόνο όταν πιάνει τον στόχο και στις τρεις μετρήσεις.

Δεδομένα εργαστηρίου (lab data) είναι μια προσομοίωση: το Lighthouse φορτώνει τη σελίδα μία φορά, σε συγκεκριμένη συσκευή και ταχύτητα δικτύου. Από εκεί βγαίνει το γνωστό σκορ 0–100 του PageSpeed Insights. Είναι πολύτιμο για να βρείτε τι φταίει, αλλά δεν είναι αυτό που δείχνει η αναφορά Core Web Vitals. Το Lighthouse δεν μπορεί καν να μετρήσει το INP, αφού δεν υπάρχει πραγματικός χρήστης να πατήσει κάτι, και χρησιμοποιεί ως ένδειξη το Total Blocking Time (TBT).

03Πώς μετράτε τα Core Web Vitals του site σας

Δύο δωρεάν εργαλεία της Google αρκούν:

• PageSpeed Insights. Στο πάνω μέρος δείχνει τα δεδομένα πεδίου για τη σελίδα και για όλο το site, αν υπάρχουν αρκετά. Από κάτω, τη διάγνωση του Lighthouse με τις συγκεκριμένες αιτίες. Ξεκινήστε από την καρτέλα για κινητά, όπου τα αποτελέσματα είναι συνήθως χειρότερα.
• Search Console. Η αναφορά Core Web Vitals ομαδοποιεί σελίδες με παρόμοια εμπειρία, π.χ. όλα τα προϊόντα ενός e-shop, και δείχνει ποια ομάδα έχει πρόβλημα και σε ποια μέτρηση. Η κατάσταση της ομάδας είναι η χειρότερη από τις τρεις. Όταν διορθώσετε κάτι, ξεκινάτε την επικύρωση και η Google παρακολουθεί τις σελίδες για 28 ημέρες.

Ένα σημείο που αφορά πολλές μικρές επιχειρήσεις: αν το site δεν έχει αρκετή κίνηση, το Search Console θα γράφει ότι δεν υπάρχουν διαθέσιμα δεδομένα και το PageSpeed Insights θα δείχνει μόνο το εργαστήριο. Αυτό δεν σημαίνει ότι όλα είναι καλά. Σημαίνει ότι οδηγός σας είναι το Lighthouse, με προσοχή στο LCP, στο CLS και στο TBT.

04Πόσο μετράνε για τη Google και για τις πωλήσεις

Η Google γράφει ότι τα Core Web Vitals χρησιμοποιούνται από τα συστήματα κατάταξης. Γράφει όμως εξίσου καθαρά ότι δεν υπάρχει ένα ενιαίο σήμα «εμπειρίας σελίδας», ότι προτεραιότητα έχει πάντα το πιο σχετικό περιεχόμενο ακόμη κι αν η εμπειρία δεν είναι καλή, και ότι καλά νούμερα στις αναφορές δεν εγγυώνται τις πρώτες θέσεις. Μπορούν να βοηθήσουν όταν για μια αναζήτηση υπάρχουν πολλές εξίσου χρήσιμες σελίδες.

Με απλά λόγια: ένα αργό site με το καλύτερο περιεχόμενο για «ενοικίαση σκάφους Κέρκυρα» δεν θα εξαφανιστεί από την πρώτη σελίδα. Ανάμεσα σε πέντε παρόμοια sites ενοικίασης, όμως, η εμπειρία στη σελίδα μπορεί να είναι ένας από τους παράγοντες που τα ξεχωρίζουν.

Ο πιο άμεσος λόγος να ασχοληθείτε είναι οι επισκέπτες που ήδη έρχονται. Η Vodafone Ιταλίας έκανε A/B test σε landing page: η έκδοση με 31% καλύτερο LCP έφερε 8% περισσότερες πωλήσεις. Σε μελέτη της Deloitte με ανάθεση από τη Google σε 37 brands της Ευρώπης και των ΗΠΑ, βελτίωση 0,1 δευτερολέπτου σε τέσσερις μετρήσεις ταχύτητας στο κινητό συνδέθηκε με 8,4% περισσότερες μετατροπές στα retail sites και 9,2% μεγαλύτερη δαπάνη ανά πελάτη. Είναι στοιχεία μεγάλων επιχειρήσεων και όχι εγγύηση για κάθε site, δείχνουν όμως προς τα πού γέρνει η ζυγαριά.

05LCP στο WordPress: server, cache και εικόνες

Στα WordPress sites που ελέγχουμε, το LCP είναι συνήθως το πρώτο πρόβλημα. Κατά το web.dev, το 40% των sites στο CrUX δεν πιάνει το όριο. Οι αιτίες είναι κυρίως δύο: αργή απάντηση του server και βαριά ή καθυστερημένη κεντρική εικόνα.

Hosting και page cache

Χωρίς cache, το WordPress φτιάχνει κάθε σελίδα από την αρχή σε κάθε επίσκεψη, με PHP και ερωτήματα στη βάση. Σε υπερφορτωμένο shared hosting αυτό τρώει χρόνο πριν καν ξεκινήσει να φορτώνει οτιδήποτε άλλο. Ένα page cache σερβίρει έτοιμη HTML και ένα CDN τη φέρνει πιο κοντά στον επισκέπτη· σύμφωνα με το web.dev, μόνο το 33% των αιτημάτων για σελίδες HTML εξυπηρετείται από CDN. Στα e-shops το καλάθι και το checkout δεν μπαίνουν σε cache, οπότε εκεί ο server μετράει διπλά. Γι’ αυτό η ταχύτητα ξεκινά από τη συντήρηση και το hosting, όχι από ένα plugin.

Εικόνες στο σωστό μέγεθος και format

Μια φωτογραφία από το κινητό, ανεβασμένη όπως είναι, είναι ο πιο συνηθισμένος ένοχος. Ανεβάστε εικόνες στο μέγεθος που χρειάζεται το θέμα, σε WebP ή AVIF, και αφήστε το WordPress να φτιάξει τις μικρότερες εκδοχές (srcset), ώστε το κινητό να κατεβάζει μικρότερο αρχείο.

Η κεντρική εικόνα δεν θέλει lazy-loading

Το lazy-loading καθυστερεί τις εικόνες μέχρι να χρειαστούν. Είναι σωστό για όσες βρίσκονται πιο κάτω και λάθος για την εικόνα της πρώτης οθόνης, που πρέπει να φορτώνει αμέσως, με fetchpriority=”high”. Από την έκδοση 6.3, το WordPress το κάνει μόνο του για την εικόνα που θεωρεί πιθανή LCP, κάτι που κατά την ομάδα του βελτιώνει συνήθως το LCP κατά 5–10%. Δεν μπορεί όμως να το κάνει όταν η εικόνα μπαίνει ως background από το CSS ή όταν ένα slider τη φορτώνει με JavaScript. Το web.dev αναφέρει ότι στο 73% των σελίδων σε κινητό το στοιχείο LCP είναι εικόνα και ότι στο 35% αυτών η διεύθυνση της εικόνας δεν φαίνεται στην αρχική HTML.

Γραμματοσειρές

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

06INP: λιγότερο JavaScript, λιγότερα βάρη

Το INP χαλάει όταν ο browser είναι απασχολημένος με JavaScript και δεν προλαβαίνει να απαντήσει στο πάτημα του χρήστη. Οι εργασίες πάνω από 50 ms θεωρούνται «μεγάλες» και καθυστερούν την απόκριση. Στο WordPress, το JavaScript έρχεται κυρίως από τρεις πηγές:

• Page builders και «πολυεργαλεία» themes. Φορτώνουν κώδικα για δεκάδες λειτουργίες σε κάθε σελίδα, ακόμη κι αν η σελίδα χρησιμοποιεί δύο. Γι’ αυτό φτιάχνουμε custom themes χωρίς page builder. Το τι σημαίνει αυτό για τον προϋπολογισμό το εξηγούμε στο άρθρο για το πόσο κοστίζει μια ιστοσελίδα.
• Plugins. Το πρόβλημα δεν είναι μόνο ο αριθμός τους, αλλά τι φορτώνει το καθένα και πού. Ένα plugin φόρμας που φορτώνει τα scripts του σε όλες τις σελίδες, ενώ η φόρμα υπάρχει μόνο στην επικοινωνία, είναι συνηθισμένο εύρημα.
• Third-party scripts. Chat, pixels διαφήμισης, χάρτες, widgets κρατήσεων, cookie banners. Κρατήστε όσα πραγματικά χρησιμοποιείτε και φορτώστε τα υπόλοιπα αργότερα ή μόνο στις σελίδες που τα χρειάζονται.

07CLS: κρατήστε χώρο για ό,τι φορτώνει αργότερα

Το CLS είναι συνήθως το πιο εύκολο να διορθωθεί. Οι βασικές αιτίες:

• Εικόνες χωρίς διαστάσεις. Με width και height (ή aspect-ratio στο CSS) ο browser κρατά τον χώρο πριν φτάσει η εικόνα. Κατά το web.dev, το 66% των σελίδων έχει τουλάχιστον μία εικόνα χωρίς διαστάσεις.
• Στοιχεία που εμφανίζονται από πάνω. Banners προσφορών, ειδοποιήσεις και ενσωματώσεις (χάρτες, βίντεο, social) χρειάζονται δεσμευμένο ύψος. Ένα cookie banner που σπρώχνει τη σελίδα αντί να εμφανίζεται πάνω της είναι κλασικό λάθος.
• Animations. Κινήσεις με transform, αντί για top, margin ή ύψος, δεν μετακινούν το υπόλοιπο περιεχόμενο.
• Γραμματοσειρές. Όταν η τελική γραμματοσειρά διαφέρει πολύ σε μέγεθος από την προσωρινή, το κείμενο αλλάζει πλάτος και σπρώχνει ό,τι βρίσκεται γύρω του.

08Από πού να ξεκινήσετε

1. Δείτε τα δεδομένα πεδίου στο Search Console ή στο PageSpeed Insights, πρώτα για κινητά. Αν όλα είναι στο «Καλό», η ταχύτητα δεν είναι το πρόβλημά σας.
2. Αν το LCP είναι κακό σε όλο το site, κοιτάξτε πρώτα server και cache. Αν είναι κακό σε συγκεκριμένα templates, κοιτάξτε την κεντρική τους εικόνα.
3. Για το INP, καταγράψτε ποια scripts τρέχουν σε κάθε σελίδα και αφαιρέστε ό,τι δεν χρειάζεται.
4. Για το CLS, ελέγξτε διαστάσεις εικόνων, banners και γραμματοσειρές.
5. Μετά από κάθε αλλαγή, δώστε χρόνο: τα δεδομένα πεδίου αλλάζουν σταδιακά και η επικύρωση στο Search Console διαρκεί 28 ημέρες.

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