De grootste prestatiewinst die ik ooit heb geleverd op WP Adminify's marketingsite was't een cachingplug-in of een CDN-tweak. Het was het verwijderen van één afbeelding. Onze oude held was een 2.400px PNG-screenshot I'd geëxporteerd op "volledige kwaliteit" omdat ik koppig geloofde dat PNG helder betekende. Dat ene bestand was 1,4 MB. Op een Android-element uit het middensegment boven 4G was het het grootste contentvolle verfelement - en het sleepte LCP naar ongeveer 4,1 seconden. Ik heb het geruild voor 84 KB WEBP bij de werkelijke weergavebreedte en LCP zakte dezelfde middag onder de 1.9s Geen code Gewoon een kleiner plaatje.
Dat' is het frustrerende aan beeld SEO. Het' is niet exotisch Afbeeldingen zijn meestal het zwaarste ding op de pagina - vaak bijna de helft van het totaal aantal bytes - en toch behandelen de meesten van ons ze als een bijzaak We laten een originele camera in het CMS vallen, typen & quot; screenshot" in het alt-veld, en gaan verder Dan vragen we ons af waarom de Core Web Vitals rapport in Search Console bloedt rood op mobiel.
Deze gids is de checklist die ik daadwerkelijk uitvoer op Toolz.dev en client sites, geschreven vanuit het perspectief van iemand die dit spul verzendt I & # 39; zal eerlijk zijn over wat de gratis tools doen en - net zo belangrijk - wat ze doen & # 39; t. Elk beeldhulpmiddel aan Toolz.dev draait volledig in uw browser op een <canvas>, dus niets dat je laat vallen, wordt overal geüpload. Dat heeft echte gevolgen voor je workflow, een aantal goede, een vervelende. We komen bij beide.
tl;dr: Verklein de afbeelding eerst naar de echte weergavebreedte, comprimeer en comprimeer vervolgens en serveer dan een modern formaat. In de praktijk zijn dat drie passen: Afbeelding wijzigen Om de pixelafmetingen te snijden, Afbeelding samendrukken om de bytes te knijpen, en Formaat converter Om webp te krijgen. Voeg toe
width/heightattributen om de lay-outverschuiving te stoppen, alt-tekst te schrijven die een mens hardop zou zeggen, en alles onder de vouw lui te laden. Doe dat en uw LCP en CLS verbeteren beide: de twee beeldgestuurde Core Web Vitals waarop Google daadwerkelijk scoort.
Waarom zijn afbeeldingen zo belangrijk voor SEO?
Twee van de drie Core Web Vitals zijn vermomde beeldproblemen Grootste Contentful Paint is, op de meeste contentpagina's, de heldafbeelding die zijn download afmaakt Cumulatieve lay-outverschuiving is heel vaak een afbeelding die laat wordt geladen en de tekst een regel lager wordt gezet. Beide zijn bevestigde rangschikkingsinvoer, en beide zijn dingen die je oplost door beter met afbeeldingen om te gaan - niet door meer inhoud te schrijven.
There' s een tweede verkeerskanaal mensen vergeten: Google Afbeeldingen Voor veel e-commerce, recept, reizen, en design sites, is het zoeken naar afbeeldingen een betekenisvol stukje organische bezoeken, soms een vijfde daarvan Dat verkeer hangt volledig af van dingen die een crawler kan lezen - de bestandsnaam, de alt tekst, de omringende kopie, en of de afbeelding zelfs klein genoeg is om snel geïndexeerd te worden.
En dan is er de saaie maar echte: bandbreedte kost geld en geduld. Een pagina die 3 MB aan afbeeldingen verzendt, stuitert mobiele gebruikers op gemeten verbindingen voordat ze uw kop zien. Snellere pagina's houden mensen in de buurt en betrokkenheid, hoe Google het ook meet, doet geen pijn.
Welk beeldformaat moet je eigenlijk gebruiken?
Formaatkeuze is waar de meeste besparingen leven, en de regels zijn eenvoudiger dan de formaatoorlogen ze laten klinken.
JPEG is voor foto's - alles met vloeiende gradiënten en duizenden kleuren It' s lossy, wat precies is wat je wilt voor een foto Bij kwaliteit 75-85 is de compressie onzichtbaar voor een normale kijker en het bestand is een fractie van het origineel Don' t gebruik het voor alles met harde randen, tekst of transparantie.
Great is verliesvrij Gebruik het voor screenshots, logo's, diagrammen, en alles met vlakke kleurgebieden of transparantie De vangst: voor een foto, PNG produceert een komisch groot bestand in vergelijking met JPEG Mijn 1,4 MB heldenfout was precies dit - een fotografisch-achtige screenshot gedwongen in PNG.
WEBP is de praktische standaard in 2026. Het doet zowel lossy als lossless, ondersteunt transparantie en animatie, en komt doorgaans 25-34% kleiner uit dan JPEG bij matching-kwaliteit. Browserondersteuning is nu universeel. Dit is het formaat waar ik bijna alles naar converteer.
voorwerp comprimeert nog harder - vaak betekenisvol kleiner dan WebP - omdat het ' s gebouwd op de AV1-videocodec It' is een geweldig formaat. Maar ik moet hier eerlijk tegen je zijn, omdat veel handleidingen (inclusief het concept dat dit artikel heeft vervangen) je vertellen dat je & quot; converteer gewoon naar AVIF" met een online tool, en dat ' is niet hoe browsercanvascodering werkt.
SVG Is voor vectoren: pictogrammen, logo's, eenvoudige illustraties. Het schaalt oneindig en blijft klein. Het is nutteloos voor foto's.
het Avif-voorbehoud dat niemand noemt
Hier is het eerlijke deel. Toolz.dev's Formaat converter uitvoer PNG, JPEG of WebP- en alleen die drie. 't Kan' t AVIF uitvoeren, en de meeste in-browser converters ook niet De reden is technisch: de tool tekent je afbeelding op een <canvas> en belt canvas.toBlob('image/webp', quality). De browser-encoder van de browser verzendt JPEG, PNG en WebP; het verzendt geen AVIF-encoder. Er is dus geen manier om een Avif uit een canvas te persen, punt uit.
Je kunt nog steeds gebruiken een AVIF-bestand in - de browser decodeert AVIF gelukkig via new Image(), dus een Avif-drop-in wordt goed weergegeven op canvas. Je krijgt er gewoon geen 1 terug. Het is een decode-in, code-out asymmetrie en het struikelt mensen constant.
Dus mijn echte advies: gebruik de format-converter voor de WebP-stap, degene die 95% van de overwinning dekt. Als je AVIF bovenop wilt, genereer het dan in je build-pijplijn met sharp, avifenc, of Squoosh's offline encoder - that's waar AVIF toch thuishoort, omdat de codering traag is en je het niet doet en#39; Ik wil het voor elke afbeelding met de hand doen.
| formaat | het beste voor | Verlies? | Toolz.dev converter kan het uitgeven? |
|---|---|---|---|
| JPEG | foto's foto | ja | ja |
| Great | Screenshots, logo's, transparantie | heel weinig | ja |
| WEBP | Bijna alles op internet | allebei | ja |
| voorwerp | Max compressie op zware afbeeldingen | ja | Nee - gebruik een bouwgereedschap |
| SVG | Pictogrammen, logo's, vectorkunst | oeuvre | Nee (vector, geen canvas) |
Hoe comprimeer je afbeeldingen zonder de kwaliteit te slopen?
De fout die ik het meest zie, is dat het verkeerde in de verkeerde volgorde wordt gecomprimeerd. Het comprimeren van een 4000px-afbeelding die wordt weergegeven met 800px is als het vacuüm maken van een koffer die u nooit hoeft in te pakken. Wijzig eerst het formaat, comprimeer als tweede. Altijd.
Dus de workflow is: open Afbeelding wijzigen, stel de breedte in op de grootste grootte waarop de afbeelding daadwerkelijk zal worden weergegeven (controleer uw lay-out - een blogbody-afbeelding is vaak 720-800px, niet 1920).De resizer past in uw doelvak en rekt of gewassen nooit, dus de beeldverhouding is veilig. Neem die uitvoer vervolgens mee naar Afbeelding samendrukken en trek de kwaliteit naar beneden totdat je het nauwelijks kunt zien - meestal 78-82 voor foto's. Voorbeeld bij volledige zoom voordat je het begaat; artefacten verbergen zich in gradiënten en huidtinten, niet in de miniatuur.
Een nummer om aan te ankeren: voor fotografische inhoud is kwaliteit 80 het saaie, betrouwbare antwoord. ik heb A/B'D 80 tegen 90 op echte productfoto's en, met 100% zoom op een goede monitor, kunnen de meeste mensen het niet noemen. Maar 80 is vaak 40% kleiner. Onder ongeveer 60 begin je blokkerige artefacten te zien in gladde gebieden, dus dat is de vloer voor alles behalve een kleine miniatuur.
Twee browser gotchas die je in verwarring brengen
Beide kostten me echte debugging-tijd, dus leer ze gratis.
Transparant PNG → JPEG maakt de achtergrond zwart, niet wit. Ik heb ooit een transparant logo omgezet naar JPEG en de transparante gebieden kwamen er effen zwart uit Ik ging ervan uit dat het gereedschap kapot was en besteedde twintig minuten aan het staren ernaar It' is geen bug - it' s de HTML-specificatie Wanneer u een canvas serialiseert naar een formaat zonder alfakanaal (JPEG), worden de transparante pixels samengesteld op effen zwart Als u transparantie nodig heeft, houdt u PNG of gebruikt u WebP, dat alfa ondersteunt Als u specifiek een witte achtergrond wilt, zet dan eerst een witte laag neer.
Elke hercodering stript EXIF en GPS-metadata. Omdat deze tools het beeld opnieuw tekenen op een vers canvas, heeft de uitvoer geen EXIF, geen camera-info, geen ingebedde GPS-coördinaten Dat' is een echte privacywinst - u' publiceert niet per ongeluk de breedtegraad/lengtegraad die uw telefoon in een foto heeft gestempeld Maar het' is ook een gotcha als u vertrouwde op ingebedde kleurprofielen of copyright-metagegevens; die gaan ook Voor SEO doet het ' maakt niet uit, maar weet het ' er gebeurt.
Hoe werken responsieve afbeeldingen en srcset?
Een telefoon geeft afbeeldingen weer op misschien 390px breed. Het verzenden van een bestand van 1920px verspilt de meeste bytes die u net zorgvuldig hebt gecomprimeerd. srcset Lost dat op door de browser een menu met maten te geven en het te laten kiezen.
<img
src="product-800.webp"
srcset="product-400.webp 400w,
product-800.webp 800w,
product-1200.webp 1200w"
sizes="(max-width: 600px) 100vw, 800px"
alt="Matte-black wireless headphones on a walnut desk"
width="800" height="600" loading="lazy" />
Om die drie bestanden te maken, voer je dezelfde bron uit Afbeelding wijzigen bij 400, 800 en 1200px, converteer elk naar WebP. sizes attribuut is het deel dat mensen overslaan, en het overslaan ervan breekt stilletjes het geheel - zonder dit, de browser gaat ervan uit dat de afbeelding de viewport vult en pakt de grootste kandidaat Vertel het hoe breed de afbeelding echt rendert en het downloadt de juiste.
Hoe schrijf je alt-tekst die echt helpt?
Alt-tekst is de andere helft van Image SEO en het is de halve ontwikkelaars die haasten. Het doet drie taken tegelijk: het is wat een schermlezer hardop voorleest aan een blinde gebruiker, het is hoe een crawler begrijpt wat de afbeelding laat zien, en het is de terugvaltekst als de afbeelding niet wordt geladen. Het goed doen gaat vooral over schrijven als een persoon, niet over schrijven als een trefwoordrobot.
De regel die ik gebruik: beschrijf de afbeelding zoals jij ' d het beschrijft aan iemand die een telefoongesprek voert Specifiek, natuurlijk, kort - minder dan ongeveer 125 tekens, dus schermlezers don' t knotten het onhandig in Skip & quot; image of" of & quot; foto van," omdat de schermlezer al aankondigt dat het ' een afbeelding is; leiden met die verspillingen de luisteraar's tijd. En als uw doelzoekwoord echt bij de afbeelding past, neem het dan natuurlijk eenmalig op. ' niet draadloos passen, laat het weg - een foto van een toetsenbord en altquot 740000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Een paar voor/naen van echte recensies die ik heb gedaan:
alt="image"→alt="Matte-black wireless headphones on a walnut desk"alt="chart"→alt="Bar chart of monthly revenue rising from $10K in January to $45K in December"alt="best cheap headphones buy now free shipping sale"(sleutelwoord gevuld) →alt="Over-ear headphones with the carrying case open beside them"
Eén nuance die mensen verkeerd hebben: puur decoratieve afbeeldingen - een scheidingswand, een achtergrond bloeien - moeten een ruimen alt="", geen beschrijving. Een lege alt vertelt de schermlezer om het volledig over te slaan, en dat is precies wat je wilt voor decoratie. Reserveer echte alt-tekst voor afbeeldingen die informatie bevatten.
Terwijl je het doet, noem het bestand ook beschrijvend. wireless-headphones-matte-black.webp pijpen IMG_4532.jpg Omdat zoekmachines de bestandsnaam als een signaal lezen en koppeltekens (niet onderstrepen) de scheidingsteken Google-paren als het woord breekt.
Hoeveel verandert dit eigenlijk Core Web Vitals?
LCP (grootste tevreden verf): je held is meestal het LCP element Serveer het op de juiste dimensies, in WebP, op kwaliteit ~80, en - kritisch - doe nee luie laad het. Lui-laden De boven-de-vouw held is een klassieke zelf-eigenaar; het vertraagt het exacte element dat LCP meet. Als het de held is, <link rel="preload" as="image"> het in plaats daarvan.
CLS (Cumulatieve lay-outverschuiving): altijd zetten width en height op de <img>. Met deze twee attributen kan de browser de ruimte reserveren voordat de afbeelding arriveert, zodat de tekst niet springt wanneer deze wordt geladen. Dit is de goedkoopste CLS-fix die er is en ik vind nog steeds dat sites het missen.
INP (interactie tot Next Paint): Afbeeldingen rijden niet direct inP, maar een pagina die stikt in 3 MB niet-geoptimaliseerde afbeeldingen, hongert de hoofdthread en het netwerk van de capaciteit die uw JavaScript nodig heeft om te reageren uit. Lichtere afbeeldingen, vlottere interacties, indirect.
Een paar dingen die ik heb geleerd op de vervelende manier
Audit voordat u optimaliseert Voer de pagina uit via PageSpeed Insights en repareer eerst het zwaarste bestand - de overtreder van 1,2 MB doet er meer toe dan 4 KB van een pictogram scheren Naambestanden als een mens: wireless-headphones-matte-black.webp pijpen IMG_4532.jpg in beeld zoeken omdat de crawler leest de bestandsnaam als een inhoud signaal Schrijf alt tekst you' d eigenlijk zeggen beschrijven van de foto aan iemand op de telefoon - specifiek, natuurlijk, trefwoord-ingesloten alleen waar het past, nooit met trefwoorden gevuld. En don' vergeet je grafiek openen deel afbeelding; een correct formaat 1200×630 die u hebt gemaakt in Afbeelding wijzigen is wat verschijnt in sociale previews en soms zoeken.
Veelgestelde vragen
Heeft beeldoptimalisatie echt invloed op SEO-ranglijsten?
Ja, via kernweb vitale functies. LCP en CL's zijn bevestigde Google-rangschikkingssignalen en beide zijn sterk beeldgestuurd. Geoptimaliseerde afbeeldingen verbeteren doorgaans de scores voor mobiele paginasnelheid met een merkbare marge en op mobiel die zich kunnen vertalen in rankingbewegingen. Het ontgrendelt ook Google Afbeeldingen als een aparte verkeersbron.
Kan ik afbeeldingen converteren naar AVIF met een gratis online tool?
Meestal niet, en Toolz.dev's Format Converter kan dat niet. In-browser converters trekken naar een <canvas>, en de browser's canvas encoder voert alleen JPEG, PNG en WebP uit - there' is er geen AVIF encoder beschikbaar. Converteer online naar WebP voor het grootste deel van de winst en genereer AVIF in uw build-pijplijn met tools zoals scherp of avifenc als u die nodig heeft.
Moet ik WebP of AVIF gebruiken in 2026?
WebP is de veilige standaard en wat ik als eerste bereik - universele ondersteuning, grote besparingen, en je kunt het in de browser maken AVIF comprimeert nog harder en is de moeite waard om toe te voegen voor grote helden- en galerijafbeeldingen, maar genereer het tijdens de bouwtijd en bedien het via <picture> Met een webp-terugval.
Welke kwaliteitsinstelling moet ik jpeg en webp comprimeren?
Kwaliteit 80 is het betrouwbare antwoord voor foto's. Het is meestal niet te onderscheiden van het origineel bij normaal kijken, terwijl het dramatisch kleiner is. Bekijk een voorbeeld van 100% zoom voordat u zich commeert, aangezien artefacten in verlopen en huidtinten verschijnen. Onder de 60 wordt compressie zichtbaar.
Waarom werd mijn transparante PNG zwart na het omzetten naar JPEG?
Omdat JPEG geen alfakanaal heeft. De HTML-canvasspecificatie zegt dat transparante pixels worden samengesteld op effen zwart wanneer u serialiseert naar een niet-alfa-formaat. Het is het verwachte gedrag, geen bug. Bewaar de afbeelding als PNG of WebP om de transparantie te behouden, of stel hem eerst op een witte achtergrond als je wit wilt.
uploaden deze tools mijn afbeeldingen naar een server?
Nee. De afbeeldingshulpmiddelen op Toolz.dev verwerken alles lokaal op een canvas in uw browser - het bestand verlaat uw apparaat nooit Een bijwerking die het weten waard is: elke hercodeer stript EXIF- en GPS-metagegevens, wat goed is voor de privacy, maar betekent dat ingebedde cameragegevens en kleurprofielen ook worden geschrapt.
Wat is de ideale bestandsgrootte voor een webafbeelding?
Als een ruw doelwit: Hero-afbeeldingen onder ~200 kB, in-contentafbeeldingen onder ~ 100 kb en miniaturen onder ~ 30 kb. Die zijn zeer haalbaar als u eenmaal de grootte van de werkelijke weergavebreedte en WEBP bedient, het exacte aantal is minder dan de gewoonte om het formaat te wijzigen-dan-compress-dan-convert.
Verwante lectuur en hulpmiddelen:
- Afbeelding samendrukken- knip de bestandsgrootte na het wijzigen van de grootte
- Afbeelding wijzigen- maak responsieve maten en sociale afbeeldingen
- Formaat converter- exporteer PNG, JPEG of WebP
- De handleiding voor afbeeldingen van de ontwikkelaars
- Afbeeldingscompressie uitgelegd



