Θα ξεκινήσω με μια εικόνα, και ταιριάζει στο θέμα. Φανταστείτε ότι ετοιμάζετε βαλίτσα για τριήμερο και βάζετε μέσα χειμωνιάτικο παλτό, δύο ζευγάρια μπότες και μια κουβέρτα. Θα τα χρειαστείτε; Μάλλον όχι. Θα τα κουβαλάτε; Οπωσδήποτε. Αυτό ακριβώς κάνουν οι περισσότερες σελίδες με τις εικόνες τους: κουβαλούν βάρος που ο επισκέπτης δεν θα δει ποτέ, και μετά απορούμε γιατί ανοίγουν αργά στο κινητό.
Ας δούμε λοιπόν πόσο είναι πραγματικά αυτό το βάρος, ποια είναι τα δύο ή τρία λάθη που το κάνουν χειρότερο, και τι πετυχαίνετε όταν κάτσετε να το φτιάξετε. Με μετρήσεις, όχι με επίθετα.
Πόσο ζυγίζουν στ’ αλήθεια
Το Web Almanac του HTTP Archive σαρώνει εκατομμύρια σελίδες και δημοσιεύει τα ευρήματα. Στην έκδοση του 2025, η διάμεση αρχική σελίδα ζυγίζει περίπου 2,56 MB σε κινητό και 2,86 MB σε υπολογιστή. Από αυτά, οι εικόνες είναι περίπου 911 KB στο κινητό και 1.058 KB στον υπολογιστή.
Κάντε τη διαίρεση: μιλάμε για το ένα τρίτο ως το μισό της σελίδας, σε εικόνες. Και μιλάμε για τη διάμεση σελίδα, δηλαδή τις μισές είναι χειρότερα.
Υπάρχει και ένα εύρημα που το βρίσκω από τα πιο χρήσιμα: στις εσωτερικές σελίδες τα μεγέθη πέφτουν κατακόρυφα, σε 354 KB στο κινητό και 442 KB στον υπολογιστή. Δηλαδή το βάρος συγκεντρώνεται στην αρχική, εκεί ακριβώς που κρίνεται η πρώτη εντύπωση. Σωστά το σκεφτήκατε: εκεί αξίζει να δουλέψετε πρώτα.
Οι μορφές, και μια αλήθεια που θα σας ξενίσει
Όλοι μιλάνε για WebP και AVIF. Ας δούμε πόσοι τα χρησιμοποιούν όντως. Από τη μέτρηση του 2024, στο κινητό:
| Μορφή | Μερίδιο |
|---|---|
| JPEG | 32,4% |
| PNG | 28,4% |
| GIF | 16,8% |
| WebP | 12% |
| SVG | 6,4% |
| AVIF | 1,0% |
Το AVIF είναι στο 1%. Ένα τοις εκατό, μετά από χρόνια συζητήσεων. Και το GIF, που είναι τεχνολογία του 1987, εξακολουθεί να είναι σχεδόν δεκαεπτά φορές πιο διαδεδομένο.
Πριν όμως τρέξετε να αλλάξετε τα πάντα, μια διόρθωση που πρέπει να ειπωθεί. Κυκλοφορεί ευρέως ένα νούμερο, ότι το AVIF εξοικονομεί «60% έναντι JPEG», αποδιδόμενο στη Google. Δεν είναι δήλωση της Google. Αυτό που γράφει η ίδια η ομάδα του Chrome στο web.dev είναι πιο συγκρατημένο: ότι οι δοκιμές έδειξαν εξοικονόμηση πάνω από 50% έναντι του JPEG σε ορισμένες περιπτώσεις. Το «σε ορισμένες περιπτώσεις» δεν είναι διακοσμητικό.
Η πρακτική σύσταση παραμένει απλή: WebP για όλα, AVIF όπου έχετε χρόνο να το δοκιμάσετε, και πάντα με εφεδρεία. Το JPEG δεν πέθανε, απλώς έπεσε από το 40% το 2022 στο 32% το 2024.
Το λάθος που κοστίζει περισσότερο από κάθε συμπίεση
Και τώρα το πιο σημαντικό του άρθρου, που το κάνουν και πολύ καλοί προγραμματιστές.
Το loading="lazy" είναι εξαιρετικό: λέει στον browser να μην κατεβάσει μια εικόνα μέχρι να πλησιάσει ο χρήστης. Χρησιμοποιείται πλέον, κατά το ίδιο Web Almanac, στο ένα τρίτο των ιστότοπων. Ωραία νέα.
Το κακό νέο είναι το επόμενο νούμερο: το 9,5% των εικόνων που ευθύνονται για το LCP έχουν native lazy loading. Μία στις δέκα. Δηλαδή η πιο σημαντική εικόνα της σελίδας, αυτή που καθορίζει πότε ο επισκέπτης θεωρεί ότι «φόρτωσε», έχει ρητά δηλωθεί ως μη επείγουσα.
Είναι σαν να βάζετε τον σερβιτόρο να φέρει πρώτα τις οδοντογλυφίδες και μετά το φαγητό. Και το χειρότερο: η σελίδα βγάζει καλύτερο σκορ σε κάποια εργαλεία, επειδή κατέβασε λιγότερα bytes συνολικά, ενώ ο πραγματικός χρήστης περιμένει περισσότερο.
Το web.dev το γράφει ρητά: μην κάνετε lazy load εικόνες που πιθανότατα θα βρίσκονται στο ορατό μέρος όταν φορτώνει η σελίδα, ιδίως τις εικόνες LCP. Και συμπληρώνει: χρησιμοποιήστε το loading=lazy μόνο για εικόνες εκτός του αρχικού ορατού πεδίου.
Αν κρατήσετε ένα πράγμα από όλο το άρθρο, κρατήστε αυτό.
Το αντίστροφο: πείτε στον browser τι είναι επείγον
Το loading="lazy" λέει «μη βιάζεσαι». Υπάρχει και το αντίθετο, και το ξέρουν λιγότεροι: το fetchpriority="high".
Χωρίς αυτό, οι εικόνες ξεκινούν με χαμηλή προτεραιότητα και ανεβαίνουν μόνο αφού ο browser καταλάβει ότι είναι ορατές. Με αυτό, ξεκινούν αμέσως ψηλά. Η ομάδα του Chrome το διατυπώνει απλά, ότι έτσι το LCP συμβαίνει νωρίτερα, και δίνει παράδειγμα από τις Πτήσεις Google: LCP από 2,6 σε 1,9 δευτερόλεπτα, με μία δήλωση.
Ο κανόνας λοιπόν είναι δύο γραμμές. Η κύρια εικόνα παίρνει fetchpriority="high" και δεν παίρνει ποτέ loading="lazy". Όλες οι υπόλοιπες παίρνουν loading="lazy" και τίποτε άλλο.
Οι δύο αριθμοί που λείπουν και κουνάνε τη σελίδα
Ξέρετε τη στιγμή που διαβάζετε κάτι στο κινητό, φορτώνει μια εικόνα από πάνω, και το κείμενο πηδάει προς τα κάτω; Την ξέρετε. Την έχετε βρίσει.
Η αιτία είναι σχεδόν πάντα η ίδια: λείπουν το width και το height από την εικόνα. Το MDN το εξηγεί καθαρά: με αυτά τα δύο, ο browser υπολογίζει τον λόγο διαστάσεων πριν κατέβει η εικόνα και δεσμεύει τον χώρο, μειώνοντας ή και εξαλείφοντας τη μετατόπιση.
Το ίδιο MDN προσθέτει κάτι που δεν το σκέφτονται πολλοί: είναι ακόμη πιο κρίσιμα στις lazy-loaded εικόνες, γιατί μια εικόνα που δεν έχει φορτώσει έχει πλάτος και ύψος μηδέν. Δηλαδή όσο πιο σωστά κάνετε το ένα, τόσο πιο απαραίτητο γίνεται το άλλο.
Το srcset, το sizes, και το λάθος που κάνουν οι μισοί
Οι responsive εικόνες υπάρχουν για να μη στέλνετε φωτογραφία 2000 pixel σε οθόνη 400 pixel. Το srcset δηλώνει ποιες εκδοχές υπάρχουν, και το sizes δηλώνει πόσο χώρο πιάνει η εικόνα στη διάταξή σας, ώστε ο browser να διαλέξει.
Χρησιμοποιούνται λιγότερο απ’ όσο νομίζετε: srcset στο 42% των σελίδων σε κινητό, <picture> μόλις στο 9,3%.
Και εδώ είναι το ενδιαφέρον. Το πιο συχνό λάθος δεν είναι να μη βάλετε sizes, είναι να το βάλετε λάθος. Η μέτρηση του 2024 βρήκε ότι η διάμεση τιμή του sizes είναι 16% μεγαλύτερη από την πραγματική σε κινητό και 43% μεγαλύτερη σε υπολογιστή. Δηλαδή δηλώνουμε στον browser ότι η θέση είναι μεγαλύτερη απ’ όσο είναι, εκείνος υπακούει και κατεβάζει μεγαλύτερο αρχείο, και έτσι στήνουμε ολόκληρο μηχανισμό εξοικονόμησης για να τον ακυρώσουμε με έναν λάθος αριθμό.
Το <picture> είναι άλλη ιστορία και δεν είναι για την ίδια δουλειά: χρησιμεύει όταν θέλετε διαφορετικά κάδρα ανά οθόνη, όχι απλώς άλλη ανάλυση της ίδιας.
Τα δικά μας νούμερα, γιατί τα ξένα τα είπαμε
Όλα τα παραπάνω είναι ξένες μετρήσεις. Ας βάλω και δικές μας, από έργα που τρέξαμε και μετρήσαμε με το MS-Tools.
Στο osyllektis.gr, ένα e-shop σε WordPress, ο χρόνος φόρτωσης έπεσε από 19 δευτερόλεπτα σε 4,4. Στο mswriter.eu το LCP πήγε από 10,4 δευτερόλεπτα σε 2,9. Στο yachtsgreece.com, όπου το πρόβλημα ήταν και όγκος αρχείων, κατεβήκαμε από 35 GB σε 7.
Δεν οφείλονται όλα στις εικόνες, θα ήταν ανέντιμο να το πω. Οφείλονται όμως σε μεγάλο βαθμό, γιατί όταν οι εικόνες είναι το ένα τρίτο του βάρους, δεν υπάρχει σοβαρή βελτίωση ταχύτητας που να τις προσπερνά.
Τι δεν θα σας πω
Θα περιμένατε εδώ ένα νούμερο του τύπου «κάθε δευτερόλεπτο κοστίζει τόσο τοις εκατό πωλήσεις». Δεν θα το γράψω, γιατί όταν πήγα να το επαληθεύσω δεν βρήκα ανεξάρτητη μελέτη πίσω του.
Αυτό που υπάρχει είναι μελέτες περίπτωσης που δημοσιεύει το ίδιο το web.dev, και είναι αυτοαναφερόμενες: η Vodafone Italy αναφέρει ότι βελτίωση 31% στο LCP συνοδεύτηκε από 8% περισσότερες πωλήσεις. Είναι πραγματικό στοιχείο, από δοκιμή A/B, αλλά μίας εταιρείας σε μία σελίδα. Δεν είναι κανόνας και δεν σας το υπόσχομαι.
Το σίγουρο είναι πιο ταπεινό και πιο χρήσιμο: η σελίδα εμφανίζεται νωρίτερα, δεν χοροπηδά, και το κινητό δεν καίει δεδομένα. Αν αυτό φέρνει πωλήσεις, το μετράμε στη δική σας περίπτωση αντί να το δανειστούμε από ξένο γράφημα.
Και μια συντόμευση, για όποιον δεν θέλει να ασχοληθεί
Αν όλα αυτά σας φάνηκαν πολλά, υπάρχει και ο δρόμος της αυτοματοποίησης. Το ίδιο το web.dev γράφει ότι η μεταφορά σε ένα image CDN μπορεί να δώσει εξοικονόμηση 40% έως 80% στο μέγεθος των αρχείων, και ότι στις περισσότερες περιπτώσεις τα βελτιστοποιεί καλύτερα από ένα script που τρέχει κατά το χτίσιμο.
Δεν είναι πανάκεια και έχει κόστος. Είναι όμως έντιμη επιλογή για όποιον έχει χίλιες εικόνες προϊόντων και δεν πρόκειται να τις περάσει μία μία.
Κι έτσι επιστρέφουμε στη βαλίτσα. Δεν χρειάζεται να ταξιδέψετε χωρίς ρούχα, χρειάζεται να μην κουβαλάτε το παλτό τον Αύγουστο. Αν θέλετε να δούμε τι κουβαλάει σήμερα το δικό σας site και τι από αυτό μπορεί να φύγει, με μέτρηση πριν και μετά, επικοινωνήστε μαζί μου.