8 στα 8 sites μας σκοράρουν πάνω από 93/100 στο Lighthouse — και κανένα δεν είναι WordPress.
Η ταχύτητα δεν είναι ζήτημα τεχνικής περηφάνιας
Ένα κοινό λάθος: η ταχύτητα φορτώσεως αντιμετωπίζεται σαν αισθητικό ζήτημα, κάτι που νοιάζει μόνο τους developers. Δεν είναι. Κάθε δευτερόλεπτο καθυστέρησης στη φόρτωση μιας σελίδας συνδέεται με μετρήσιμη πτώση στις μετατροπές — η Google το τεκμηριώνει εδώ και χρόνια σε δικές της μελέτες mobile retail. Η ταχύτητα δεν είναι engineering flex. Είναι το πρώτο σημείο επαφής του πελάτη με το πόσο σοβαρά παίρνετε την εμπειρία του, πριν καν διαβάσει μία λέξη.
Πώς δουλεύει το WordPress κάτω από την κουκούλα
Κάθε φορά που κάποιος ζητάει μια σελίδα WordPress, ο server πρέπει να τρέξει PHP κώδικα, να εκτελέσει ερωτήματα σε μια βάση δεδομένων MySQL, να ενεργοποιήσει σειριακά όλα τα εγκατεστημένα plugins, να συναρμολογήσει το theme, και μόνο τότε να επιστρέψει HTML. Αυτό είναι δυναμική απόδοση (dynamic rendering) — η σελίδα «χτίζεται» ξανά, τουλάχιστον εν μέρει, σε κάθε request, εκτός αν παρεμβληθεί κάποιο caching layer. Το caching δεν αλλάζει την αρχιτεκτονική· απλώς σερβίρει ένα «στιγμιότυπο» από πριν, με τον κίνδυνο να δείχνει μπαγιάτικο περιεχόμενο αν κάτι άλλαξε.
Πώς δουλεύει το Next.js
Το Next.js προσφέρει κάτι που το WordPress δεν μπορεί να προσφέρει native: επιλογή στρατηγικής rendering ανά σελίδα. Στατικές σελίδες (π.χ. μια σελίδα υπηρεσίας που σπάνια αλλάζει) μπορούν να παραχθούν μία φορά στο build και να σερβίρονται από CDN σε μιλισεκόντ, χωρίς καν να αγγίξουν server. Δυναμικές σελίδες (π.χ. αποτελέσματα αναζήτησης ενός e-shop) μπορούν να αποδοθούν με server components, όπου μόνο τα απολύτως απαραίτητα δεδομένα ταξιδεύουν στον browser — όχι ολόκληρο το JavaScript runtime μιας εφαρμογής. Αυτή η ευελιξία είναι δομικά αδύνατη σε ένα σύστημα σαν το WordPress, που χτίστηκε γύρω από μία και μοναδική στρατηγική: PHP + MySQL, σε κάθε request, χωρίς εναλλακτική.
Head-to-head: τι μετράει το Lighthouse και γιατί
Το Lighthouse βαθμολογεί πέντε βασικές μετρικές, τρεις από τις οποίες συνθέτουν τα Core Web Vitals: το LCP (πόσο γρήγορα εμφανίζεται το κύριο περιεχόμενο), το CLS (πόσο σταθερό είναι το layout όσο φορτώνει), και έμμεσα το INP μέσω του Total Blocking Time. Κάθε μία από αυτές τις μετρικές ευνοεί δομικά αρχιτεκτονικές που ελαχιστοποιούν το JavaScript στο critical path και μεγιστοποιούν το ποσοστό περιεχομένου που είναι έτοιμο πριν καν το ζητήσει ο browser — ακριβώς το αντίθετο από το πώς λειτουργεί ένα βαρύ WordPress site με είκοσι ενεργά plugins.
Τα πραγματικά μας νούμερα
Χωρίς θεωρία τώρα. Αυτά είναι τα πραγματικά Lighthouse Performance scores σε desktop, από οκτώ live production sites που τρέχουν σήμερα σε πραγματική κίνηση:
| Project | Κλάδος | Performance (Desktop) | |---|---|---| | Kismet Hotel | Φιλοξενία | 99/100 | | Armakatone | Κατασκευές | 99/100 | | Diamond Glass | Αρχιτεκτονικές κατασκευές | 99/100 | | CrystaLaw | Νομικές υπηρεσίες | 99/100 | | IntelliAgTech | Συμβουλευτική | 98/100 | | Παπουτσάκης Transport | Logistics | 96/100 | | Eleanna Pitsikaki | Καλλιτέχνης, 8 γλώσσες | 96/100 | | Γ. Πασσάκης | Πλαστική χειρουργική | 93/100 |
Το εύρος είναι 93-99/100, σε οκτώ εντελώς διαφορετικούς κλάδους, με εντελώς διαφορετικές απαιτήσεις περιεχομένου — από βαρύ οπτικό υλικό (Γ. Πασσάκης) μέχρι διαδραστική χαρτογράφηση (Παπουτσάκης) και πλήρη 8-γλωσση τοπικοποίηση (Eleanna Pitsikaki). Κανένα από αυτά δεν τρέχει σε WordPress. Δεν είναι επιλεκτικό δείγμα — είναι όλο το ενεργό portfolio μας.
Ένα τυπικό WordPress site με δημοφιλές theme, page builder (Elementor/Divi) και τα συνήθη plugins ασφάλειας, SEO και forms σπάνια ξεπερνάει το 60-70 σε mobile performance, ακόμα και με ενεργό caching plugin — γιατί το caching κρύβει το πρόβλημα της δυναμικής απόδοσης, δεν το εξαφανίζει.
Γιατί το WordPress «κολλάει» ακόμα και με καλό caching plugin
Το caching plugin μπορεί να επιταχύνει το «πρώτο byte» σερβίροντας ένα αποθηκευμένο HTML αντί να τρέξει ξανά όλη την αλυσίδα PHP→MySQL. Αλλά δεν κάνει τίποτα για το JavaScript που ήδη φορτώνει το theme και τα plugins στον browser του χρήστη. Ένα σύγχρονο WordPress theme με page builder συνήθως φορτώνει πολλαπλάσιο JavaScript από ένα καλά γραμμένο Next.js site, ανεξάρτητα από το πόσο καλό caching έχετε στον server. Το caching λύνει το πρόβλημα του server. Δεν λύνει το πρόβλημα του browser — και το INP μετράει ακριβώς το δεύτερο.
Το πραγματικό κόστος της αργής σελίδας
Η αργή ταχύτητα δεν είναι απλώς ενοχλητική. Μεταφράζεται άμεσα σε bounce rate (ο επισκέπτης φεύγει πριν καν δει το περιεχόμενο) και έμμεσα σε χαμηλότερη κατάταξη, γιατί η Google χρησιμοποιεί συμπεριφορικά σήματα engagement ως μέρος της αξιολόγησης ποιότητας μιας σελίδας. Ένα e-shop που χάνει επισκέπτες στα πρώτα 3 δευτερόλεπτα φόρτωσης δεν χάνει απλώς μια κακή στατιστική — χάνει πωλήσεις που ποτέ δεν θα καταγραφούν πουθενά, γιατί ο χρήστης έφυγε πριν προλάβει να γίνει lead.
Πότε το Next.js δεν αξίζει τον κόπο
Δεν θα ήταν έντιμο να πούμε ότι το Next.js είναι πάντα η σωστή απάντηση. Αν έχετε ένα απλό blog προσωπικού χαρακτήρα, χωρίς εμπορικό στόχο, χωρίς ανάγκη για ταχύτητα-ως-ανταγωνιστικό-πλεονέκτημα, το κόστος μετάβασης πιθανόν δεν δικαιολογείται. Το Next.js αξίζει όταν η ταχύτητα μεταφράζεται σε χρήμα: e-shops, sites κρατήσεων, B2B πύλες lead generation, οτιδήποτε όπου κάθε δευτερόλεπτο καθυστέρησης έχει μετρήσιμο κόστος ευκαιρίας.
Τι σημαίνει «93-99» σε πραγματικά δευτερόλεπτα φόρτωσης
Ένα νούμερο σαν το 96/100 ακούγεται αφηρημένο μέχρι να το μεταφράσετε σε αυτό που πραγματικά βιώνει ο επισκέπτης. Πίσω από ένα score στα 95+ κρύβεται συνήθως LCP κάτω από 1.5 δευτερόλεπτα σε desktop και κάτω από 2.5 σε mobile — δηλαδή το κύριο περιεχόμενο της σελίδας (η φωτογραφία hero, ο τίτλος, το πρώτο call-to-action) είναι πλήρως ορατό πριν προλάβει ο χρήστης να καταλάβει ότι περίμενε. Ένα τυπικό score στα 60-70, που βλέπουμε συχνά σε production WordPress sites με page builder, αντιστοιχεί σε LCP γύρω στα 3.5-4.5 δευτερόλεπτα σε mobile. Η διαφορά ανάμεσα σε «1.5 δευτερόλεπτα» και «4 δευτερόλεπτα» δεν είναι αισθητική λεπτομέρεια. Είναι η διαφορά ανάμεσα σε έναν χρήστη που περιμένει και έναν χρήστη που έχει ήδη πατήσει back. Η Google το έχει τεκμηριώσει επανειλημμένα: κάθε επιπλέον δευτερόλεπτο φόρτωσης πάνω από τα πρώτα τρία αυξάνει σημαντικά την πιθανότητα εγκατάλειψης, ειδικά σε mobile δικτύωση με μεταβλητή ταχύτητα.
Το CLS λέει μια εξίσου σημαντική ιστορία. Ένα site με CLS κοντά στο μηδέν σημαίνει ότι τίποτα δεν «πηδάει» στην οθόνη όσο φορτώνει — το κουμπί που θέλατε να πατήσετε δεν μετακινείται μια στιγμή πριν το ακουμπήσετε επειδή μόλις φόρτωσε μια διαφήμιση ή μια γραμματοσειρά από πάνω του. Αυτό το φαινόμενο είναι σχεδόν πάντα αποτέλεσμα ασύγχρονης φόρτωσης πόρων χωρίς δεσμευμένο χώρο — κάτι που συμβαίνει συχνότερα σε WordPress themes όπου κάθε plugin φορτώνει το δικό του CSS και JavaScript ανεξάρτητα, χωρίς κεντρικό συντονισμό.
Το βάρος του JavaScript: γιατί το πρόβλημα δεν είναι μόνο ο server
Το caching plugin λύνει το πρόβλημα του πρώτου byte. Δεν λύνει το πρόβλημα του browser, και εκεί κρύβεται το μεγαλύτερο κομμάτι της διαφοράς ταχύτητας. Ένα σύγχρονο WordPress theme με page builder (Elementor, Divi, Beaver Builder) συνήθως συνοδεύεται από τη δική του βιβλιοθήκη JavaScript, το δικό της CSS framework, και μια σειρά από plugins ασφαλείας, SEO, φορμών επικοινωνίας και analytics — καθένα από τα οποία προσθέτει το δικό του αρχείο στη σελίδα. Το άθροισμα αυτών των αρχείων είναι αυτό που ο browser του χρήστη πρέπει να κατεβάσει, να αναλύσει (parse) και να εκτελέσει πριν η σελίδα γίνει πραγματικά διαδραστική — αυτό είναι το Total Blocking Time που τροφοδοτεί το INP score.
Ένα καλά γραμμένο Next.js site λειτουργεί αντίστροφα: κάθε component φορτώνει μόνο το JavaScript που πραγματικά χρειάζεται για τη δική του λειτουργία, και τα server components δεν στέλνουν καθόλου JavaScript στον client για ό,τι δεν χρειάζεται διαδραστικότητα. Ένα στατικό block κειμένου, μια εικόνα, μια λίστα υπηρεσιών — όλα αυτά μπορούν να σερβιριστούν ως καθαρό HTML, χωρίς να «κοστίζουν» τίποτα σε JavaScript. Η αρχιτεκτονική επιλογή, όχι κάποιο μαγικό τρικ βελτιστοποίησης, είναι αυτή που παράγει τη διαφορά.
Τα τρία λάθη που κάνουν οι επιχειρήσεις όταν συγκρίνουν τα δύο συστήματα
Το πρώτο λάθος: δοκιμάζουν ένα φρέσκο, άδειο WordPress install χωρίς περιεχόμενο και plugins, και το συγκρίνουν με ένα production site με πραγματικά δεδομένα. Ένα άδειο site είναι πάντα γρήγορο — το ερώτημα είναι τι συμβαίνει μετά από 12 μήνες λειτουργίας, όταν έχουν προστεθεί 15 plugins, τρία themes updates και ένα e-commerce module.
Το δεύτερο λάθος: κοιτάζουν μόνο το desktop score και αγνοούν το mobile. Η Google ευρετηριάζει πλέον με βάση την mobile-first έκδοση του site σας — αν το desktop score είναι 95 και το mobile 55, αυτό το δεύτερο νούμερο είναι αυτό που μετράει περισσότερο για την κατάταξή σας, όπως εξηγούμε αναλυτικά στο άρθρο για το mobile first indexing.
Το τρίτο λάθος: μετράνε την ταχύτητα μία φορά, σε συνθήκες χαμηλής κίνησης, και θεωρούν το αποτέλεσμα οριστικό. Ένα site που φαίνεται γρήγορο με 10 ταυτόχρονους επισκέπτες μπορεί να καταρρεύσει σε TTFB πάνω από 2 δευτερόλεπτα όταν φτάσει σε 500 ταυτόχρονους, ακριβώς επειδή η δυναμική απόδοση PHP+MySQL δεν κλιμακώνεται γραμμικά χωρίς σοβαρή επένδυση σε server infrastructure.
Ενστάσεις που ακούμε συχνά
«Το WordPress μπορεί να είναι γρήγορο αν πληρώσεις για καλό hosting.» Εν μέρει αληθές, ολικά παραπλανητικό. Καλό managed hosting (WP Engine, Kinsta) βελτιώνει σημαντικά το TTFB μειώνοντας τον χρόνο απόκρισης server — αλλά δεν αγγίζει καθόλου το πρόβλημα του JavaScript bundle που περιγράψαμε παραπάνω. Πληρώνετε περισσότερο τον μήνα για να λύσετε το μισό πρόβλημα.
«Το Next.js κοστίζει περισσότερο να φτιαχτεί, άρα δεν αξίζει.» Το αρχικό κόστος ανάπτυξης μπορεί όντως να είναι υψηλότερο σε ώρες engineering. Αλλά το κόστος καθ' όλη τη διάρκεια ζωής του site είναι σχεδόν πάντα χαμηλότερο — χωρίς μηνιαία άδεια premium theme, χωρίς ανανεώσεις 15 διαφορετικών plugin licenses, χωρίς τον κίνδυνο ένα update να σπάσει ολόκληρο το site το πρωί πριν από μια σημαντική καμπάνια.
Headless WordPress: η εξαίρεση που επιβεβαιώνει τον κανόνα
Υπάρχει ένα σενάριο όπου το WordPress μπορεί να πλησιάσει σε ταχύτητα ένα Next.js site: όταν χρησιμοποιείται headless, δηλαδή μόνο ως backend/CMS API, με ένα εντελώς ξεχωριστό front-end χτισμένο σε React ή Next.js που καταναλώνει τα δεδομένα μέσω REST ή GraphQL. Σε αυτή την περίπτωση, ο χρήστης δεν βλέπει ποτέ το «κλασικό» WordPress rendering pipeline — βλέπει το ίδιο γρήγορο front-end που θα είχε ένα καθαρό Next.js project. Το κόστος: χάνετε την ευκολία διαχείρισης ενός ενοποιημένου συστήματος, και χρειάζεστε δύο ξεχωριστές ομάδες συντήρησης (μία για το CMS, μία για το front-end) αντί για μία. Για τις περισσότερες μικρές και μεσαίες επιχειρήσεις, αυτή η πολυπλοκότητα δεν δικαιολογείται όταν υπάρχει ήδη μια αρχιτεκτονική που κάνει τη δουλειά ενοποιημένα, γρήγορα, από την πρώτη μέρα.
Το κρυφό κόστος hosting που κανείς δεν βάζει στη σύγκριση
Όταν συγκρίνετε προσφορές, το κόστος hosting σπάνια εμφανίζεται στην ίδια γραμμή με το κόστος ανάπτυξης — αλλά είναι μέρος του ίδιου υπολογισμού. Ένα WordPress site που θέλει πραγματικά καλή απόδοση χρειάζεται managed hosting premium επιπέδου, συνήθως 25-60€ τον μήνα, συν το κόστος άδειας του page builder (30-90€ τον χρόνο), συν άδειες για τα σοβαρότερα plugins ασφαλείας και cache (ακόμα 100-200€ τον χρόνο συνολικά). Ένα Next.js site σε σύγχρονο edge hosting (Vercel, Netlify) συχνά τρέχει άνετα στο δωρεάν ή στο πρώτο πληρωμένο επίπεδο για τυπική κίνηση μικρής-μεσαίας επιχείρησης, ακριβώς επειδή η στατική απόδοση (static generation) δεν καταναλώνει compute σε κάθε request. Το άθροισμα σε βάθος τριετίας δεν είναι αμελητέο — και δεν περιλαμβάνει καν τον χρόνο που θα χαθεί σε ένα πρωινό που ένα update θα σπάσει το site λίγο πριν μια σημαντική καμπάνια διαφημίσεων.
Ένα σενάριο μετάβασης: τι αλλάζει τους πρώτους 6 μήνες
Ας υποθέσουμε μια επιχείρηση με υπάρχον WordPress site που σκοράρει 58/100 σε mobile Lighthouse, μεταφέρεται σε Next.js, και καταλήγει κοντά στο εύρος 93-99/100 που βλέπουμε στο δικό μας portfolio. Τι αλλάζει πρακτικά; Πρώτον, το bounce rate σε mobile πέφτει αισθητά μέσα στις πρώτες εβδομάδες — λιγότεροι επισκέπτες φεύγουν πριν δουν περιεχόμενο. Δεύτερον, η Google Search Console αρχίζει να δείχνει βελτίωση στο ποσοστό σελίδων που περνούν τα Core Web Vitals assessment, κάτι που η ίδια η Google αναφέρει ρητά ως ένα από τα σήματα κατάταξης. Τρίτον — και αυτό είναι το κομμάτι που παραβλέπεται συχνότερα — μια τεχνική μετάβαση αρχιτεκτονικής χρειάζεται προσεκτικό χειρισμό redirects και δομής URL, αλλιώς κινδυνεύετε να χάσετε την υπάρχουσα κατάταξη ακριβώς την ώρα που προσπαθείτε να τη βελτιώσετε. Το πλήρες πλάνο για το πώς αποφεύγεται αυτό το ρίσκο περιγράφεται στον οδηγό migration website seo.
Το JavaScript SEO ρίσκο που εμφανίζεται μόνο μετά τη μετάβαση
Υπάρχει μια παγίδα που πολλές ομάδες ανακαλύπτουν μόνο αφού έχουν ήδη μεταφερθεί: ένα React/Next.js site που δεν έχει ρυθμιστεί σωστά για server-side rendering ή static generation μπορεί να αποδώσει άδειο HTML στους crawlers, ενώ ο πραγματικός χρήστης βλέπει πλήρες περιεχόμενο μέσω client-side JavaScript. Το αποτέλεσμα είναι ένα εξαιρετικά γρήγορο site που η Google αδυνατεί να διαβάσει σωστά — δηλαδή ταχύτητα χωρίς κατάταξη, το ακριβώς αντίθετο πρόβλημα από ένα αργό WordPress site. Αυτό δεν είναι επιχείρημα εναντίον του Next.js· είναι επιχείρημα υπέρ του να γίνεται η μετάβαση από ανθρώπους που καταλαβαίνουν τη διαφορά ανάμεσα σε rendering strategies. Αναλύουμε ακριβώς αυτές τις παγίδες στο άρθρο javascript seo προβλήματα.
Τι σημαίνει αυτό στην πράξη
Αν αξιολογείτε ένα νέο website project, ζητήστε να δείτε πραγματικά Lighthouse screenshots από τα τελευταία 3-5 ολοκληρωμένα projects της εταιρείας που εξετάζετε — όχι δηλώσεις, screenshots. Αναλύουμε αναλυτικά και τους λόγους αρχιτεκτονικής επιλογής στο άρθρο γιατί όχι wordpress, και το πλήρες τεχνικό stack που χρησιμοποιούμε περιγράφεται στο σχετικό FAQ για το tech stack μας.
Lab data vs field data: γιατί το δικό σας Lighthouse score μπορεί να «λέει ψέματα»
Ένα κοινό, καλόπιστο λάθος: κάποιος ανοίγει PageSpeed Insights, βλέπει 96/100, και θεωρεί το ζήτημα λυμένο οριστικά. Αυτό το νούμερο είναι lab data — μια μέτρηση σε ελεγχόμενες συνθήκες, σε συγκεκριμένη συσκευή προσομοίωσης, με σταθερή ταχύτητα δικτύου. Είναι χρήσιμο για διάγνωση, αλλά δεν είναι αυτό που βλέπει η Google όταν αποφασίζει κατάταξη με βάση Core Web Vitals. Εκεί χρησιμοποιεί field data — πραγματικές μετρήσεις από πραγματικούς χρήστες, μέσω του Chrome User Experience Report (CrUX), συγκεντρωμένες τις τελευταίες 28 ημέρες.
Η απόκλιση ανάμεσα στα δύο μπορεί να είναι μεγάλη, και προς τις δύο κατευθύνσεις. Ένα site μπορεί να σκοράρει 95 σε lab test με γρήγορο wifi γραφείου, αλλά να έχει field data που δείχνει «Needs Improvement» επειδή το πραγματικό του κοινό συνδέεται κυρίως από 4G σε επαρχιακή περιοχή, ή από παλαιότερα κινητά με λιγότερη επεξεργαστική ισχύ. Το αντίστροφο συμβαίνει σπανιότερα αλλά συμβαίνει: ένα site με μέτριο lab score μπορεί να έχει καλά field data αν το πραγματικό του κοινό είναι σχεδόν αποκλειστικά desktop με γρήγορη σύνδεση.
Το πρακτικό συμπέρασμα: ελέγξτε πάντα και τα δύο, όχι μόνο το ένα. Το Search Console έχει ειδική αναφορά Core Web Vitals βασισμένη σε field data, ομαδοποιημένη ανά τύπο σελίδας — αυτή είναι η αναφορά που αντικατοπτρίζει τι πραγματικά βλέπει η Google, όχι το lab score του PageSpeed Insights. Ένα site που σκοράρει σταθερά 93-99 σε lab test αλλά ποτέ δεν έχει ελεγχθεί σε field data τρέχει στα τυφλά — το νούμερο που δείχνει στον πελάτη μπορεί να μην είναι το νούμερο που μετράει τελικά την κατάταξή του.
Υπάρχει και μια ειδική περίπτωση: sites με πολύ χαμηλή επισκεψιμότητα απλά δεν έχουν αρκετά δεδομένα field στο CrUX για να εμφανιστεί αναφορά — το Search Console δείχνει κενό αντί για σκορ. Σε αυτή την περίπτωση, το lab data παραμένει ο μόνος διαθέσιμος δείκτης, αλλά αξίζει να θυμάστε ότι είναι η αισιόδοξη εκτίμηση της πραγματικής εικόνας, όχι υποκατάστατο της.
Ένα αριθμητικό παράδειγμα: το κόστος μιας ανεπεξέργαστης εικόνας σε KB
Ας δούμε τη διαφορά αρχιτεκτονικής σε ένα συγκεκριμένο, μετρήσιμο σενάριο αντί σε αφηρημένη περιγραφή. Ένας χρήστης ανεβάζει μια φωτογραφία hero 4000×3000 pixels, απευθείας από την κάμερα, χωρίς επεξεργασία — τυπικό μέγεθος αρχείου γύρω στα 3-5MB σε JPEG.
Σε ένα τυπικό WordPress site χωρίς πρόσθετη ρύθμιση, αυτή η εικόνα συχνά ανεβαίνει ως έχει, ή στην καλύτερη περίπτωση περνάει από ένα plugin συμπίεσης που τη μειώνει σε περίπου 800KB-1.2MB, ακόμα πολύ μεγαλύτερη απ' όσο χρειάζεται μια οθόνη κινητού. Σε ένα Next.js site με το ενσωματωμένο Image component, η ίδια φωτογραφία μετατρέπεται αυτόματα σε WebP ή AVIF, αλλάζει μέγεθος ανάλογα με την πραγματική οθόνη του επισκέπτη, και καταλήγει συνήθως στα 80-150KB για την έκδοση mobile — περίπου δέκα φορές μικρότερη από το ανεπεξέργαστο αρχείο, χωρίς ορατή απώλεια ποιότητας στην οθόνη όπου προβάλλεται.
Πολλαπλασιάστε αυτή τη διαφορά σε μια σελίδα με δέκα εικόνες — σενάριο συνηθισμένο σε site κατασκευαστικής εταιρείας ή ξενοδοχείου — και η διαφορά συνολικού βάρους σελίδας φτάνει εύκολα τα 5-8MB έναντι 1MB. Σε σύνδεση 4G με ταχύτητα γύρω στα 10Mbps, αυτό μεταφράζεται σε διαφορά αρκετών δευτερολέπτων φόρτωσης — ακριβώς το LCP που περιγράψαμε παραπάνω, μόνο που εδώ βλέπετε τον ακριβή μηχανισμό, όχι μόνο το τελικό σκορ.
Το σημείο δεν είναι ότι το WordPress δεν μπορεί ποτέ να κάνει σωστή διαχείριση εικόνων — μπορεί, με σωστά ρυθμισμένα plugins όπως το ShortPixel ή το Imagify. Το σημείο είναι ότι στο Next.js αυτή η βελτιστοποίηση είναι η προεπιλεγμένη συμπεριφορά του συστήματος, όχι πρόσθετη ρύθμιση που κάποιος πρέπει να θυμηθεί να ενεργοποιήσει και να συντηρήσει σε κάθε νέο upload. Πριν υπογράψετε με οποιαδήποτε εταιρεία, οι ερωτήσεις πριν διαλέξετε web agency περιλαμβάνουν ακριβώς αυτό το είδος τεχνικής λεπτομέρειας — ζητήστε να δείτε πώς χειρίζεται πρακτικά τις εικόνες σας, όχι μόνο τι λέει ότι κάνει.