Afbeeldingen optimaliseren 2 – Technische SEO
Afbeeldingen optimaliseren deel 2: technische optimalisatie
Er is veel gezegd en geschreven over SEO voor content (relevante tekst, juiste titels, sleutelwoorden en omschrijvingen, etc.) maar niet al te veel over een andere soort content, namelijk afbeeldingen. Als redacteur heb je de controle over de titel en alttekst-attributen maar niet altijd over de technische aspecten van afbeeldingen in je site. Hier heb je een goede samenwerking met je webdeveloper nodig.
Als vervolg op het vorige artikel over het optimaliseren van afbeeldingen, gaat dit blogartikel over de meer technische aspecten van afbeeldingen en wat jij of je webdeveloper kan doen om problemen te voorkomen. Zo laadt je site sneller en daarmee maak je ook de zoekmachines blij. Laten we beginnen met de afmetingen van afbeeldingen.
“Size matters”, ook bij afbeeldingen
Desktop site
Stel dat je een pakkend artikel schrijft over je nieuwste product en je krijgt er van de leverancier een mooie foto van. Deze zet je in je artikel en dan bekijk je het in de browser. Goh wat duurt het lang voordat de pagina laadt. Dit krijg je als je een afbeelding gebruikt die eigenlijk bedoeld is voor drukwerk – 3000 x 2000 pixels en dan 12MB! Dit is een extreem voorbeeld maar het gebeurt vaker dan je denkt. De huidige maximale breedte van het contentgebied op een webpagina is nu rond de 1000 pixels (met uitzondering van full-width sliders, die kunnen 1600 pixels breed zijn). De extra 2000 pixels in dit voorbeeld zijn dus overbodig en kosten alleen maar meer bandbreedte en laadtijd dan nodig is. Je verliest ook wat kwaliteit omdat je het aan de browser overlaat om de afbeelding te schalen. De manier van schalen en het resultaat verschilt per browser en OS.
De oplossingen kunnen verschillen per systeem maar ik zal me hier focussen op het meest gebruikte CMS (Content Management System): WordPress.
De oplossing(en):
- Als je WordPress gebruikt kun je zelf de maximale afmetingen (en verhoudingen) van alle afbeeldingen instellen (Instellingen -> Media). Deze zouden/moeten overeenkomen met de gebruikte ruimtes in de site (full-width, blog content en widget thumbnails). Vraag je webdeveloper om de juiste afmetingen in te stellen. WordPress gebruikt standaard 3 instelbare afbeeldingsformaten:
- Grote afmeting – afbeeldingen die gebruikt wordt over de volle breedte van de site – meestal tussen de 960 en 1000 pixels breed.
- Gemiddelde afmeting – afbeeldingen voor blog berichten – vaak 100% van de breedte waarin het bericht past +/-600 pixels
- Thumbnails – afbeeldingen voor bijvoorbeeld widgets – +/- 150 pixels
- Kies bij het inzetten van de afbeeldingen in je berichten/pagina’s het juiste afbeeldingsformaat. Zie afbeelding hieronder.
- Voor sommige doeleinden (bijvoorbeeld full-width sliders) moet je toch zelf de afbeeldingen op de juiste formaat croppen en vergroten of verkleinen. WordPress gebruikt dan de oorspronkelijke afbeeldingsformaat voor sliders zonder ze te schalen. Photoshop blijft hier nog altijd het beste gereedschap voor. Vraag naar de juiste afmetingen bij je webdeveloper.
- Uitgelichte afbeeldingen worden voor verschillende doeleinden gebruikt in WordPress; als afbeeldingen in een bloglijst, portfolio’s, galerijen, etc. De maker van je thema is verantwoordelijk voor het gebruiken van de juiste afmetingen. Een webdeveloper kan beter beoordelen of ze toch niet te groot zijn.
Weergave-instellingen in pagina’s/berichten
N.B. Ook als je de afmetingen verandert in de instellingen moet je alle afbeeldingen weer aanpassen aan de nieuwe waarden. Dit gaat jammer genoeg niet automatisch. Je kunt hiervoor een plugin gebruiken: Regenerate Thumbnails.
Mobiele site
Bovengenoemde probleem wordt nog duidelijker op de mobiele versie van je site. Met beperkte bandbreedte zal je bezoeker nog langer moeten wachten voor die te grote afbeeldingen. Als het te lang duurt om een mobiele pagina te laden wegens te grote afbeeldingen zullen Google en de bezoeker je hiervoor bestraffen; mobiel page-ranking naar beneden stellen en je zal waarschijnlijk bezoekers verliezen. Er zijn wat trucjes voor om andere content en ook verkleinde versies van je afbeeldingen te vertonen op mobiel.
De oplossing(en):
- Een apart mobiel thema gebruiken – (bijvoorbeeld met WPTouch Themes). De content wordt automatisch geformatteerd en afbeeldingen worden verkleind.
- Met wat javascript en PHP kan je webdeveloper de site laten reageren op verschillende apparaten en/of beeldschermresoluties. Voor mobiele apparaten zal WordPress dan verkleinde versies van je afbeeldingen gebruiken. In het het geval van Retina-schermen zal die ook grotere resoluties gebruiken. Het meest gebruikte javascript hiervoor op dit moment is Retina.js (zie “Afbeeldingen voor Retina en andere hoge resolutie schermen” hieronder).
- Steeds meer thema’s ondersteunen Retina afbeeldingen.
Het Retina.js-script maak je ook mogelijk met deze handige plugin (aanvulling mei 2017).
Compressie
Zelfs als je een afbeelding wegschrijft vanuit Photoshop via “Opslaan voor web” is dat niet het einde van het verhaal. Leuk en aardig, die afbeeldingen vanuit Photoshop die rond de 80kb zijn, maar als je toch 12 afbeeldingen op een pagina weergeeft dan is dat bijna 1MB. Kan het wat kleiner? Ja, dat kan. Voor elk bestandsformaat (.jpg, .png en zelfs .gif) is er een andere oplossing. De meeste van deze verwijderen onder andere de meta-informatie (EXIF) en overbodige kleurprofielen uit de afbeeldingen. Je 1MB in afbeeldingsgrootte wordt gereduceerd tot wel 80%! Er zijn ook twee varianten van het comprimeren; “lossless” en “lossy” oftwel het niet weggooien van kleurinformatie en dus behoud van kwaliteit of wel informatie weggooien en kwaliteitsverlies. Het kenmerk van zware JPEG compressie is zichtbare blokken van 8 x 8 pixels. Hieronder zie je een extreem voorbeeld van “lossy” compressie.
Lossless vs. lossy compressie
Hier zijn wat tools voor het comprimeren van je afbeeldingen die je kunt opnemen in je redactionele ‘workflow’.
De oplossing(en) afhankelijk van OS:
- ImageOptim; Offline tool, voor Mac computers: PNG, JPG
- RIOT; Offline tool, voor Windows computers: PNG, JPG
- Smush.it; Online tool; PNG en JPG afbeeldingen tot een bestandsgrootte van 1MB)
- SuperPNG; Photoshop plugin om PNG-bestanden nog kleiner te maken dan de standaard van Photoshop
- Tiny PNG; Online tool: voor PNG en JPG (was eerst alleen PNG)
- JPGmini Online tool: alleen voor JPG
- Compress PNG/JPG; Online tool voor zowel PNG als JPG
N.B. Zelfs bij de “lossy” methoden zul je vaak het verschil niet zien. Eerst experimenteren dus. Vaak kun je wat agressievere “lossy” compressie loslaten op afbeeldingen voor Retina-schermen. Zie volgende sectie.
Afbeeldingen voor Retina en andere hogeresolutieschermen
Stel dat je een afbeelding van 320 pixels breed gebruikt op je desktop site en dezelfde afbeelding op een Retina-scherm of andere hogeresolutie-apparaat bekijkt. Dat ziet er waarschijnlijk minder goed uit. Dit komt omdat de 72 PPI (pixels per inch) van je desktopscherm wordt ‘uitgesmeerd’ (technisch gezien ‘verdrievoudigd’ of meer) over de 220 t/m 326 PPI van een Retina-scherm. Minder informatie over een groter bereik dus. Dit zie je als een wazig beeld:
Afbeelding geschikt voor retina vs. non-retina (niet geschikt voor retina)
Om dit te voorkomen maak je aparte afbeeldingen voor hogeresolutieschermen die 1.5 tot 2 keer groter zijn dan voor op de desktop.
De oplossing(en):
- Gebruik de WP Retina 2X plugin. Hiermee hoef je er alleen maar voor te zorgen dat de originele afmeting van al je afbeeldingen voldoende zijn voor Retina schermen: 1.5 tot 2 keer groter. WordPress kiest dan de juiste afmeting voor het apparaat.
- Sinds de komst van Apple’s hogeresolutie-modifier “@2“ zal een iPhone/iPad afbeeldingen met deze extensie op een Retina scherm gebruiken. Samen met wat javascript (Retina.js bijvoorbeeld) kun je de normale afbeelding gebruiken, het script zorgt ervoor dat als er een hogeresolutie-apparaat gedetecteerd wordt, de lageesolutie-afbeelding wordt vervangen door de hogeresolutieversie. Dit werkt op alle apparaten, niet alleen op Apple producten.
- Voor afbeeldingen in de CSS (afbeeldingen geassocieerd met het thema) kun je CSS media queries gebruiken:
- @media
(-webkit-min-device-pixel-ratio: 2),(min-resolution: 192dpi) {
/* Retina-specifieke regels hier */
}
- @media
N.B. Omdat het scherm van een mobiele telefoon wat kleiner is kun je afbeeldingen voor hogeresolutieschermen wat agressiever comprimeren. Bijvoorbeeld in Photoshop schrijf je de oorspronkelijke afbeelding weg met 80% JPG compressie, maar voor de hogeresolutie-afbeelding kun je 30% compressie gebruiken. Het zal wel scherp blijven want de artefacten van de zware compressie zal meestal niet opvallen.
CSS sprites
Stel dat op je site 2 verschillende afbeeldingen van een pijltje (links- en rechtsaanduidingen) worden gebruikt voor verschillende doeleinden. En elke van deze pijltjes een apart mouse-overeffect heeft. Dit betekent dat de gebruiker 4 verschillende afbeeldingen moet laden. Voor elke afbeelding is er een extra HTTP-request. Waarom zou je deze dan niet in een enkele afbeelding verzamelen? In plaats van 4 HTTP-requests wordt alles in één request binnengehaald. Deze collectie van afbeeldingen wordt een “sprite” genoemd.
Losse afbeeldingen versus één CSS sprite
Met CSS kunnen we die ene afbeelding die nodig is in de sprite weergeven, de rest blijft verborgen. Voor het mouse-overeffect hoeven we dan de sprite alleen maar naar boven te schuiven (min Y-coördinaten). Het kost wel tijd om de afbeeldingen in een enkele sprite te verzamelen en de CSS aan te passen maar het is zeker de mooite waard. Dit is wel iets wat je webdeveloper voor je moet doen.
De oplossing: Eigenlijk is er alleen maar één oplossing;
Er was een webapp (bookmarklet) die het harde werk voor je overnam SpriteMe.
SpriteMe analyseert je pagina op mogelijke sprites
SpriteMe analyseerde alle losse afbeeldingen in je site en zorgde ervoor dat de afbeeldingen met dezelfde hoogte in dezelfde rij in de sprite kwamen te staan. Je kon de nieuwe sprite downloaden en SpriteMe schreef ook alvast de juiste CSS voor je weg.
Sinds 2019 lijkt SpriteMe niet meer te werken, alternatieven vind je hier.
Sitemaps voor afbeeldingen
Sitemaps worden meestal gebruikt om je content (pagina’s en berichten) te laten indexeren bij verschillende zoekmachines. Wat veel mensen niet weten is dat vooral Google je afbeeldingen en video’s ook apart indexeert. Hiervoor moet je deze media in je sitemap.xml apart opnemen.
Een voorbeeld van een XML sitemap voor afbeeldingen:
<?xml version="1.0" encoding="UTF-8"?> <urlset xmlns="http://www.example.com/sitemap.xml"> <url> <loc>http://www.example.com/foo.html</loc> <image:image> <image:loc>http://example.com/image.jpg</image:loc> </image:image> </url> </urlset>
De oplossing:
Via de plugin Google XML Sitemap for Images wordt dit makkelijker gemaakt in WordPress. Installeer de plugin en maak maar een sitemap voor je media aan. De plugin zorgt ervoor dat al je media samen met je content worden opgenomen in de sitemap.XML. Google en andere zoekmachines zullen de sitemap op ten duur indexeren maar het gaat veel sneller als je deze zelf in Google Webmaster Tools opneemt.
Conclusie
Het lijkt veel werk om rekening mee te houden met al deze technieken. En dat is eenmaal zo. Maar het loont wel. Je zult zeker een paar punten hoger scoren bij Google’s Page Speed en bij Yahoo’s Y-slow scores.
Voor meer informatie of het inzetten van deze technieken kun je best bij je eigen webdeveloper aankloppen. Samen kun je een workflow opzetten waarin alles geregeld wordt qua afbeeldingsoptimalisatie.
Ook interessant voor jou:
Jason is WordPress webdeveloper bij ORDNUNG. Als webdeveloper richt hij zich op de technische kant van WordPress websites. Vanuit deze kennis deelt hij zijn kennis op het blog van Letterzaken.
Contact: info@ordnung.nl
Jason zoals we hem kennen! Goed artikel.
Waar komt de constatering “maximale breedte van een webpagina is 1000 pixels” vandaan? Ik werk al jaren op een full HD scherm. Als ik kijk naar analytics van grote websites, dan is zeker 90% een groter scherm dan 1024 pixels.
Dank voor het aankaarten Jan-Willem. Waar Jason op doelde is ‘het contentgebied op een website”, dit is inmiddels aangepast in het artikel. Laten we het houden op een gevalletje lost in translation, Jason spreekt beter Nederlands dan dat hij het schrijft, als Nederlander van Amerikaanse oorsprong :-)
Knappe research en goed weergegeven (met een terechte opmerking van Jan-Willem).
Dank voor je reactie Peter. De kritische noot is altijd welkom, ik weet dat niemand perfect is, dus zo zorgen we ervoor dat de juiste informatie wordt gegeven. Op basis van Jan-Willem’s reactie was er al een aanpassing gemaakt :-)
Hi, je schrijft over WP Mobile Detector Mobile Plugin. Die heeft zoals te lezen is geen ondersteuning voor WP 4.1
Welk alternatief is er als je wel op WP 4.1.1 zit?
WP Mobile Detector is, zoals Jason aangeeft, een plugin om een aparte mobiele weergave te creëren voor je WordPress website. Met een goed responsive of adaptive theme heb je deze plugin niet nodig.
Beste, kennen jullie een WordPress plugin waarbij je kan aanklikken of je afbeeldingen mobiel niet zichtbaar wil maken? Vriendelijke groeten
Hallo Elke, wanneer afbeeldingen voldoende verkleind zijn, zou dat mijns inziens niet nodig moeten zijn. Afbeeldingen ondersteunen de tekst en maken tekst leesbaarder. Qua plugins hiervoor kan ik je helaas geen advies geven, aangezien ik me niet -of in ieder geval heel weinig- met de technische zaken rondom WordPress bezighoud, verwijs ik je voor je vraag graag naar de WordPress support groep op Facebook: https://www.facebook.com/groups/wordpresssupportnl/
Hallo Nathan,
Ik werk op een pc met Linux OS. Om plaatjes te comprimeren voor de website maak ik gebruik van Libre Office Writer. In een file plaats ik alle originele plaatjes, die ik daarna met een tool binnen LO Writer comprimeer.
Vervolgens bewaar ik deze plaatje onder een nieuwe naam en daarna upload ik deze naar mijn media bibliotheek. Werkt prima
Hallo Wim,
Mooie aanvulling. Daar kunnen mensen nog wat aan hebben. top!
Beste Nathan,
Dank voor je heldere uiteenzetting. Even ter aanvulling op je artikel.
TinyPNG, met die vriendelijke Panda, kan tegenwoordig zowel PNG, als JPG gaan. Je kunt het in bulk gebruiken en daarnaast biedt TinyPNG plugins voor Photoshop, WordPress en Magento.
Je hebt helemaal gelijk Gerben. Overigens heb ik dit artikel niet zelf geschreven. Ik zal het wel even aanpassen nu :-)
Hoe kan ik eigenlijk vooraf zien wat de breedte van mijn content-gebied is? Jullie zeggen gemiddeld 1000px, maar op mijn blog (www.blogkracht.nl) plaats ik plaatjes van 650 px en die beslaan de hele breedte. Als ik voor 1000px was gegaan, had ik onnodig zware plaatjes geplaatst.
Het is dus afhankelijk van je template hoe breed je ideale afbeelding moet zijn. Maar weet iemand hoe je dat kunt zien aan een template? Ik heb het nu gewoon door trail-error achterhaald. Ik weet dat er tools voor zijn, maar weet alleen de namen niet.
Thanks,
Bastiaan
Ik vind dit ook altijd lastig Bastiaan. Daarom schakel ik hiervoor even mijn secondanten in, kijken wie er het eerste reageert, dan wel het beste antwoord heeft.
Het beste kun je met de de inspector uit de Dev tools van Google Chrome kijken wat de breedte van het vak is. Dan zit je altijd goed. Mocht je niet weten hoe die werkt kijk dan even hier: https://lamper-design.nl/pas-zelf-je-wordpress-website-aan-met-css/
Hi Kees,
Dat was ook de optie die ik uiteindelijk had gevonden. Dat werkte prima op mijn iMac. Dan moet je wel eerst het plaatjes iets ruimer op je site plaatsen en dan via de inspector kijken wat de ideale afmeting is. Zo kwam ik bij mij op 660px uit. Dat getal klopt inderdaad.
Echter… toen ik dit testte op mijn MacBook (kleiner scherm) kreeg ik een andere waarde: 498px of zo. Dat is toch gek? Enig idee waar dat aan kan liggen en hoe op te lossen. Ik zoek naar een optie die voor iedereen kan werken.
Thanks,
Bastiaan
Hi Bastiaan,
Dat zal liggen aan de thumbnails die gegeneerd worden vanuit je thema. Maar is hij op 498px dan niet volledig?
Groet,
Kees
Bij de voorbeelden van de afbeeldingen Retina – en non retinascherm zijn als ik het goed heb begrepen de afbeeldingen verwisseld.
MVG Ton Bruin
Ben even benieuwd waarop je dit baseert Ton. Bedoel je de afbeelding van ‘retina vs. non-retina’? Ik denk dat het juist ter illustratie is wat er gebeurt als je wél retina-ready afbeeldingen gebruikt (links, ‘retina’ dus) en wanneer je gewoon afbeeldingen uploadt en hoe die dan op een retinascherm worden weergegeven ( ‘non-retina’).