Βελτιστοποίηση Εικόνων: WebP, AVIF και Lazy Loading για SEO

Σε ένα τυπικό website, οι εικόνες αντιστοιχούν στο 50-70% του συνολικού βάρους της σελίδας.

Το παράδοξο των εικόνων στο web design

Οι εικόνες πουλάνε. Ένα site χωρίς καλές φωτογραφίες μοιάζει με κατάστημα με άδεια βιτρίνα, όσο καλό κι αν είναι το εσωτερικό. Ταυτόχρονα, οι εικόνες είναι ο πρώτος λόγος που ένα site γίνεται αργό. Αυτό δημιουργεί μια ψευδή δίλημμα στο μυαλό πολλών ιδιοκτητών: "καλύτερες εικόνες = πιο αργό site, άρα πρέπει να θυσιάσω κάτι".

Το δίλημμα είναι ψευδές γιατί η αντίθεση δεν είναι ανάμεσα σε ποιότητα και ταχύτητα. Είναι ανάμεσα σε σωστή και λάθος ρύθμιση. Μια εικόνα 4MB σε JPEG και η ίδια ακριβώς εικόνα σε σωστά ρυθμισμένο AVIF, στην ίδια οπτική ποιότητα, μπορεί να ζυγίζει 400KB. Δέκα φορές μικρότερη, εικονικά αδιάκριτη σε ποιότητα. Το πρόβλημα δεν ήταν ποτέ "καλές εικόνες ή γρήγορο site". Ήταν "ξέρετε πώς λειτουργεί η συμπίεση εικόνων ή όχι".

Τρεις μορφές, τρεις γενιές τεχνολογίας

JPEG/PNG: η γενιά του 1992-1996

Το JPEG σχεδιάστηκε πριν από 30+ χρόνια για φωτογραφίες, το PNG για γραφικά με διαφάνεια. Και τα δύο δεν έχουν καμία επίγνωση σύγχρονων αλγορίθμων συμπίεσης. Παραμένουν το προεπιλεγμένο fallback γιατί κάθε browser και κάθε συσκευή τα υποστηρίζει, χωρίς εξαίρεση, εδώ και δεκαετίες.

WebP: η γενιά του 2010

Αναπτύχθηκε από τη Google, παράγει αρχεία 25-35% μικρότερα από JPEG στην ίδια ποιότητα, υποστηρίζει διαφάνεια σαν το PNG, και υποστηρίζεται πλέον από κάθε σύγχρονο browser. Είναι η ασφαλής, καθολική επιλογή.

AVIF: η γενιά του 2019-σήμερα

Βασισμένο στο AV1 video codec, το AVIF παράγει αρχεία ακόμα 20-30% μικρότερα από το WebP στην ίδια ποιότητα, δηλαδή συνολικά 40-50% μικρότερα από JPEG. Το μειονέκτημα: η κωδικοποίηση (encoding) είναι πιο αργή υπολογιστικά, κάτι που έχει σημασία μόνο κατά τη στιγμή δημιουργίας της εικόνας, όχι κατά τη στιγμή που τη βλέπει ο επισκέπτης σας.

Η σωστή στρατηγική δεν είναι "διαλέξτε μία μορφή". Είναι: προσφέρετε AVIF στους browsers που το υποστηρίζουν, WebP σε αυτούς που δεν το υποστηρίζουν αλλά υποστηρίζουν WebP, και JPEG/PNG ως τελευταίο fallback. Αυτό γίνεται αυτόματα μέσω του στοιχείου <picture> με πολλαπλά <source>, ή μέσω ενός image optimization pipeline όπως αυτό του Next.js, που κάνει ακριβώς αυτή τη διαπραγμάτευση μορφής αυτόματα ανά αίτημα, χωρίς να χρειάζεται να αποθηκεύετε χειροκίνητα τρεις εκδοχές κάθε εικόνας.

Ένα πραγματικό, ελέγξιμο παράδειγμα ρύθμισης

Δεν χρειάζεται να μας πιστέψετε στα λόγια: το δικό μας site είναι ρυθμισμένο ακριβώς έτσι, και η ρύθμιση είναι δημόσια ελέγξιμη στον κώδικά μας. Στο αρχείο ρυθμίσεων Next.js δηλώνουμε ρητά:

images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [384, 512, 640, 750, 828, 1080, 1200, 1920],
    imageSizes: [96, 128, 256, 384],
    minimumCacheTTL: 86400,
}

Αυτές οι τέσσερις γραμμές κάνουν τέσσερα πράγματα ταυτόχρονα. Πρώτο: δηλώνουν ρητή προτεραιότητα μορφών: AVIF πρώτα, WebP δεύτερο, με αυτόματο fallback σε JPEG/PNG για ό,τι δεν υποστηρίζει κανένα από τα δύο. Δεύτερο: ορίζουν οκτώ συγκεκριμένα "breakpoints" πλάτους οθόνης (384px μέχρι 1920px) για τις οποίες παράγεται ξεχωριστή, κατάλληλα μεγεθυμένη εκδοχή κάθε εικόνας. Ένα κινητό δεν κατεβάζει ποτέ την εκδοχή 1920px μιας εικόνας. Τρίτο: ορίζουν μικρότερα μεγέθη ειδικά για μικρά στοιχεία UI όπως avatars ή εικονίδια, όπου δεν έχει νόημα να παράγεται εικόνα πλάτους 1920px. Τέταρτο: καθορίζουν ελάχιστο cache TTL 24 ωρών, ώστε μια εικόνα που παράχθηκε μια φορά να μην παραχθεί ξανά σε κάθε αίτημα.

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

Responsive images: το κομμάτι που ξεχνιέται πιο συχνά

Η μετατροπή σε AVIF/WebP λύνει το πρόβλημα της μορφής. Δεν λύνει το πρόβλημα του μεγέθους. Μια εικόνα σχεδιασμένη για desktop hero section, πλάτους 1920px, δεν έχει κανένα λόγο να σερβίρεται αυτούσια σε ένα κινητό με οθόνη πλάτους 390px. Αν συμβαίνει αυτό, ο επισκέπτης κατεβάζει δεδομένα πολλαπλάσια από όσα χρειάζεται, και σε mobile δίκτυα, αυτό μεταφράζεται άμεσα σε αργότερο LCP.

Η λύση είναι το attribute srcset σε συνδυασμό με sizes, που λέει στον browser: "εδώ έχεις πέντε εκδοχές αυτής της εικόνας σε διαφορετικά πλάτη, διάλεξε μόνος σου ποια ταιριάζει στην πραγματική οθόνη και ανάλυση pixel του χρήστη". Αυτό ακριβώς κάνουν τα deviceSizes στη ρύθμιση που δείξαμε παραπάνω: παράγουν αυτόματα το σωστό σύνολο εκδοχών ώστε το srcset να έχει πάντα κατάλληλη επιλογή, χωρίς να χρειάζεται χειροκίνητη διαχείριση.

Lazy loading: πότε βοηθάει και πότε βλάπτει

Το lazy loading καθυστερεί τη φόρτωση εικόνων μέχρι να πλησιάσει ο επισκέπτης στο σημείο που θα τις δει, εξοικονομώντας bandwidth για εικόνες που ίσως ποτέ δεν δει. Είναι σχεδόν πάντα καλή ιδέα, με μία εξαίρεση που καταστρέφει περισσότερα sites απ' όσα βοηθάει.

Η εικόνα που εμφανίζεται πρώτη, πάνω-πάνω στη σελίδα, πριν από οποιοδήποτε scroll, αυτή είναι σχεδόν πάντα το στοιχείο που μετράει η Google ως Largest Contentful Paint. Αν εφαρμόσετε lazy loading και σε αυτή, ουσιαστικά λέτε στον browser να μην τη φορτώσει άμεσα, καθυστερώντας ακριβώς το metric που θέλετε να βελτιώσετε. Ο κανόνας που εφαρμόζουμε: lazy loading σε κάθε εικόνα κάτω από το fold, φόρτωση με προτεραιότητα (priority ή eager) στην πρώτη ορατή εικόνα, χωρίς εξαίρεση.

Alt text: το SEO κομμάτι που δεν αφορά μόνο προσβασιμότητα

Το alt text εξυπηρετεί δύο σκοπούς που συχνά μπερδεύονται σε έναν. Πρώτος σκοπός: προσβασιμότητα. Screen readers διαβάζουν το alt text σε χρήστες με προβλήματα όρασης, οπότε πρέπει να περιγράφει πραγματικά την εικόνα, όχι να είναι keyword stuffing. Δεύτερος σκοπός: η Google Images είναι μια ξεχωριστή πηγή οργανικής επισκεψιμότητας, και το alt text είναι το κύριο σήμα σχετικότητας που έχει ο crawler για μια εικόνα, μαζί με το όνομα του αρχείου και το context γύρω της.

Η σωστή προσέγγιση καλύπτει και τα δύο ταυτόχρονα: περιγράψτε τι δείχνει πραγματικά η εικόνα, με φυσική γλώσσα, συμπεριλαμβάνοντας το σχετικό keyword όπου ταιριάζει φυσικά, όχι "εικόνα εικόνα προϊόν αγορά online φθηνά". Ένα alt text σαν "δωμάτιο ξενοδοχείου με θέα στη θάλασσα στην Κρήτη, boutique διακόσμηση" εξυπηρετεί και τον χρήστη screen reader και τη μηχανή αναζήτησης ταυτόχρονα.

CDN και εικόνες: γιατί η γεωγραφία μετράει

Ακόμα και μια τέλεια συμπιεσμένη, σωστά μεγεθυμένη εικόνα ταξιδεύει αργά αν πρέπει να διανύσει χιλιόμετρα από έναν κεντρικό server. Ένα CDN αποθηκεύει αντίγραφα των εικόνων σας σε servers γεωγραφικά κατανεμημένους, ώστε ένας επισκέπτης στην Αθήνα να κατεβάζει την εικόνα από τον πλησιέστερο κόμβο, όχι από όπου φιλοξενείται το κύριο site σας. Εξηγούμε πλήρως πώς λειτουργεί αυτό στο άρθρο cdn caching website, αλλά για εικόνες συγκεκριμένα, η σωρευτική εξοικονόμηση χρόνου σε μια σελίδα με 15-20 εικόνες είναι από τις πιο μετρήσιμες βελτιώσεις που μπορείτε να κάνετε χωρίς να αγγίξετε ούτε μία γραμμή περιεχομένου.

Το τεστ πέντε λεπτών για το δικό σας site

Ανοίξτε τα Developer Tools του browser σας (F12), πηγαίνετε στο tab "Network", φιλτράρετε για "Img", και φορτώστε την πιο βαριά σελίδα του site σας. Ελέγξτε τρία πράγματα: ποια μορφή σερβίρεται (JPEG/PNG σημαίνει χαμένη ευκαιρία), τι μέγεθος αρχείου έχει η μεγαλύτερη εικόνα (πάνω από 500KB σημαίνει πρόβλημα συμπίεσης ή μεγέθους), και αν η πρώτη ορατή εικόνα φορτώνει άμεσα ή περιμένει.

Αν και οι τρεις απαντήσεις είναι θετικές (σύγχρονη μορφή, λογικό μέγεθος, άμεση φόρτωση της πρώτης εικόνας), έχετε ήδη λύσει το μεγαλύτερο μέρος του προβλήματος ταχύτητας που πιθανότατα έχει το site σας, χωρίς να χρειαστεί να αγγίξετε server, hosting, ή οτιδήποτε πιο σύνθετο. Αυτό συνδέεται άμεσα και με το πώς η Google αξιολογεί το core web vitals τι είναι της σελίδας σας, αφού το LCP element είναι σχεδόν πάντα μια εικόνα σε sites με οπτικό περιεχόμενο.

Ένα πραγματικό παράδειγμα με αριθμούς: μια gallery 20 εικόνων

Ας το κάνουμε συγκεκριμένο. Ένα boutique ξενοδοχείο θέλει να δείξει 20 φωτογραφίες δωματίων και κοινόχρηστων χώρων σε υψηλή ποιότητα, ακριβώς το είδος gallery που περιγράφουμε στο portfolio του KISMET, όπου το image-first design είναι ο πυρήνας της εμπειρίας. Αν κάθε φωτογραφία είναι σε αυθεντικό JPEG από επαγγελματική μηχανή, χωρίς καμία επεξεργασία, το μέγεθος αρχείου κυμαίνεται συνήθως στα 3-5MB ανά εικόνα. Είκοσι τέτοιες εικόνες σε μία σελίδα σημαίνουν 60-100MB συνολικού βάρους, κάτι που σε mobile δίκτυο μπορεί να χρειαστεί δεκάδες δευτερόλεπτα για να φορτώσει πλήρως.

Με τη ρύθμιση που δείξαμε παραπάνω (AVIF πρώτα, WebP δεύτερο, οκτώ breakpoints ανά μέγεθος οθόνης), το ίδιο σύνολο 20 εικόνων μειώνεται σε 6-10MB συνολικά, μια μείωση 85-90%. Ένας επισκέπτης σε κινητό δεν κατεβάζει καν την πλήρη ανάλυση 1920px. Κατεβάζει την εκδοχή 750px που ταιριάζει στην οθόνη του, σε μορφή AVIF, με μέγεθος αρχείου γύρω στα 80-150KB ανά εικόνα αντί για 3-5MB. Αυτή η διαφορά δεν είναι θεωρητική βελτίωση benchmark: είναι η διαφορά ανάμεσα σε επισκέπτη που περιμένει και επισκέπτη που κάνει κράτηση.

Πώς μετατρέπετε ένα υπάρχον αρχείο εικόνων, βήμα-βήμα

Αν διαχειρίζεστε ήδη ένα site με εκατοντάδες εικόνες σε JPEG/PNG, η μετάβαση δεν χρειάζεται να είναι χειροκίνητη ούτε να σταματήσει τη λειτουργία του site. Τρία βήματα, με αυτή τη σειρά:

Πρώτο, αυτοματοποιήστε τη μετατροπή στο επίπεδο του framework, όχι ανά αρχείο. Αν χτίζετε σε Next.js, το component <Image> κάνει αυτόματα τη μετατροπή σε AVIF/WebP με τη ρύθμιση που δείξαμε — δεν χρειάζεται να ξαναφορτώσετε χειροκίνητα καμία εικόνα. Αν είστε σε CMS χωρίς αυτή τη δυνατότητα, ένα CDN με image transformation (π.χ. Cloudflare Images, Cloudinary) κάνει την ίδια δουλειά on-the-fly.

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

Τρίτο, επαληθεύστε με πραγματική μέτρηση, όχι εντύπωση. Μετά τη μετατροπή, ανοίξτε ξανά το Network tab και επιβεβαιώστε ότι η μορφή που σερβίρεται άλλαξε πραγματικά — δεν είναι σπάνιο μια ρύθμιση να "εφαρμοστεί" στον κώδικα αλλά να μην ενεργοποιείται πραγματικά λόγω λάθους στη διαμόρφωση caching ή CDN.

Τι κάνουν λάθος οι περισσότερες επιχειρήσεις με τις εικόνες τους

Το πιο συχνό λάθος δεν είναι έλλειψη ενδιαφέροντος για ποιότητα — είναι το αντίθετο άκρο: ανέβασμα εικόνων απευθείας από τη μηχανή ή το κινητό, χωρίς καμία ενδιάμεση επεξεργασία, επειδή "η ποιότητα πρέπει να είναι η καλύτερη δυνατή". Αυτό μπερδεύει την ανάλυση της πηγής με την ανάλυση της παρουσίασης. Μια φωτογραφία 45 μεγαπίξελ από επαγγελματική μηχανή δεν χρειάζεται να σερβίρεται αυτούσια σε μια οθόνη browser των 1920 pixels πλάτους — το επιπλέον μέγεθος αρχείου δεν προσθέτει καμία ορατή ποιότητα, μόνο χρόνο φόρτωσης.

Δεύτερο συχνό λάθος: εικόνες που ανεβαίνουν απευθείας μέσα από ένα CMS από μη τεχνικό προσωπικό, χωρίς κανένα guardrail. Ένας υπάλληλος μάρκετινγκ ανεβάζει μια νέα φωτογραφία προϊόντος 8MB σε ένα άρθρο, χωρίς να ξέρει καν ότι υπάρχει ζήτημα μεγέθους. Η λύση δεν είναι να εκπαιδεύσετε κάθε άτομο που ανεβάζει περιεχόμενο — είναι να χτίσετε το pipeline ώστε η συμπίεση και η μετατροπή μορφής να συμβαίνουν αυτόματα στο επίπεδο του συστήματος, ανεξάρτητα από το ποιος ανεβάζει το αρχείο ή πόσο προσεκτικός είναι. Αυτό είναι ακριβώς το είδος θεμελιώδους ρύθμισης που ελέγχουμε σε κάθε technical seo audit πριν προτείνουμε οτιδήποτε άλλο.

Τρίτο λάθος, πιο σπάνιο αλλά πιο ακριβό όταν συμβαίνει: υπερβολική συμπίεση που καταστρέφει ορατά την ποιότητα, συνήθως από φόβο για το μέγεθος αρχείου χωρίς κατανόηση της σχέσης ποιότητας-μεγέθους. Η σωστή ρύθμιση ποιότητας AVIF/WebP (συνήθως 70-80% στην κλίμακα ποιότητας) παράγει αρχεία μικρά αλλά οπτικά αδιάκριτα από το πρωτότυπο. Κάτω από αυτό το εύρος, η συμπίεση γίνεται ορατή — «θολά» άκρα, artifacts γύρω από περιοχές έντονης αντίθεσης — και τότε το πρόβλημα δεν είναι πια ταχύτητα, είναι αντιληπτή ποιότητα brand.

Η ιδιαίτερη πρόκληση των e-shop με εκατοντάδες εικόνες προϊόντων

Ένα e-shop με 300+ προϊόντα, το καθένα με 3-5 φωτογραφίες, έχει μια εντελώς διαφορετική κλίμακα προβλήματος από ένα site παρουσίασης 10 σελίδων. Η χειροκίνητη διαχείριση 1.000+ αρχείων εικόνων δεν είναι απλώς κουραστική — είναι ουσιαστικά αδύνατη να διατηρηθεί σωστά με την πάροδο του χρόνου, καθώς προστίθενται νέα προϊόντα κάθε εβδομάδα. Εδώ η αυτοματοποιημένη ρύθμιση δεν είναι πολυτέλεια, είναι προϋπόθεση επιβίωσης της απόδοσης του site.

Αναλύουμε πλήρως το κόστος και τις τεχνικές απαιτήσεις ενός τέτοιου project στο άρθρο για το κόστος e-shop στην Ελλάδα — αλλά το τεχνικό σημείο εδώ είναι απλό: όσο μεγαλύτερος ο όγκος εικόνων, τόσο πιο κρίσιμο γίνεται να λυθεί το πρόβλημα μορφής και μεγέθους μία φορά, στο επίπεδο υποδομής, αντί να αντιμετωπίζεται ξανά και ξανά χειροκίνητα σε κάθε νέο προϊόν που προστίθεται στον κατάλογο.

Το βασικό συμπέρασμα

Η βελτιστοποίηση εικόνων δεν είναι θέμα θυσίας ποιότητας για χάρη ταχύτητας. Είναι θέμα σωστής ρύθμισης πριν καν χρειαστεί να κάνετε αυτή την επιλογή. Μια σωστά ρυθμισμένη σύγχρονη υποδομή —AVIF/WebP με fallback, responsive sizes, lazy loading εκτός από την πρώτη εικόνα, CDN— σας δίνει και τα δύο ταυτόχρονα, χωρίς compromise. Το μόνο κόστος είναι να το ρυθμίσετε μία φορά, σωστά, στην αρχή.

SVG και εικονίδια: γιατί δεν ισχύουν οι ίδιοι κανόνες

Όλα όσα περιγράψαμε παραπάνω αφορούν φωτογραφίες — pixel-based εικόνες όπου AVIF και WebP κερδίζουν καθαρά. Υπάρχει όμως μια ολόκληρη κατηγορία οπτικών στοιχείων όπου αυτοί οι κανόνες όχι μόνο δεν ισχύουν, αλλά εφαρμοσμένοι λάθος κάνουν περισσότερο κακό παρά καλό: λογότυπα, εικονίδια, γραφήματα με λίγα χρώματα και καθαρές γραμμές.

Ένα λογότυπο σε PNG των 40KB, μετατρεμμένο "για συνέπεια" σε WebP, συνήθως δεν κερδίζει τίποτα σε μέγεθος — μπορεί και να χάσει, γιατί οι αλγόριθμοι συμπίεσης φωτογραφιών (AVIF, WebP, JPEG) είναι σχεδιασμένοι για φυσικές εικόνες με χιλιάδες σταδιακές διαβαθμίσεις χρώματος, όχι για επίπεδα γραφικά με απότομες γραμμές. Το σωστό format για λογότυπα, εικονίδια, και γραφήματα είναι το SVG — ένα vector format που περιγράφει σχήματα μαθηματικά αντί για pixel-by-pixel. Ένα λογότυπο σε SVG ζυγίζει συνήθως 2-8KB, κλιμακώνεται σε οποιοδήποτε μέγεθος χωρίς απώλεια ποιότητας (χρήσιμο για retina οθόνες), και δεν χρειάζεται καν πολλαπλές εκδοχές ανά μέγεθος οθόνης όπως χρειάζονται οι φωτογραφίες.

Το λάθος που βλέπουμε συχνά: ένα ολόκληρο σύνολο εικονιδίων UI (κουμπιά μενού, βελάκια, εικονίδια κοινωνικών δικτύων) φορτωμένο ως ξεχωριστά αρχεία PNG, το καθένα με το δικό του HTTP request. Ακόμα κι αν κάθε αρχείο είναι μόλις 3KB, 20 τέτοια αρχεία σημαίνουν 20 ξεχωριστά requests πριν προλάβει ο browser να τα συνδυάσει σε λίγα connections. Η λύση είναι είτε inline SVG μέσα στο ίδιο το HTML (μηδενικά επιπλέον requests), είτε ένα SVG sprite sheet που φορτώνει όλα τα εικονίδια σε ένα request.

Το πρακτικό τεστ: αν ένα οπτικό στοιχείο έχει λιγότερα από 10-15 χρώματα και καθαρές γεωμετρικές γραμμές, ανήκει σε SVG. Αν έχει φυσική διαβάθμιση φωτός, σκιές, ή υφή (μια φωτογραφία δωματίου, ενός προϊόντος, ενός ανθρώπου), ανήκει στο pipeline AVIF/WebP που περιγράψαμε παραπάνω. Το να εφαρμόσετε τη λάθος κατηγορία στη λάθος εικόνα δεν είναι απλώς αναποτελεσματικό — είναι σπατάλη χρόνου ρύθμισης σε πρόβλημα που δεν υπήρχε καν.

Σε ένα τυπικό site με menu navigation, footer social icons, και UI decorations, η μετατροπή από PNG σε inline SVG σε αυτά τα στοιχεία μειώνει συνήθως τον αριθμό HTTP requests κατά 15-25, χωρίς να αλλάξει καθόλου το οπτικό αποτέλεσμα — ο επισκέπτης βλέπει ακριβώς το ίδιο, ο browser δουλεύει αισθητά λιγότερο. Είναι από τις σπάνιες βελτιώσεις τεχνικού SEO που δεν έχουν κανένα trade-off, μόνο καθαρό κέρδος.

Λίστα ελέγχου: 7 σημεία πριν πείτε ότι οι εικόνες σας είναι έτοιμες

Πριν κλείσετε το θέμα "εικόνες" ως ολοκληρωμένο, ελέγξτε αυτά τα επτά σημεία με τη σειρά. Δεν χρειάζεται κανένα προηγμένο εργαλείο πέρα από τα Developer Tools του browser σας. Πρόκειται για μηχανικό έλεγχο, όχι υποκειμενική κρίση — κάθε σημείο απαντιέται με ναι ή όχι, χωρίς περιθώριο για «μάλλον καλά είναι».

Πρώτο, μορφή αρχείου. Κάθε φωτογραφία σερβίρεται σε AVIF ή WebP, με JPEG/PNG μόνο ως fallback για παλιούς browsers, ποτέ ως πρωτεύουσα μορφή.

Δεύτερο, μέγεθος ανά breakpoint. Καμία εικόνα δεν σερβίρεται στην πλήρη desktop ανάλυσή της σε κινητή συσκευή — το srcset επιλέγει σωστά ανά πλάτος οθόνης.

Τρίτο, η πρώτη ορατή εικόνα φορτώνει άμεσα, χωρίς loading="lazy", ενώ κάθε εικόνα κάτω από το fold έχει loading="lazy" εφαρμοσμένο.

Τέταρτο, κάθε εικόνα έχει alt text που περιγράφει το περιεχόμενό της με φυσική γλώσσα, όχι κενό, όχι keyword stuffing.

Πέμπτο, κάθε εικόνα δηλώνει προκαθορισμένες διαστάσεις (width/height ή aspect-ratio) ώστε ο browser να δεσμεύσει τον χώρο πριν τη φόρτωση, αποτρέποντας layout shift.

Έκτο, λογότυπα και εικονίδια είναι SVG, όχι PNG. Αν βλέπετε PNG με "logo" ή "icon" στο όνομα αρχείου, είναι σχεδόν σίγουρα χαμένη ευκαιρία.

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

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

Αν και τα επτά περνάνε καθαρά, οι εικόνες σας δεν είναι απλώς "καλές" — είναι στο ίδιο επίπεδο ρύθμισης με τα πιο γρήγορα sites που έχουμε χτίσει, όπου το image weight έχει σταματήσει να είναι ο περιοριστικός παράγοντας ταχύτητας. Ό,τι απομένει μετά από αυτό το σημείο αφορά server, JavaScript, ή υποδομή — όχι πια εικόνες. Το κρατάμε σκόπιμα σε επτά σημεία, όχι είκοσι, γιατί μια λίστα ελέγχου που κανείς δεν διαβάζει μέχρι το τέλος δεν είναι λίστα ελέγχου — είναι διακόσμηση.