Core Web Vitals για e-shops: LCP, INP και CLS στην πράξη

Τα Core Web Vitals είναι οι τρεις μετρικές με τις οποίες η Google αξιολογεί την εμπειρία χρήστη σε μια σελίδα. Για ένα e-shop δεν είναι απλώς «θέμα SEO»: ένα αργό ή «χοροπηδηχτό» site χάνει πωλήσεις, ιδιαίτερα στο κινητό, όπου γίνεται η μεγάλη πλειονότητα της κίνησης. Ας τα δούμε χωρίς θεωρία, με το βλέμμα στο τι διορθώνουμε στην πράξη.

Οι τρεις μετρικές σε μία παράγραφο η καθεμία

LCP (Largest Contentful Paint): πόσο γρήγορα εμφανίζεται το μεγαλύτερο στοιχείο της οθόνης — σε ένα e-shop συνήθως η κύρια φωτογραφία προϊόντος ή το banner της αρχικής. Καλό: έως 2,5 δευτερόλεπτα.

INP (Interaction to Next Paint): πόσο γρήγορα αντιδρά η σελίδα όταν ο χρήστης πατάει κάτι — ένα φίλτρο, το «Προσθήκη στο καλάθι», την επιλογή μεγέθους. Αντικατέστησε το παλιότερο FID. Καλό: έως 200 ms.

CLS (Cumulative Layout Shift): πόσο «μετακινείται» το περιεχόμενο ενώ φορτώνει. Το κλασικό παράδειγμα: πάτε να πατήσετε ένα κουμπί και αυτό κατεβαίνει επειδή φόρτωσε ένα banner από πάνω. Καλό: έως 0,1.

Η Google κρίνει αν μια σελίδα «περνάει» με βάση το 75ο εκατοστημόριο των πραγματικών επισκέψεων — δηλαδή το 75% των επισκεπτών σας πρέπει να έχει καλή εμπειρία.

Πού μετράτε (και γιατί τα νούμερα διαφέρουν)

• Field data (πραγματικοί χρήστες): η αναφορά Core Web Vitals στο Google Search Console και η ενότητα πραγματικών δεδομένων του PageSpeed Insights. Αυτά μετράνε για την Google.
• Lab data (προσομοίωση): το Lighthouse και η βαθμολογία του PageSpeed Insights. Χρήσιμα για διάγνωση, αλλά δεν είναι αυτά που «βλέπει» η Google για το ranking.

Μην κυνηγάτε το «100/100» στο Lighthouse. Κυνηγήστε τα πράσινα field data στις σελίδες που φέρνουν έσοδα. Για μικρά sites που δεν έχουν αρκετή κίνηση για field data, το lab data είναι ο καλύτερος οδηγός που έχετε.

Τα τέσσερα πρότυπα σελίδων που μετράνε

Ένα e-shop έχει ουσιαστικά τέσσερα templates. Διορθώστε τα templates, όχι τις μεμονωμένες σελίδες:

1. Αρχική: συνήθως πρόβλημα LCP από βαρύ slider.
2. Κατηγορία: συνήθως πρόβλημα INP από φίλτρα και CLS από εικόνες χωρίς διαστάσεις.
3. Προϊόν: συνήθως LCP από την κύρια φωτογραφία και INP από επιλογείς παραλλαγών.
4. Καλάθι/Checkout: συνήθως INP από βαριά scripts πληρωμών και υπολογισμούς αποστολής.

Διόρθωση LCP

Το LCP σε e-shop σχεδόν πάντα είναι εικόνα. Οι διορθώσεις κατά σειρά αποτελεσματικότητας:

• Χρόνος απόκρισης server (TTFB). Αν ο server αργεί να απαντήσει, όλα τα υπόλοιπα αργούν. Page cache για ανώνυμους επισκέπτες, καλό hosting, CDN.
• Μην κάνετε lazy load την κύρια εικόνα. Η εικόνα που είναι το LCP πρέπει να φορτώνει αμέσως, ιδανικά με fetchpriority="high".
• Σωστό μέγεθος και format. Μια φωτογραφία 3000px για οθόνη κινητού 400px είναι σπατάλη. WebP ή AVIF με srcset.
• Πετάξτε το slider. Τα sliders στην αρχική σπάνια φέρνουν κλικ μετά την πρώτη διαφάνεια και σχεδόν πάντα επιβαρύνουν το LCP. Μία στατική εικόνα κάνει τη δουλειά καλύτερα.
• Fonts. Λιγότερες οικογένειες και βάρη, font-display: swap, και τοπικό hosting των fonts.

Διόρθωση INP

Το INP είναι η μετρική που «πονάει» περισσότερο τα WooCommerce sites με πολλά plugins, γιατί κάθε plugin προσθέτει JavaScript.

• Λιγότερα third-party scripts. Chat widgets, popups, heatmaps, πολλαπλά pixels. Κάθε ένα κοστίζει. Κρατήστε μόνο ό,τι χρησιμοποιείτε ενεργά.
• Φόρτωση scripts μόνο όπου χρειάζονται. Το script του payment gateway δεν χρειάζεται στην αρχική. Το script του slider δεν χρειάζεται στο checkout.
• Φίλτρα κατηγοριών. Φίλτρα που ξαναφορτώνουν όλη τη σελίδα με βαριά AJAX σε κάθε κλικ είναι συχνή πηγή κακού INP. Δώστε άμεση οπτική απόκριση (π.χ. loading state) και βελτιστοποιήστε τα queries.
• Επιλογή παραλλαγών. Η αλλαγή μεγέθους/χρώματος πρέπει να αλλάζει τιμή και φωτογραφία αμέσως, όχι μετά από αίτημα στον server.
• Λιγότερο DOM. Σελίδες κατηγοριών με εκατοντάδες προϊόντα και mega menus τεραστίων διαστάσεων κάνουν κάθε αλληλεπίδραση πιο αργή.

Διόρθωση CLS

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

• Διαστάσεις σε όλες τις εικόνες (width και height ή aspect-ratio), ώστε ο browser να κρατάει χώρο.
• Χώρος για banners και ειδοποιήσεις. Το banner «Δωρεάν αποστολή άνω των 40€» που εμφανίζεται μετά τη φόρτωση σπρώχνει όλη τη σελίδα κάτω.
• Cookie banner ως overlay στο κάτω μέρος, όχι ως μπάρα που σπρώχνει το περιεχόμενο.
• Fonts με παρόμοιες μετρικές με το fallback, για να μην «πηδάει» το κείμενο.
• Κριτικές και widgets τρίτων με προκαθορισμένο ύψος.

Ένα πλάνο δύο εβδομάδων

1. Ημέρα 1–2: Search Console → Core Web Vitals. Ποια templates αποτυγχάνουν σε κινητό;
2. Ημέρα 3–5: TTFB και caching. Αν ο server είναι αργός, ξεκινήστε από εκεί.
3. Ημέρα 6–8: Εικόνες: formats, μεγέθη, lazy loading σωστά, κύρια εικόνα με προτεραιότητα.
4. Ημέρα 9–11: Scripts: απογραφή, αφαίρεση, φόρτωση υπό όρους.
5. Ημέρα 12–14: CLS: διαστάσεις, banners, fonts.

Τα field data στο Search Console χρειάζονται περίπου 28 ημέρες για να αποτυπώσουν πλήρως τις αλλαγές, οπότε μην απογοητεύεστε αν δεν δείτε αμέσως πράσινο.

Μην ξεχνάτε το admin και το checkout

Τα Core Web Vitals μετρούν δημόσιες σελίδες, αλλά δύο σημεία που δεν φαίνονται πάντα στις αναφορές επηρεάζουν άμεσα τις πωλήσεις. Το checkout, που συχνά δεν έχει αρκετή κίνηση για field data, αξίζει χειροκίνητο έλεγχο σε ένα μέσο κινητό με αργή σύνδεση: πόσο αργεί η αλλαγή τρόπου αποστολής, πόσο το άνοιγμα της φόρμας κάρτας; Και το admin: αν η καταχώριση μιας παραγγελίας ή ενός προϊόντος παίρνει πολλά δευτερόλεπτα, είναι σχεδόν σίγουρα σημάδι ότι και ο server δυσκολεύεται, κάτι που κάποια στιγμή θα το νιώσουν και οι πελάτες σας.

Συμπέρασμα

Τα Core Web Vitals δεν είναι αυτοσκοπός· είναι ένας μετρήσιμος τρόπος να ελέγχετε ότι το κατάστημά σας είναι ευχάριστο στη χρήση. Και ένα ευχάριστο κατάστημα πουλάει περισσότερο.

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