Τι κάνει πραγματικά το lazy loading στο largest contentful paint σας

Το lazy loading είναι μια απόφαση προγραμματισμού, όχι ξόρκι ταχύτητας

Το lazy loading περιγράφεται συχνά ως βελτίωση απόδοσης, κάτι που ισχύει με τον ίδιο τρόπο που το να μην πακετάρεις μια βαλίτσα είναι μείωση βάρους. Βοηθά επειδή ο browser κάνει λιγότερη δουλειά στην αρχή.

Αυτή η διάκριση έχει σημασία για το Largest Contentful Paint, που συνήθως συντομεύεται σε LCP. Το LCP μετρά πότε αποδίδεται το μεγαλύτερο ουσιαστικό στοιχείο μέσα στη θύρα προβολής. Σε πολλές σελίδες, αυτό το στοιχείο είναι μια hero image. Σε άλλες, είναι ένας μεγάλος τίτλος, μια εικόνα poster, μια φωτογραφία προϊόντος ή ένα block περιεχομένου.

Το lazy loading αλλάζει το πότε ζητούνται οι πόροι. Δεν κάνει μια εικόνα να αποκωδικοποιείται γρηγορότερα, έναν server να αποκρίνεται γρηγορότερα ή μια γραμματοσειρά να αποδίδεται νωρίτερα. Αν κάνετε lazy load το λάθος πράγμα, ειδικά το στοιχείο που γίνεται LCP, λέτε στον browser να περιμένει πριν φέρει ακριβώς αυτό που πρέπει να εμφανίσει για να περάσει τα Core Web Vitals.

Γι’ αυτό το lazy loading χρησιμοποιείται υπερβολικά και κατανοείται ανεπαρκώς.

Τι κάνει ο browser όταν κάνετε lazy load μια εικόνα

Το native image lazy loading προστίθεται συνήθως έτσι:

<img src='hero.jpg' loading='lazy' alt='...'>

Με loading='lazy', επιτρέπεται στον browser να αναβάλει τη λήψη της εικόνας μέχρι να θεωρήσει ότι η εικόνα είναι πιθανό να χρειαστεί. Στην πράξη, οι browsers χρησιμοποιούν την απόσταση από τη θύρα προβολής, τις συνθήκες δικτύου, τις διαστάσεις της εικόνας και άλλες ευρετικές. Οι ακριβείς κανόνες είναι λεπτομέρειες υλοποίησης και μπορούν να αλλάξουν.

Με loading='eager', ή χωρίς lazy attribute στις περισσότερες περιπτώσεις, ο browser αντιμετωπίζει την εικόνα ως μέρος της κανονικής διαδικασίας φόρτωσης. Πρέπει ακόμη να ιεραρχήσει ανάμεσα σε CSS, JavaScript, γραμματοσειρές, εικόνες και άλλα requests, αλλά η εικόνα είναι άμεσα ανιχνεύσιμη.

Αυτό σημαίνει ότι το lazy loading επηρεάζει κυρίως τρεις φάσεις:

• Discovery: πότε ο browser εντοπίζει τον πόρο.
• Request start: πότε αρχίζει η λήψη μέσω δικτύου.
• Render timing: πότε ο πόρος μπορεί τελικά να αποκωδικοποιηθεί και να ζωγραφιστεί.

Για το LCP, το επικίνδυνο σημείο είναι το request start. Αν το request της εικόνας LCP ξεκινήσει αργά, όλα όσα ακολουθούν μετατοπίζονται επίσης αργότερα.

Ο απλός κανόνας: μην κάνετε ποτέ lazy load τον υποψήφιο LCP

Αν μια εικόνα είναι ορατή στην αρχική θύρα προβολής και είναι πιθανό να είναι το μεγαλύτερο contentful element, μην την κάνετε lazy load.

Αυτό περιλαμβάνει:

• hero images
• κύριες φωτογραφίες προϊόντων πάνω από το αρχικό ορατό τμήμα
• μεγάλες εισαγωγικές εικόνες άρθρων
• μεγάλες εικόνες τύπου background υλοποιημένες ως <img>
• εικόνες poster video όταν το poster είναι το κύριο οπτικό στοιχείο

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

Ένα συνηθισμένο μοτίβο αποτυχίας μοιάζει με αυτό:

1. Ο server στέλνει το HTML.
2. Ο browser αναλύει μια εικόνα πάνω από το αρχικό ορατό τμήμα.
3. Η εικόνα έχει loading='lazy'.
4. Ο browser περιμένει επειδή η ευρετική του lazy-loading λέει ότι μπορεί.
5. Το CSS και το JavaScript συνεχίζουν να φορτώνουν.
6. Το request της εικόνας ξεκινά αργότερα από όσο θα έπρεπε.
7. Το LCP καθυστερεί, παρότι το ίδιο το αρχείο εικόνας είναι σχετικά βελτιστοποιημένο.

Αυτό είναι απογοητευτικό επειδή η σελίδα μπορεί να φαίνεται τακτοποιημένη σε ένα code review. Το πρόβλημα δεν είναι μόνο το μέγεθος αρχείου. Είναι η προτεραιότητα.

Αν διαβάζετε αποτελέσματα εργαστηρίου και προσπαθείτε να καταλάβετε αν το LCP είναι όντως το ζήτημα, ο οδηγός μας για το πώς να διαβάζετε μια αναφορά Lighthouse χωρίς πανικό είναι σκόπιμα πρακτικός: ξεχωρίστε τα field data, τις εργαστηριακές ενδείξεις και τις διορθώσεις πριν αρχίσετε να αλλάζετε κώδικα. (Σημείωση: αν το routing σας είναι case-sensitive, χρησιμοποιήστε το ακριβές URL από το CMS σας.)

Διόρθωση: χρησιμοποιήστε το πραγματικό εσωτερικό URL

Το σωστό URL του άρθρου Wux είναι Πώς να διαβάσετε μια αναφορά Lighthouse χωρίς πανικό. Το βασικό σημείο παραμένει: εντοπίστε το στοιχείο LCP πριν αλλάξετε τη συμπεριφορά φόρτωσης.

Πότε το lazy loading μπορεί να βελτιώσει το LCP

Το lazy loading μπορεί να βελτιώσει έμμεσα το LCP όταν κρατά μη κρίσιμους πόρους έξω από τον δρόμο του browser.

Φανταστείτε μια σελίδα προϊόντος με μια hero εικόνα προϊόντος στην κορυφή και ένα carousel με δώδεκα εικόνες προτάσεων κάτω από το αρχικό ορατό τμήμα. Αν και οι δεκατρείς εικόνες φορτωθούν eagerly, ο browser μπορεί να ξοδέψει bandwidth και connection slots σε εικόνες που ο χρήστης δεν μπορεί ακόμη να δει. Σε ένα περιορισμένο δίκτυο, αυτό μπορεί να ανταγωνιστεί την hero image, το CSS ή τα αρχεία γραμματοσειρών.

Το lazy loading των εικόνων του carousel κάτω από το αρχικό ορατό τμήμα μπορεί να βοηθήσει την εικόνα LCP να φορτώσει νωρίτερα, επειδή λιγότερα μη κρίσιμα requests ανταγωνίζονται κατά την αρχική φόρτωση της σελίδας.

Αυτή είναι η νόμιμη περίπτωση απόδοσης για το lazy loading:

• φορτώστε eager τον υποψήφιο LCP πάνω από το αρχικό ορατό τμήμα
• κάντε lazy load τις εικόνες κάτω από την αρχική θύρα προβολής
• αποφύγετε βαριά scripts που εισάγουν σημαντικές εικόνες αργά
• κρατήστε τις διαστάσεις εικόνων στο HTML για να αποφύγετε layout shifts

Το lazy loading δεν είναι από μόνο του βελτιστοποίηση LCP. Είναι εργαλείο ιεράρχησης πόρων. Βοηθά όταν προστατεύει το critical path.

Το καλύτερο μοτίβο για εικόνες LCP

Για μια εικόνα LCP πάνω από το αρχικό ορατό τμήμα, ο στόχος είναι ο browser να την ανακαλύψει νωρίς, να τη ζητήσει νωρίς και να την αποδώσει χωρίς αστάθεια διάταξης.

Μια στιβαρή βάση μοιάζει με αυτό:

<img
  src='/images/product-hero.avif'
  srcset='/images/product-hero-800.avif 800w, /images/product-hero-1400.avif 1400w'
  sizes='(max-width: 768px) 100vw, 720px'
  width='1400'
  height='900'
  loading='eager'
  fetchpriority='high'
  decoding='async'
  alt='Black hiking backpack with roll-top closure'
>

Τα σημαντικά μέρη δεν είναι διακοσμητικά:

• Το loading='eager' αποτρέπει την καθυστέρηση του lazy-loading.
• Το fetchpriority='high' λέει στον browser ότι αυτή η εικόνα έχει σημασία.
• Τα width και height δεσμεύουν χώρο και μειώνουν το layout shift.
• Τα srcset και sizes αποτρέπουν υπερμεγέθεις λήψεις.
• Ένα σύγχρονο format μπορεί να μειώσει τον χρόνο μεταφοράς όταν χρησιμοποιείται προσεκτικά.

Αν εξακολουθείτε να σερβίρετε ένα μεγάλο JPEG σε κάθε οθόνη, το format εικόνας και η responsive διαστασιολόγηση μπορεί να έχουν μεγαλύτερη σημασία από το lazy-loading attribute. Για ένα πρακτικό decision tree, δείτε πότε το AVIF νικά το WebP και πότε όχι.

Οι background images χρειάζονται επιπλέον προσοχή

Οι CSS background images δεν ανακαλύπτονται τόσο νωρίς όσο οι κανονικές εικόνες HTML. Ο browser πρέπει να φέρει και να αναλύσει το CSS πριν μάθει γι’ αυτές. Αν το στοιχείο LCP σας είναι μια CSS background image, έχετε ήδη κάνει την ανακάλυψη δυσκολότερη.

Αυτό δεν σημαίνει ότι οι background images απαγορεύονται. Σημαίνει ότι πρέπει να είστε συνειδητοί.

Για διακοσμητικές εικόνες, τα CSS backgrounds είναι εντάξει. Για ουσιαστική hero απεικόνιση, ένα στοιχείο <img> ή <picture> είναι συνήθως καλύτερο επειδή είναι ορατό στον HTML parser, υποστηρίζει alt text και λειτουργεί καλά με responsive image attributes.

Αν πρέπει να χρησιμοποιήσετε CSS background για μια εικόνα LCP, σκεφτείτε να την κάνετε preload:

<link rel='preload' as='image' href='/images/hero.avif'>

Ούτε το preload είναι μαγικό ραβδί. Το preloading πάρα πολλών εικόνων δημιουργεί το ίδιο πρόβλημα προτεραιότητας με άλλο κοστούμι. Χρησιμοποιήστε το για τη μία εικόνα που πραγματικά έχει σημασία, όχι για κάθε εικόνα στο design system.

Το JavaScript lazy loading συχνά κάνει τα πράγματα χειρότερα

Πριν το native lazy loading υποστηριχθεί ευρέως, πολλά sites χρησιμοποιούσαν βιβλιοθήκες JavaScript που αντάλλασσαν το data-src με το src μετά τη φόρτωση της σελίδας ή αφού ενεργοποιούνταν ένας intersection observer. Μερικά ακόμη το κάνουν.

Αυτό μπορεί να είναι λογικό για μεγάλες σελίδες άρθρων ή galleries με πολλές εικόνες. Είναι κακή επιλογή για περιεχόμενο πάνω από το αρχικό ορατό τμήμα.

Ο browser preload scanner είναι γρήγορος, αλλά δεν μπορεί να ζητήσει μια εικόνα της οποίας το URL είναι κρυμμένο σε custom attribute μέχρι να τρέξει το JavaScript. Αν η hero image σας ξεκινά ως data-src='hero.jpg', έχετε καθυστερήσει την ανακάλυψη πίσω από download script, parsing, execution και framework hydration.

Αυτό είναι κακή ανταλλαγή για το LCP. Βάλτε τα κρίσιμα URL εικόνων σε πραγματικό HTML. Αφήστε τον browser να κάνει τη δουλειά του.

Το LCP δεν είναι πάντα πρόβλημα εικόνας

Σε ορισμένες σελίδες, το στοιχείο LCP είναι κείμενο. Σε αυτή την περίπτωση, το lazy loading εικόνων μπορεί να έχει μικρή άμεση επίδραση. Το bottleneck σας μπορεί να είναι render-blocking CSS, αργή απόκριση server, client-side rendering ή web fonts.

Οι γραμματοσειρές αξίζει να αναφερθούν επειδή είναι συχνή κρυφή αιτία καθυστερημένης απόδοσης κειμένου. Ένας μεγάλος τίτλος μπορεί να γίνει LCP, και η συμπεριφορά φόρτωσης γραμματοσειρών μπορεί να καθυστερήσει ή να αλλάξει το πότε ζωγραφίζεται αυτός ο τίτλος. Αν η δουλειά σας στις εικόνες δεν μετακινεί το metric, επιθεωρήστε άμεσα το στοιχείο LCP αντί να υποθέτετε. Το άρθρο μας για τα web fonts ως κέρδος απόδοσης καλύπτει τις βαρετές διορθώσεις που συχνά λειτουργούν: λιγότερα weights, σύγχρονα formats, λογικά fallbacks.

Πώς να δοκιμάζετε αλλαγές lazy loading χωρίς να ξεγελάτε τον εαυτό σας

Μην δοκιμάζετε κοιτάζοντας τη σελίδα σας σε office Wi-Fi. Πρέπει να δείτε το request timing.

Χρησιμοποιήστε αυτή τη ροή εργασίας:

1. Ανοίξτε το Chrome DevTools και καταγράψτε ένα Performance trace.
2. Ενεργοποιήστε network throttling, όπως Fast 4G ή Slow 4G.
3. Κάντε reload τη σελίδα με απενεργοποιημένο cache.
4. Βρείτε τον LCP marker.
5. Εντοπίστε το στοιχείο LCP.
6. Στο Network panel, ελέγξτε πότε άρχισε να φορτώνει αυτός ο πόρος.

Αν ο πόρος LCP ξεκινά αργά, ρωτήστε γιατί:

• Έγινε lazy loaded;
• Εισήχθη από JavaScript;
• Ήταν κρυμμένος στο CSS;
• Υποβαθμίστηκε πίσω από άλλες εικόνες;
• Ο server άργησε να αποκριθεί;

Έπειτα κάντε μία αλλαγή και ξαναδοκιμάστε. Η δουλειά στην απόδοση γίνεται μπερδεμένη όταν οι ομάδες αλλάζουν format εικόνας, lazy loading, preloading, JavaScript bundles και ρυθμίσεις CDN στο ίδιο deployment. Μπορεί να βελτιώσετε τη σελίδα, αλλά δεν θα ξέρετε ποια αλλαγή είχε σημασία.

Τα field data έχουν επίσης σημασία. Τα lab tools είναι χρήσιμα για διάγνωση, αλλά το LCP διαφέρει ανάλογα με τη συσκευή, το δίκτυο, τη θύρα προβολής, την κατάσταση cache και τη γεωγραφία. Χρησιμοποιήστε real-user monitoring ή δεδομένα Chrome User Experience Report όταν μπορείτε.

<!-- tool-cta:start -->

💡 Δοκιμάστε αυτό: Διατηρήστε την εικόνα LCP μικρή και φορτωμένη με προτεραιότητα περνώντας τη από το Image Compressor, ώστε να αποδίδεται γρήγορα χωρίς να χρειάζεται lazy loading.

<!-- tool-cta:end -->

Μια πρακτική πολιτική για τα περισσότερα websites

Για τα περισσότερα marketing sites, ecommerce pages, documentation sites και publisher pages, αυτή η πολιτική αρκεί:

• Κύρια εικόνα πάνω από το αρχικό ορατό τμήμα: eager load, εξετάστε υψηλό fetch priority.
• Εικόνες περιεχομένου κάτω από το αρχικό ορατό τμήμα: lazy load.
• Icons και μικροσκοπικά UI assets: συνήθως δεν αξίζει να τα σκέφτεστε μεμονωμένα.
• CSS background hero: επανεξετάστε το ως HTML image ή κάντε preload προσεκτικά.
• Hero image που εισάγεται από JavaScript: διορθώστε την αρχιτεκτονική rendering αν είναι δυνατόν.
• Carousels: eager load μόνο στο πρώτο ορατό slide· lazy load στα υπόλοιπα.

Υπάρχουν edge cases. Οι ευρετικές των browsers βελτιώνονται. Τα frameworks προσθέτουν αυτόματα image components. Ορισμένες πλατφόρμες πλέον αποφεύγουν το lazy loading σε εικόνες που εντοπίζονται κοντά στη θύρα προβολής. Παρ’ όλα αυτά, η αρχή δεν αλλάζει: οι κρίσιμοι πόροι πρέπει να είναι νωρίς και εμφανείς· οι μη κρίσιμοι πόροι πρέπει να περιμένουν.

Το lazy loading είναι πολύτιμο όταν εκφράζει αυτή τη διάκριση. Είναι επιβλαβές όταν κρύβει το πιο σημαντικό περιεχόμενο από τον browser μέχρι αφού η σελίδα έχει ήδη αρχίσει να χάνει τον αγώνα του LCP.