Είναι το WebP πραγματικά μικρότερο από το JPG για εικόνες ιστοσελίδων;

Συγκρίναμε το JPG, το WebP και το AVIF στην ίδια φωτογραφία 538,6 KB με την ίδια ρύθμιση, και το JPG κέρδισε. Να γιατί συμβαίνει αυτό και τι δείχνει η δίκαιη σύγκριση.

August 9, 2026

Κάθε οδηγός σας λέει ότι το WebP είναι περίπου 30% μικρότερο από το JPG στην ίδια ποιότητα. Η δική μελέτη της Google είναι όπου προέρχεται αυτός ο αριθμός. Κάναμε τη σύγκριση με τον δικό μας συμπιεστή με μία φωτογραφία 3840x2160, texture.jpg στα 538,6 KB, και στην ίδια θέση του ρυθμιστή το JPEG κέρδισε: 286,1 KB έναντι 290,3 KB για το WebP. Το AVIF, το φορμά που υποτίθεται ότι θα κερδίσει και τα δύο, έφτασε τα 312,7 KB.

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

Γιατί το WebP βγήκε μεγαλύτερο από το JPG στην ίδια ρύθμιση;

Ο συμπιεστής μας έχει μια ιδιαιτερότητα που μοιράζονται πολλά εργαλεία και σχεδόν κανένα από αυτά δεν αναφέρει. Όταν η έξοδος είναι JPEG και η είσοδος ήταν ήδη JPEG, διαβάζει τους πίνακες ποσοτικοποίησης από το αρχείο προέλευσης, εκτιμά την ποιότητα στην οποία αποθηκεύτηκε το αρχείο, και στη συνέχεια πολλαπλασιάζει τον ρυθμιστή σας με αυτήν την εκτίμηση. Ένα αρχείο που βαθμολογεί 60 με τον ρυθμιστή στο 80 κωδικοποιείται στο 48. Το WebP και το AVIF δεν έχουν τέτοια μεταχείριση, οπότε το 80 σημαίνει 80 και ο κωδικοποιητής κάνει αυτό που του λέτε. Αυτή η εκτέλεση στην κορυφή ήταν JPEG με αποτελεσματικό 48 έναντι του WebP με κυριολεκτικό 80. Ένα αρχείο που συμπιέζεται πιο σφιχτά είναι μικρότερο.

Η ανασ scale κερδίζει τη θέση της. Η επανακωδικοποίηση ενός ήδη-χαμένου JPEG στο 80 όταν γράφτηκε στο 60 προσθέτει bytes χωρίς να προσθέτει λεπτομέρειες πίσω, οπότε αντιμετωπίζουμε τον ρυθμιστή ως κλάσμα αυτού που έχει απομείνει στο αρχείο. Το βαθύτερο πρόβλημα ανήκει στο JPEG ίδιο: η προδιαγραφή αποθηκεύει τους ακατέργαστους πίνακες ποσοτικοποίησης και ποτέ δεν αποθηκεύει έναν αριθμό ποιότητας, οπότε το 75 στο Photoshop, το 75 στο MozJPEG και το 75 σε κάποιο PHP script είναι τρία διαφορετικά αρχεία. Η αντιστοίχιση του αριθμού σε δύο ρυθμιστές και η ονομασία του ως δίκαιη δοκιμή δεν λειτουργεί.

Πώς φαίνονται τα μεγέθη όταν τα συγκρίνετε σωστά;

Στο 63, το WebP γράφει 200,6 KB από αυτήν την πηγή 538,6 KB. Το AVIF στην ίδια ρύθμιση φτάνει τα 186,9 KB, και το 63 είναι αυτό που η έξυπνη λειτουργία μας επιλέγει για το AVIF ούτως ή άλλως, οπότε δεν είναι ένας αριθμός που επιλέξαμε για να κολακεύσουμε το φορμά. Αντιστοιχίστε πρώτα τα μεγέθη εξόδου, στη συνέχεια ανοίξτε και τα δύο αρχεία σε πλήρες μέγεθος και αποφασίστε ποιο μπορείτε να ζήσετε με. Αυτή είναι η σύγκριση που αξίζει να γίνει.

Πρέπει να χρησιμοποιήσω το AVIF τότε;

Σε bytes, το AVIF κερδίζει. Σε υπομονή, χάνει. Η κωδικοποίηση αυτού του πλαισίου 3840x2160 σε AVIF πήρε περίπου 10 έως 11 δευτερόλεπτα στον περιηγητή, ενώ το JPEG και το WebP επέστρεψαν αμέσως. Όλα αυτά είναι WebAssembly που τρέχει στον δικό σας υπολογιστή, οπότε αυτός είναι ο φορητός υπολογιστής σας που κάνει κωδικοποίηση AV1 intra, και το κόστος κλιμακώνεται με τον αριθμό των pixel. Υπάρχει μια δεύτερη παγίδα που αξίζει να γνωρίζετε: αν ο κωδικοποιητής WASM αποτύχει, επιστρέφουμε στον κωδικοποιητή καμβά του περιηγητή, και ο καμβάς μπορεί να γράψει JPEG, PNG και WebP αλλά δεν έχει καθόλου διαδρομή AVIF. Για μια μεγάλη παρτίδα, η Google προτείνει το εγγενές εργαλείο avifenc αντί των κατασκευών WebAssembly, και το κόστος δέκα κωδικοποιήσεων AVIF σε μία καρτέλα μετράται επίσης.

Τι χάνω όταν μετατρέπω ένα JPG σε WebP;

Τρία συγκεκριμένα πράγματα. Τα μεταδεδομένα πάνε πρώτα: η συμπίεση ή η μετατροπή αποκωδικοποιεί την εικόνα σε ακατέργαστους pixel και την επανακωδικοποιεί, οπότε το EXIF, οι συντεταγμένες GPS, το προφίλ ICC και η ενσωματωμένη μικρογραφία χάνονται όλα από την έξοδο. Η προσανατολισμός επιβιώνει, επειδή ο περιηγητής τον εφαρμόζει κατά την αποκωδικοποίηση. Αν χρειάζεστε την ημερομηνία λήψης, κρατήστε το αρχικό αρχείο. Και ένα χαμένο JPG που επανακωδικοποιείται ως χαμένο WebP είναι μια δεύτερη γενιά απώλειας στοιβαγμένη πάνω στην πρώτη, οπότε κάντε το μία φορά από την καλύτερη πηγή που έχετε.

Η χρωματική απώλεια είναι η δεύτερη απώλεια. Το χαμένο WebP είναι κλειδωμένο σε υποδειγματοληψία 4:2:0, χωρίς καμία επιλογή 4:4:4 οπουδήποτε στο φορμά, οπότε μια στιγμιότυπη οθόνη κώδικα με επισημασμένη σύνταξη ή ένα λογότυπο σε κορεσμένο κόκκινο μπορεί να φαίνεται χειρότερο στο WebP από ότι σε ένα JPEG του ίδιου βάρους. Οι φωτογραφίες δεν νοιάζονται. Η απόδοση είναι η τρίτη: ένα προοδευτικό JPEG ζωγραφίζει ένα τραχύ πλήρες καρέ νωρίς και οξύνεται καθώς φτάνουν τα bytes, και το WebP δεν έχει προοδευτική λειτουργία, οπότε ένα μεγάλο δείχνει τίποτα μέχρι να φτάσουν αρκετά από αυτό. Σε μια ηρωική εικόνα σε μια αδύναμη σύνδεση, αυτό αλλάζει πόσο γρήγορα φαίνεται η σελίδα ακόμη και όταν το αρχείο είναι μικρότερο.

Κερδίζει το WebP αν η εικόνα έχει διαφάνεια;

Το JPEG δεν μπορεί να κάνει διαφάνεια. Δεν υπάρχει κανένα κανάλι alpha σε οποιαδήποτε λειτουργία JPEG, οπότε για ένα λογότυπο ή μια κοπή ο πραγματικός διαγωνισμός είναι το PNG έναντι του WebP, και η περίπτωση για καθένα από αυτά τα δύο φορμά μετράται σε αυτά τα ίδια αρχεία. Οι αριθμοί μας για το PNG θέτουν τον πήχη που πρέπει να ξεπεράσετε: το alpha.png στα 900x606 και 942,4 KB κατέβηκε στα 383,9 KB μέσω της χωρίς απώλειες oxipng στο επίπεδο 3, και στα 98,3 KB μόλις το imagequant το μείωσε σε μια παλέτα, που είναι 90% με την διαφάνεια ανέπαφη. Το WebP αποθηκεύει την alpha χωρίς απώλειες ακόμη και μέσα σε ένα αρχείο με απώλειες, οπότε οι άκρες κοπής παραμένουν καθαρές είτε έτσι είτε αλλιώς. Αν φτιάχνετε την κοπή εξαρχής, ο αφαιρέτης φόντου μας πάντα γράφει PNG με alpha, και αυτό το PNG μπορεί να πάει κατευθείαν στον συμπιεστή αργότερα.

Ποιο από τα δύο πρέπει να βάλω στην ιστοσελίδα;

Αποστείλετε WebP για φωτογραφίες. Κάθε τρέχων περιηγητής το αποκωδικοποιεί, συμπεριλαμβανομένου του Safari, και οι εξοικονομήσεις είναι πραγματικές μόλις σταματήσετε να συγκρίνετε αριθμούς ρυθμιστή. Κρατήστε το JPG όπου το αρχείο πρέπει να ανοίξει σε παλαιό λογισμικό, ή όπου μια μεγάλη ηρωική εικόνα επωφελείται από την προοδευτική απόδοση περισσότερο από ότι επωφελείται από 30 KB. Ο οδηγός τύπων εικόνας του MDN είναι η αναφορά που πρέπει να ελέγξετε πριν δεσμεύσετε μια ολόκληρη βιβλιοθήκη σε ένα φορμά.

Ελέγξτε πρώτα τους pixel. Μια φωτογραφία 3840px είναι τέσσερις φορές πιο φαρδιά από μια στήλη περιεχομένου 960px που θα εμφανιστεί ποτέ, και κανένας κωδικοποιητής δεν σας δίνει πίσω αυτό που παραδίδει μια αναδιάταξη δωρεάν, οπότε ο αναδιαμορφωτής με τα 25/50/75 presets είναι ένα κλικ και συνήθως κερδίζει τη συζήτηση για το φορμά. Η κλίμακα ποιότητας έχει σημασία περισσότερο από το φορμά επίσης. Το ίδιο texture.jpg πήγε στα 212,4 KB στο 60 και 131 KB στο 30, και η έξυπνη λειτουργία κατέληξε στα 286,1 KB, 47% λιγότερο, χωρίς να σας ρωτήσει τίποτα.

Πώς μπορώ να εκτελέσω αυτή τη δοκιμή στην εικόνα μου;

Ανοίξτε τον συμπιεστή, ρίξτε τη φωτογραφία σας και αλλάξτε σε χειροκίνητο. Επιλέξτε JPG, σημειώστε το μέγεθος. Αλλάξτε το αναπτυσσόμενο μενού φορμά σε WebP στην ίδια ρύθμιση και σημειώστε αυτήν. Στη συνέχεια, τραβήξτε τον ρυθμιστή WebP προς τα κάτω μέχρι τα δύο αρχεία να βρίσκονται εντός μερικών KB το ένα από το άλλο, και δείτε τα δίπλα-δίπλα σε πλήρες μέγεθος, γιατί αυτή είναι η μόνη σύγκριση που σας λέει οτιδήποτε. Οι παρτίδες περιορίζονται σε 10 αρχεία και 50 MB. Αν προτιμάτε να παραλείψετε εντελώς τον ρυθμιστή, JPG σε WebP κωδικοποιεί σε σταθερή ποιότητα 80 χωρίς αναδιάταξη, WebP σε JPG επιστρέφει από την άλλη πλευρά με τη διαφάνεια να είναι επενδυμένη σε λευκό, και ο οδηγός PDF καλύπτει τη μία μετατροπή που κάνει τα αρχεία μεγαλύτερα.