Sleep een afbeelding of klik om te selecteren
PNG, JPEG, WebP, GIF, BMP, AVIF
Hoe het werkt
Een placeholder is wat de plaats van een afbeelding inneemt terwijl die wordt gedownload. Hij dient twee verschillende doelen: de exacte ruimte reserveren die de afbeelding gaat innemen, zodat de omringende tekst niet verspringt als ze verschijnt, en iets tonen dat op de uiteindelijke inhoud lijkt, waardoor het wachten korter aanvoelt dan bij een grijze rechthoek.
Er zijn drie families van oplossingen. Compacte hashes (BlurHash en ThumbHash) vatten de afbeelding samen in een tekenreeks die zo kort is dat je hem in een databasekolom naast de rest van het record kunt bewaren; de browser decodeert hem en tekent de vervaging. Data-URI's (de LQIP-thumbnail en de SVG) dragen de al gecodeerde afbeelding in de HTML of de CSS, dus ze hebben helemaal geen JavaScript nodig. En de effen kleur is de goedkoopste placeholder van allemaal: zeven tekens.
Wat het beste past, hangt af van waar de HTML vandaan komt. Komen de afbeeldingen uit een database en toon je er honderden, dan is de hash per record het lichtst. Genereer je statische pagina's of gebruik je een framework dat placeholders al ondersteunt, dan bespaart de data-URI je het toevoegen van decodeercode. Alle waarden die je hier ziet, worden in je browser berekend: de afbeelding wordt naar geen enkele server geüpload.
Voorbeelden
blurhash 4 × 3LGHC162?|cKNqSWDjtaghVfjfQfjDe lengte van een BlurHash hangt alleen af van het aantal componenten, niet van de grootte of de inhoud van de afbeelding: bij 4 × 3 zijn het altijd 28 tekens, bij 3 × 3 zijn het er 22 en bij 5 × 4 zijn het er 44.thumbhash3wcKNZpwh3eAiIh3iHiIiHCAB/eHEen ThumbHash neemt tussen 17 en 25 bytes in beslag, oftewel 24 tot 36 tekens in Base64. De exacte grootte hangt af van de beeldverhouding en van de vraag of er transparantie is, omdat het formaat ook het alfakanaal codeert.lqip 24 px webpdata:image/webp;base64,UklGRi…Een 24 px brede WebP-thumbnail blijft meestal onder 1 KB. Doordat hij in de HTML is ingesloten, levert hij geen extra verzoek op, maar hij maakt het document wel zwaarder, en dat wordt niet apart gecachet.Gebruiksscenario's
- Een BlurHash of ThumbHash in de afbeeldingentabel opslaan, zodat een lijst of een feed met oneindig scrollen vanaf het eerste moment iets toont.
- Het attribuut blurDataURL van next/image of de placeholder van NgOptimizedImage invullen wanneer de afbeelding geen statische import is.
- Layoutverschuiving (CLS) in product- of artikelkaarten voorkomen door de placeholder te combineren met de attributen width en height.
- Een placeholder insluiten in statische HTML, een e-mail of een sjabloon waar je geen decodeer-JavaScript kunt uitvoeren.
- Dezelfde BlurHash hergebruiken op het web en in mobiele apps, waarvoor decoders in Swift, Kotlin en Flutter bestaan.
- De gemiddelde kleur als achtergrond van een container gebruiken wanneer het bytebudget zelfs geen thumbnail toelaat.
Veelgestelde vragen
BlurHash of ThumbHash?
ThumbHash geeft de afbeelding getrouwer weer met minder bytes, behoudt transparantie en slaat de beeldverhouding op, dus je hoeft de originele grootte niet eens te kennen om hem te tekenen. BlurHash is ouder en minder nauwkeurig, maar heeft implementaties voor veel meer platforms en talen. Begin je vanaf nul, dan ThumbHash; heb je al BlurHash-decoders in je stack, dan is er geen reden om over te stappen.
Verbetert dit de LCP?
Niet rechtstreeks. De placeholder verbetert de beleving van snelheid en elimineert samen met width en height de layoutverschuiving, maar de LCP-meting vindt nog steeds plaats wanneer de echte afbeelding klaar is met tekenen. Sterker nog: als de hoofdafbeelding het LCP-element is, geef die dan geen loading="lazy" en stel hem niet uit achter een placeholder; markeer hem liever met fetchpriority="high" zodat de browser hem eerder opvraagt. Placeholders zijn bedoeld voor afbeeldingen buiten het eerste scherm.
Hoeveel componenten kun je het beste gebruiken in een BlurHash?
Vier bij drie werkt goed bij liggende afbeeldingen en drie bij vier bij staande. Elke extra component voegt twee tekens en iets meer detail toe, maar boven de zes of zeven is het verschil met het blote oog niet meer te zien, omdat het resultaat toch vervaagd wordt getoond.
Hash of data-URI?
De hash neemt enkele tientallen bytes per afbeelding in beslag en is ideaal wanneer er veel op dezelfde pagina staan, maar vereist code aan de clientkant om hem te decoderen. De data-URI heeft helemaal niets nodig, al weegt hij tien tot vijftig keer meer en reist hij mee in de HTML, die niet apart wordt gecachet. Bij een paar uitgelichte afbeeldingen is de data-URI beter; bij lange lijsten de hash.
Waarom de SVG gebruiken in plaats van de thumbnail zelf?
Omdat de vervaging door de browser wordt toegepast bij het tekenen van de SVG. Daardoor kun je uitgaan van een veel kleinere thumbnail zonder dat de pixelblokken zichtbaar worden bij vergroting, en het resultaat oogt bij elk formaat even zacht. De SVG zet het alfakanaal bovendien op ondoorzichtig, zodat de vervaging de randen niet transparant maakt.
Is er een limiet aan de grootte van de placeholder?
Dat hangt van het gereedschap af. Angulars NgOptimizedImage geeft een waarschuwing in de console wanneer de data-URI van de placeholder meer dan 4000 tekens telt, omdat het gewicht van de HTML vanaf dat punt zwaarder gaat wegen dan het voordeel. Dat is een goede algemene richtlijn: overschrijdt je thumbnail die waarde, verlaag dan de breedte of de kwaliteit.