Progressieve JPEG vs Baseline:
Welke is beter voor het web?

Het visuele laadverschil

Het meest voor de hand liggende verschil tussen progressieve en baseline JPEG is hoe de afbeelding verschijnt terwijl deze nog steeds door de browser wordt gedownload. Dit is belangrijk omdat afbeeldingen vaak de grootste assets op een webpagina zijn, en op langzamere verbindingen kunnen ze seconden duren om volledig te laden.

Baseline JPEG: van boven naar beneden

Een baseline JPEG slaat afbeeldingsgegevens op in één scan, pixel rij voor pixel rij, van boven naar beneden. Als de browser bytes ontvangt, rendert deze wat het heeft:

• Bij 10% geladen: De bovenste 10% van de afbeelding is zichtbaar in volledig detail. De rest is leeg of een placeholder.
• Bij 50% geladen: De bovenste helft is volledig weergegeven. De onderste helft ontbreekt nog.
• Bij 90% geladen: Bijna klaar, maar de onderrand is nog leeg.
• Bij 100% geladen: De volledige afbeelding is zichtbaar.

De gebruiker ziet een “gordijenonthullings”-effect — een scherpe lijn tussen het weergegeven gedeelte en het ongeladen gedeelte.

Progressieve JPEG: wazig-naar-scherp

Een progressieve JPEG slaat afbeeldingsgegevens op in meerdere scans (doorgaans 3–5). De eerste scan bevat de laagste-frequentie DCT-coëfficiënten — de brede kleur- en helderheidsgegevens. Elke volgende scan voegt hoger-frequente details toe.

• Bij 10% geladen: De gehele afbeelding is zichtbaar als een zeer wazig, lage-resolutievoorvertoning. Je kunt het onderwerp, kleuren en compositie identificeren.
• Bij 50% geladen: De afbeelding is herkenbaar met gemiddelde details. Fijne texturen zijn nog steeds zacht, maar de algemene indruk is duidelijk.
• Bij 90% geladen: Bijna volledig detail. Alleen de fijnste texturen en randen zijn nog licht zacht.
• Bij 100% geladen: Identiek aan de baselineversie — volledige kwaliteit, elk detail aanwezig.

De gebruiker ziet de volledige compositie onmiddellijk, en kijkt dan toe hoe deze scherper wordt. Dit is psychologisch meer bevredigend dan toekijken hoe een half weergegeven afbeelding langzaam naar beneden groeit.

Hoe progressieve scans technisch werken

Om te begrijpen waarom progressieve JPEG zowel perceptueel beter als enigszins kleiner kan zijn, moet je weten wat die meerdere scans werkelijk bevatten.

Elk JPEG-afbeelding wordt opgebroken in 8×8 pixelblokken, en elk blok wordt getransformeerd in 64 DCT (Discrete Cosine Transform) coëfficiënten. Deze coëfficiënten variëren van de DC-coëfficiënt (de gemiddelde helderheid van het blok — de laagste frequentie) tot de AC63-coëfficiënt (de fijnste diagonale details — de hoogste frequentie).

In een baseline JPEG worden alle 64 coëfficiënten voor elk blok in één pass geschreven. De encoder verwerkt blok na blok, rij na rij, van boven naar beneden.

In een progressieve JPEG doet de encoder meerdere passes over de gehele afbeelding:

1. Scan 1 (alleen DC): Schrijft alleen de DC-coëfficiënt van elk blok. Dit is voldoende om een 8x-downgesampled versie van de afbeelding te reconstrueren — de wazig-preview.
2. Scan 2: Voegt enkele laagfrequente AC-coëfficiënten toe (AC1–AC5). De afbeelding wordt merkbaar scherper, randen verschijnen.
3. Scan 3–4: Voegt middenfrequente coëfficiënten toe. De meeste details zijn nu zichtbaar.
4. Uiteindelijke scan: Voegt de hoogfrequente coëfficiënten toe. De afbeelding bereikt volledige kwaliteit.

Het eindresultaat is wiskundig identiek aan de baselineversie. Dezelfde DCT-coëfficiënten, dezelfde kwantisatie, dezelfde pixels. Alleen de byteorde in het bestand verschilt.

Bestandsgrootteimpact

Een van de minder bekende voordelen van progressieve JPEG is dat het doorgaans iets kleinere bestanden oplevert dan baseline bij dezelfde kwaliteitsinstelling.

Waarom is progressief kleiner? In progressieve modus worden vergelijkbare DCT-coëfficiënten van de gehele afbeelding gegroepeerd in dezelfde scan. Dit creëert langere reeksen van vergelijkbare waarden, die Huffman-codering efficiënter comprimeert. In baselinemodus worden alle 64 coëfficiënten voor één blok samen geschreven voordat naar het volgende blok wordt gegaan — mengeling van laagfrequente en hoogfrequente gegevens met zeer verschillende statistische verdelingen.

De enige uitzondering is zeer kleine afbeeldingen onder 10 KB — kleine miniatuurtjes, pictogrammen en avatars. Voor deze geldt dat de overhead van meerdere scankopjes (elke scan voegt enkele bytes metagegevens toe) het compressievoordeel opweegt. Maar deze afbeeldingen zijn zo klein dat het verschil op zijn best een paar honderd bytes is.

Waargenomen prestaties en Core Web Vitals

Vanuit zuiver technisch oogpunt bereiken zowel progressieve als baseline JPEG volledige kwaliteit op exact hetzelfde moment — wanneer de laatste byte aankomt. De totale downloadtijd is identiek (of iets sneller voor progressief, gezien de kleinere bestandsgrootte).

Maar webprestaties gaan niet alleen om absolute snelheid. Waargenomen prestaties — hoe snel de pagina aanvoelt voor de gebruiker — is net zo belangrijk. En dit is waar progressieve JPEG een duidelijk voordeel heeft.

Gebruikers ervaren progressief als sneller

Onderzoek naar waargenomen laadsnelheid toont consistent aan dat gebruikers progressief-laadafbeeldingen sneller als ingeladen evalueren dan van-boven-naar-beneden baselineafbeeldingen, zelfs wanneer de werkelijke downloadtijd identiek is. De reden is eenvoudig: het zien van de gehele afbeelding in een wazig staat voelt als “bijna geladen,” terwijl het zien van alleen het bovenste derde van een afbeelding voelt als “nog steeds wachten.”

Impact op Core Web Vitals

Google's Core Web Vitals meten gebruikerservaring aan de hand van drie metrieken. Progressieve JPEG kan twee van hen positief beïnvloeden:

• Largest Contentful Paint (LCP): LCP meet wanneer het grootste inhoudselement zichtbaar wordt. Voor baseline JPEG rapporteert de browser LCP wanneer de afbeelding begint te renderen (bovenste rijen). Voor progressief arriveert de eerste scan snel en rendert het volledige afbeeldingsgebied (wazig). Beide rapporteren vergelijkbare LCP-tijden, maar de progressieve versie toont op dat moment een nuttiger-voorvertoning.
• Cumulative Layout Shift (CLS): Zowel progressief als baseline gedragen zich identiek voor CLS — de afbeeldingsafmetingen zijn bekend uit de JPEG-kop voordat pixelgegevens aankomen. Geen van beide modi veroorzaakt layout-verschuiving wanneer passende breedte-/hoogte-attributen of CSS aspect-ratio zijn ingesteld.
• Interaction to Next Paint (INP): Geen directe impact van beide modi.

Afbeeldingen boven de vouw

Voor grote heldenafbeeldingen aan de top van een pagina is progressieve codering bijzonder voordelig. Op een 3G mobiele verbinding duurt een 200 KB heldenafbeelding ongeveer 2 seconden om volledig te laden. Met progressieve codering ziet de gebruiker een herkenbare (zij het wazig) versie van de held na slechts 200–400 ms — genoeg om de visuele identiteit van de pagina te begrijpen terwijl de rest van de inhoud verder laadt.

Browserondersteuning in 2026

Progressieve JPEG geniet van universele browserondersteuning. Er is geen compatibiliteitsprobleem in enige moderne of zelfs matig oude browser:

Progressieve JPEG maakt deel uit van de originele JPEG-specificatie (ITU-T T.81, gepubliceerd in 1992). Het is al tientallen jaren ondersteund door elke grote afbeeldingsviewer en browser. Er is nul risico op compatibiliteitsproblemen.

Is progressief nog relevant in 2026?

Met HTTP/2, 5G-netwerken en breedbandsnelheden gemeten in honderden megabits, kan je je afvragen of het incrementele laadvoordeel van progressieve JPEG nog van belang is. Het antwoord is genuanceerd.

Op snelle verbindingen: Minimaal zichtbaar verschil

Op een glasvezelverbinding of een sterk 5G-signaal laadt een 200 KB afbeelding in minder dan 50 ms. Bij die snelheid toont geen progressief of baseline enig zichtbaar laadgedrag — de afbeelding verschijnt eenvoudig volledig weergegeven. De gebruiker ziet nooit de overgang van wazig naar scherp omdat alle scans aankomen voordat het eerste frame wordt getekend.

Op trage verbindingen: Nog steeds zeer relevant

Niet iedereen heeft snel internet. In 2026 verlaten aanzienlijke delen van de wereld zich nog steeds op 3G of overbelaste WiFi-netwerken. In deze omstandigheden:

• Een 300 KB afbeelding op een 1 Mbps verbinding duurt ongeveer 2,4 seconden.
• Met progressieve codering ziet de gebruiker een herkenbare voorvertoning in ~400 ms.
• Met baseline-codering ziet de gebruiker slechts de bovenste 15% van de afbeelding bij 400 ms.

Voor gebruikers op trage verbindingen — platteland, opkomende markten, overbelaste openbare WiFi, ondergrondse doorgang — biedt progressieve JPEG een aanzienlijk beter ervaring.

De bodem: Geen nadeel

Progressieve JPEG heeft geen nadelen in vergelijking met baseline voor afbeeldingen boven 10 KB:

• Dezelfde of iets kleinere bestandsgrootte.
• Dezelfde eindafbeeldingskwaliteit.
• Universele browserondersteuning.
• Beter waargenomen laadtijd op trage verbindingen.
• Geen extra coderingstijd (verwaarloosbaar verschil).
• Geen extra decoderingstijd in browsers.

Er is gewoon geen reden om baseline boven progressief voor webafbeeldingen te kiezen. Progressief is het uitsluitend betere standaard.

Hoe progressieve JPEG te maken

De meeste afbeeldingsverwerkingstools ondersteunen progressieve codering. Hier zijn de meest voorkomende methoden:

ImageMagick

ImageMagick gebruikt de vlag -interlace om progressieve codering te beheren:

# Progressieve JPEG
convert input.png -interlace Plane -quality 85 output.jpg

# Baseline JPEG (expliciet)
convert input.png -interlace None -quality 85 output.jpg

De optie -interlace Plane vertelt ImageMagick de DCT-coëfficiënten in frequentieband-volgorde (progressief) in plaats van blok-voor-blok-volgorde (baseline) te schrijven. De kwaliteitsinstelling is onafhankelijk — je kunt elk kwaliteitsniveau met beide interlace-modi combineren.

CleverUtils.com

Onze converter gebruikt standaard progressieve codering. Wanneer je een PNG uploadt en naar JPG converteert, is de uitvoer altijd een progressieve JPEG. Geen configuratie nodig.

Adobe Photoshop

Vink in Photoshop's “Opslaan voor web” (of “Exporteren als”) dialoogvenster het “Progressief” selectievakje aan. Schakel in het gewone “Opslaan als” JPEG-dialoog “Progressief” in het JPEG-optiesvenster in.

GIMP

Vouw bij het exporteren als JPEG de geavanceerde opties uit en vink “Progressief” aan. GIMP gebruikt libjpeg onder de motorkap, die progressieve codering volledig ondersteunt.

jpegtran (Lossless conversie)

Als je een bestaande baseline JPEG hebt en deze naar progressief wilt converteren zonder opnieuw te coderen (geen kwaliteitsverlies):

# Converteer baseline naar progressief (lossless)
jpegtran -progressive input.jpg > output.jpg

# Converteer progressief naar baseline (lossless)
jpegtran -baseline input.jpg > output.jpg

jpegtran herschikt de DCT-coëfficiënten zonder de afbeelding te decoderen en opnieuw te coderen. Dit is een werkelijk lossless bewerking — de pixels veranderen helemaal niet. Alleen de byteindeling in het bestand verandert.

Batchconversie met mogrify

Om een volledige map van baseline JPEG's naar progressief ter plaatse te converteren:

# ImageMagick mogrify (overschrijft originals)
mogrify -interlace Plane *.jpg

# Of met jpegtran (lossless, naar aparte map)
mkdir -p progressive
for f in *.jpg; do
  jpegtran -progressive "$f" > "progressive/$f"
done

Hoe te controleren of een JPEG progressief is

Je kunt bepalen of een bestaande JPEG-bestand progressieve of baseline-codering gebruikt met verschillende methoden:

ImageMagick identify

identify -verbose image.jpg | grep Interlace

Dit geeft Interlace: JPEG (progressief) of Interlace: None (baseline) uit.

file-commando (Linux/Mac)

file image.jpg

Voor een progressieve JPEG bevat de uitvoer “progressive” in de beschrijving. Voor baseline zegt het “baseline” of noemt geen van beide.

Python (Pillow)

from PIL import Image
img = Image.open("image.jpg")
print("Progressive" if img.info.get("progressive") else "Baseline")

Browser DevTools

Helaas tonen browser DevTools niet direct of een JPEG progressief of baseline is. Het tabblad Netwerk toont de bestandsgrootte en downloadtiming, maar niet de coderingsmodus. Gebruik een van de bovenstaande opdrachtlijnmethoden voor een definitieve controle.

Progressieve JPEG vs moderne alternatieven

In 2026 concurreert progressieve JPEG met nieuwere afbeeldingsformaten die hun eigen progressieve-achtige functies hebben:

WebP en AVIF produceren aanzienlijk kleinere bestanden maar ondersteunen geen progressieve decodering standaard. Ze laden van boven naar beneden zoals baseline JPEG. JPEG XL heeft een geavanceerde progressieve modus die superieur is aan die van JPEG, maar browserondersteuning blijft in 2026 beperkt.

Voor maximale compatibiliteit met progressief laden, blijft JPEG de enige universeel ondersteunde optie. Voor maximale compressie, overweeg WebP of AVIF met responsieve afbeeldingstechnieken (<picture> element) die terugvallen op JPEG voor oudere browsers.