Web-Bildkomprimierungstechniken 2026: Geschwindigkeit, Qualität und Core Web Vitals

Anleitung

So nutzen Sie diesen Ratgeber

1

Aktuelle Bildgewichte prüfen

Nutzen Sie Browser-DevTools oder ein Page-Speed-Tool, um Bilder zu identifizieren, die am meisten zum Seitengewicht beitragen. Priorisieren Sie Bilder oberhalb der Falz, insbesondere den LCP-Kandidaten.

2

Das richtige Format je Bildtyp wählen

Verwenden Sie WebP für Fotos. Verwenden Sie PNG für Screenshots, Logos und UI-Grafiken. Nutzen Sie SVG für Symbole und Illustrationen, sofern möglich.

3

Qualitätsziel festlegen und visuell testen

Starten Sie bei Qualität 80 für WebP-Fotos. Vergleichen Sie die komprimierte Ausgabe mit dem Original in der beabsichtigten Anzeigegröße. Reduzieren Sie, wenn der Unterschied unsichtbar ist, erhöhen Sie bei sichtbarer Qualitätsminderung.

4

Vor der Komprimierung skalieren

Ein Bild, das mit 800px Breite ausgeliefert wird, benötigt keine 3000px Daten. Skalieren Sie zuerst auf die tatsächlichen Anzeigeabmessungen und komprimieren Sie dann. Dieser Schritt verringert die Dateigröße oft stärker als die reine Formatumwandlung.

5

Ausliefern und Core Web Vitals prüfen

Führen Sie nach dem Ausliefern komprimierter Bilder einen PageSpeed-Insights-Test durch und prüfen Sie den LCP-Wert. Die Verbesserung sollte messbar sein, wenn das LCP-Element bildbasiert war.

Inhaltsverzeichnis

• Einleitung: Warum Bildkomprimierung 2026 weiterhin ein wichtiges Core-Web-Vital-Signal ist
• Warum Bildkomprimierung weiterhin kritisch ist
• Verlustfrei vs. verlustbehaftet: der Entscheidungsleitfaden
• Komprimierungsverhältnisse nach Format
• Qualitätsschwellen-Tests
• Vorher/Nachher-Seitengeschwindigkeitsvergleich
• Serverseitige vs. browserseitige Komprimierung
• Werkzeugvergleich
• So stapelkomprimieren Sie ohne Qualitätsverlust

---

Einleitung: Warum Bildkomprimierung 2026 weiterhin ein wichtiges Core-Web-Vital-Signal ist

Jedes Jahr kursieren Prognosen, dass Bilder aufhören werden, ein Engpass für die Web-Leistung zu sein. Die Breitbandgeschwindigkeiten sind gestiegen. Mobile Netze haben sich verbessert. CDNs haben zugenommen. HTTP/2 und HTTP/3 haben die parallele Auslieferung von Assets effizienter gemacht. Und doch bleibt das Bildgewicht 2026 der größte Einzelbeitrag zur Ladezeit der meisten Content-Websites, E-Commerce-Shops und Medienangebote.

Der Grund, warum sich das nicht geändert hat, ist, dass die Bildnachfrage im gleichen Maß wie die Auslieferungskapazität gewachsen ist. Seiten, die früher zwei oder drei Bilder hatten, haben nun zehn oder fünfzehn. Hero-Bilder sind von 800px Breite auf 1600px oder mehr gewachsen, um Retina-Displays zu bedienen. Produktseiten, die früher ein Foto zeigten, zeigen nun acht Ansichten. Die gesamte Bildlast ist schneller gewachsen als die Infrastruktur zu ihrer Auslieferung.

Die Konsequenz ist: Bildkomprimierung ist kein gelöstes Problem und keine historische Sorge — sie ist eine der wirkungsvollsten technischen Entscheidungen in der heutigen Web-Performance, und die Details der Komprimierung zählen genauso sehr wie die Entscheidung, ob man überhaupt komprimiert. Dieser Leitfaden behandelt die Techniken, Werkzeuge und Entscheidungsrahmen, die 2026 die besten Ergebnisse liefern.

---

Warum Bildkomprimierung weiterhin kritisch ist

LCP und Core Web Vitals

Googles Core-Web-Vitals-Framework, das die Suchrangfolge seit 2021 beeinflusst, umfasst Largest Contentful Paint (LCP) als primäre Kennzahl. LCP misst die Zeit vom Beginn des Seitenladens bis zur Fertigstellung des größten sichtbaren Elements. Bei den meisten Content-Seiten ist dieses größte sichtbare Element ein Bild — ein Hero-Bild, ein hervorgehobenes Produktfoto, eine Artikelillustration.

Da LCP in echten Nutzersitzungen und nicht unter Laborbedingungen gemessen wird, wird seine Leistung stark von der tatsächlichen Downloadzeit des LCP-Bildes beeinflusst. Ein unoptimiertes JPEG-Hero-Bild von 1,2 MB lädt in einem 4G-Netz mit mittlerem Empfang spürbar länger als ein gut komprimiertes WebP-Äquivalent mit 400 KB. Der Unterschied zwischen einem schwachen LCP-Wert (über 4 Sekunden) und einem guten LCP-Wert (unter 2,5 Sekunden) wird häufig allein vom Bildgewicht bestimmt.

Mobile Nutzer und reale Bandbreite

Obwohl die Breitbandgeschwindigkeiten absolut gesehen gestiegen sind, stammt ein erheblicher Teil des Web-Traffics weiterhin von Mobilgeräten über Mobilfunkverbindungen mit schwankender Bandbreite. Ein Pendler im öffentlichen Nahverkehr, ein Einkaufender in einem belebten Einzelhandelsbereich, ein Nutzer in einer weniger erschlossenen Region — all diese Nutzer sind auf Verbindungen, bei denen das Bildgewicht spürbare Verzögerungen verursacht.

Wer für den Durchschnittsfall entwirft, lässt das Ende der Nutzer mit langsameren Verbindungen immer leiden. Bilder so stark zu komprimieren, dass sie bei einer 3-5-Mbps-Verbindung akzeptabel laden, sorgt dafür, dass alle Nutzer — auch die mit schnelleren Verbindungen — ein schnelles Erlebnis haben.

Energieverbrauch

Bildgewicht hat eine weniger diskutierte, aber reale Umweltfolge. Ein unnötig großes Bild verschwendet bei jedem Schritt Energie: im Rechenzentrum bei der Übertragung der Datei, in der Netzinfrastruktur beim Transport und im Gerät beim Empfang und Rendern. Bei hoch frequentierten Seiten ist die aggregierte Energieeinsparung durch korrekte Bildkomprimierung nicht unbedeutend. Dies ist eine Erwägung, die für größere Organisationen mit Nachhaltigkeitszielen zunehmend wichtig ist.

---

Verlustfrei vs. verlustbehaftet: der Entscheidungsleitfaden

Die grundlegende Komprimierungsentscheidung ist, ob verlustfreie oder verlustbehaftete Komprimierung verwendet wird. Das Richtige zu tun ist wichtiger als jede spezifische Werkzeugwahl.

Verlustfreie Komprimierung

Verlustfreie Komprimierung verringert die Dateigröße, indem sie die Bilddaten effizienter kodiert, ohne Informationen zu verwerfen. Das dekomprimierte Bild ist identisch mit dem Original. PNG nutzt verlustfreie Komprimierung. Auch verlustfreies WebP und verlustfreies AVIF existieren als Optionen.

Verlustfrei ist die richtige Wahl für:

• Screenshots mit Text, UI-Elementen oder Diagrammen — wo eingeführte Artefakte sichtbar und ablenkend wären
• Logos und Markengrafiken — wo Farbgenauigkeit und Kantenschärfe Anforderungen sind
• Quelldateien, die weiter bearbeitet werden — eine verlustbehaftete Komprimierung einer Quelldatei vor der Bearbeitung führt zu Artefakten, die sich mit jedem Bearbeitungszyklus addieren
• Bilder, bei denen bestimmte Pixelwerte eine Bedeutung tragen — wissenschaftliche Bilder, medizinische Aufnahmen oder technische Diagramme

Die Grenze der verlustfreien Komprimierung ist, dass sie bei komplexen Bildern wie Fotos nicht die gleichen Dateiverkleinerungen wie verlustbehaftete Komprimierung erreicht. Ein verlustfreies PNG eines Fotos enthält alle Originaldaten und komprimiert schlechter als ein gut abgestimmter verlustbehafteter Kompressor.

Verlustbehaftete Komprimierung

Verlustbehaftete Komprimierung erreicht Dateiverkleinerungen, indem sie Bilddaten identifiziert und verwirft, die von menschlichen Beobachtern kaum bemerkt werden. JPEG ist verlustbehaftet. Verlustbehaftetes WebP und verlustbehaftetes AVIF sind die modernen Äquivalente. Das Wahrnehmungsmodell hinter verlustbehafteter Komprimierung basiert auf Forschung darüber, wie das menschliche Auge Farbe, Helligkeit und Details wahrnimmt — hochfrequente Details in kontrastarmen Bereichen werden etwa verworfen, weil sie minimal zur wahrgenommenen Bildqualität beitragen.

Verlustbehaftete Komprimierung ist die richtige Wahl für:

• Fotos und fotografische Bilder
• Hero-Bilder, Produktaufnahmen und redaktionelle Bilder
• Jedes Bild, bei dem eine 10-20 % geringere wahrgenommene Qualität bei Anzeigegröße unsichtbar ist, aber eine 50-70 % kleinere Datei erzeugt

Der Schlüsselgrundsatz ist: Die Bewertung der Qualitätsminderung bei verlustbehafteter Komprimierung erfolgt bei der Anzeigegröße, nicht bei der Quellauflösung. Ein Artefakt, das beim Betrachten eines Bildes in 100 % nativer Auflösung sichtbar ist, kann völlig unsichtbar sein, wenn das Bild im Browser mit 400px Breite angezeigt wird.

---

Komprimierungsverhältnisse nach Format

Das Verständnis typischer Komprimierungsverhältnisse hilft, realistische Erwartungen zu setzen. Die folgende Tabelle zeigt typische Bereiche über eine breite Stichprobe fotografischer Inhalte.

Format	Komprimierungstyp	Typische Größe ggü. unkomprimiert	Hinweise
JPEG (Qualität 80)	Verlustbehaftet	8-15 % des Unkomprimierten	Etablierte Baseline
PNG	Verlustfrei	30-60 % des Unkomprimierten	Besser für Grafiken als Fotos
WebP (Qualität 80)	Verlustbehaftet	5-10 % des Unkomprimierten	25-35 % kleiner als JPEG
WebP (verlustfrei)	Verlustfrei	20-40 % des Unkomprimierten	Mitunter größer als PNG
AVIF (Qualität 60-70)	Verlustbehaftet	3-7 % des Unkomprimierten	30-50 % kleiner als WebP

Diese Bereiche sind illustrativ, nicht präzise. Tatsächliche Komprimierungsverhältnisse hängen stark vom Bildinhalt ab: flächige Bilder komprimieren besser als komplexe Texturen, rauscharme Bilder besser als ISO-raureiche Fotos, und Bilder mit großen einheitlichen Flächen besser als Bilder mit durchgehend hochfrequenten Details.

Das praktische Fazit: Für Web-Fotos ist WebP bei Qualität 80 ein verlässlicher Ausgangspunkt. AVIF bei vergleichbarer Qualität erzeugt eine merklich kleinere Datei. Für Oberflächenbilder und Screenshots ist verlustfreie Komprimierung in PNG oder verlustfreiem WebP angemessen.

---

Qualitätsschwellen-Tests

Die Qualitätseinstellung in einem verlustbehafteten Kompressor ist das Hauptregler, der den Trade-off zwischen Dateigröße und visueller Treue steuert. Zu verstehen, wie man diesen Regler für die eigenen Inhalte kalibriert, ist wertvoller als einer generischen Qualitätsempfehlung zu folgen.

Das Prinzip der unsichtbaren Minderung

Verlustbehaftete Komprimierung führt visuelle Artefakte ein, die mit sinkender Qualitätseinstellung sichtbarer werden. Doch der Zusammenhang zwischen Qualitätseinstellung und wahrnehmbarer Minderung ist nicht linear und hängt stark von den Anzeigebedingungen ab. Ein Artefakt, das bei 100 % Zoom in einem Bildeditor klar sichtbar ist, kann völlig unsichtbar sein, wenn dasselbe Bild in den beabsichtigten Web-Abmessungen und in normaler Lesedistanz betrachtet wird.

Das bedeutet: Qualität sollte stets bei der tatsächlichen Anzeigegröße getestet werden. Öffnen Sie das komprimierte Bild im Browser, betrachten Sie es in den Abmessungen, in denen es tatsächlich erscheint, und vergleichen Sie es visuell mit dem Original. Bewerten Sie die Qualität nicht anhand der Vollauflösungsdatei im Bildeditor — Sie würden die Qualität unnötig hoch setzen und Dateiverkleinerung liegen lassen.

Die Untergrenze finden

Der praktische Prozess, um die optimale Qualitätseinstellung zu finden:

1. Starten Sie bei Qualität 80 für Fotos.
2. Vergleichen Sie die komprimierte Ausgabe mit dem Original in den Anzeigeabmessungen.
3. Wenn die Bilder bei Anzeigegröße visuell identisch sind, senken Sie die Qualität um 5 und wiederholen Sie.
4. Wenn eine visuelle Minderung erkennbar ist, erhöhen Sie die Qualität um 5 und akzeptieren Sie diesen Wert.
5. Die optimale Qualität ist der niedrigste Wert, bei dem die Minderung bei Anzeigegröße unsichtbar ist.

Für die meisten Web-Fotos landet dieser Prozess irgendwo zwischen Qualität 70 und 85. Bilder mit komplexer hochfrequenter Textur (Gras, Stoff, Haar) benötigen tendenziell höhere Qualitätseinstellungen als Bilder mit sanften Verläufen und flachen Flächen.

Varianten nach Inhaltstyp

Verschiedene Inhaltstypen haben unterschiedliche Qualitätsgrenzen. Hauttöne in Porträtaufnahmen reagieren besonders empfindlich auf Komprimierungsartefakte — Banding in glatten Hautbereichen fällt bei niedrigeren Qualitätseinstellungen eher auf als bei einem Landschaftsfoto. Food-Fotografie, die auf Farbgenauigkeit und Appetitanreiz beruht, benötigt tendenziell höhere Qualitätseinstellungen als Produktaufnahmen vor einfarbigem Hintergrund. Das Verständnis der inhaltsspezifischen Qualitätsanforderungen des eigenen Veröffentlichungskontexts ermöglicht eine präzisere Optimierung.

---

Vorher/Nachher-Seitengeschwindigkeitsvergleich

Die tatsächliche Auswirkung der Bildkomprimierung auf die Seitengeschwindigkeit zu messen, ist essenziell, um die Arbeit zu validieren und ihren Wert zu kommunizieren. Die folgenden Werkzeuge und der Ansatz liefern verlässliche Vorher/Nachher-Messungen.

Was zu messen ist

Die primäre Kennzahl ist LCP — die Zeit zum Rendern des größten sichtbaren Elements. Bei bildlastigen Seiten ist dies fast immer ein Bild. Sekundäre Kennzahlen umfassen Total Blocking Time (TBT), die von Bildkomprimierung unbeeinflusst bleibt, und Cumulative Layout Shift (CLS), der von Bildern beeinflusst werden kann, wenn keine Abmessungen angegeben sind.

Für das absolute Seitengewicht verfolgen Sie das gesamte Bildgewicht laut Browser-Netzwerk-Tab. Filtern Sie auf Anfragen vom Typ „Img“ und notieren Sie die gesamte übertragene Größe vor und nach der Optimierung.

Messwerkzeuge

PageSpeed Insights (die Web-Oberfläche oder die API) liefert sowohl Labor- als auch Felddaten. Führen Sie den Test vor der Optimierung durch, notieren Sie den LCP-Wert und die spezifischen Größenempfehlungen für Ihre Bilder, wenden Sie die Optimierungen an, liefern Sie aus und führen Sie den Test erneut durch. Der Abschnitt „Opportunities“ zeigt die erwarteten Einsparungen durch Formatumwandlung und Komprimierung, bevor Sie sie umsetzen — nützlich, um zu priorisieren, welche Bilder zuerst optimiert werden.

Lighthouse in den Browser-DevTools liefert dieselben Messungen lokal und ist nützlich zum Testen vor der Auslieferung. Die Audits „Bilder korrekt dimensionieren“ und „Bilder in Next-Gen-Formaten ausliefern“ adressieren spezifisch die Probleme, die Bildoptimierung löst.

Ergebnisse interpretieren

Eine Verbesserung von 600 ms LCP auf 400 ms LCP bedeutet eine 33 % Verbesserung des LCP-Werts und kann den Unterschied zwischen „Verbesserung nötig“ und „Gut“ ausmachen. Die Schwellenwerte zählen: unter 2,5 Sekunden ist Gut, 2,5-4 Sekunden ist Verbesserung nötig, über 4 Sekunden ist Schwach. Eine Optimierung, die eine Seite von 2,6 auf 2,3 Sekunden bringt, hat größere Ranking-Auswirkung als eine, die von 2,0 auf 1,7 Sekunden bringt, selbst wenn die absolute Verbesserung kleiner ist.

---

Serverseitige vs. browserseitige Komprimierung

Bildkomprimierung kann an mehreren Punkten im Workflow stattfinden: beim Erstellen oder Hochladen des Bildes, während des Build-Prozesses, on-demand am CDN-Edge oder im Browser mit JavaScript-Werkzeugen. Jeder Ansatz hat andere Trade-offs.

Serverseitige Komprimierung

Serverseitige Komprimierung — ob während eines Build-Prozesses, als Teil einer CMS-Upload-Pipeline oder am CDN-Edge — ist der konsistenteste und skalierbarste Ansatz. Sie läuft einmal und die Ergebnisse werden zwischengespeichert. Alle Besucher erhalten optimierte Bilder unabhängig von Gerät oder Verbindung. Sie verbraucht keine Client-Ressourcen. Für jede Seite mit laufender Content-Veröffentlichung ist serverseitige Komprimierung die richtige langfristige Architektur.

Build-Zeit-Komprimierung mit in die Build-Pipeline integrierten Werkzeugen (Sharp in Node.js-Umgebungen etwa oder Astros eingebaute Bildoptimierung) wandelt und komprimiert Bilder im Rahmen des Deployment-Prozesses. Das ist Laufzeit-overhead-frei und erzeugt vorhersagbare, versionierte Ausgaben.

CDN-basierte Komprimierung und Formatumwandlung läuft am Edge und kann flexibler sein als Build-Zeit-Verarbeitung — sie kann je nach Accept-Headern und Viewport-Breite des anfragenden Geräts verschiedene Format- und Größen-Varianten ausliefern. Der Trade-off ist Kosten und die Komplexität der Konfiguration der CDN-Transformationsregeln.

Browserseitige Komprimierung

Browserseitige Komprimierung — Ausführen eines Komprimierungsalgorithmus im Browser mit JavaScript und der Canvas-API — ist für verschiedene Szenarien geeignet. Sie ist nützlich für Einzeldateien, bei denen der Nutzer Ein- und Ausgabe kontrolliert. Sie ist die richtige Wahl für vom Nutzer eingereichte Inhalte, die nicht auf einem Server gespeichert werden sollen, bevor der Nutzer der Veröffentlichung zugestimmt hat. Sie ist nützlich für Entwickler, die schnell prüfen wollen, wie eine Datei bei einer bestimmten Qualitätseinstellung aussieht, ohne eine serverseitige Pipeline einzurichten.

Die Grenze der browserseitigen Komprimierung ist, dass sie auf dem Gerät des Clients läuft und dessen CPU und Speicher verbraucht. Für große Stapel großer Bilder kann das langsam sein. Und sie betrifft nur Dateien, die der Nutzer explizit verarbeitet — sie verbessert nicht die Auslieferung bestehender Inhalte auf einer Website.

Der ImgKit Image Compressor unter /tools/image-compressor/ ist ein browserseitiges Werkzeug, das die Komprimierung lokal ausführt, wodurch Dateien nie auf einen Server hochgeladen werden. Das ist besonders relevant für sensible oder vertrauliche Bilder.

---

Werkzeugvergleich

Die Landschaft der Bildkomprimierungswerkzeuge ist erheblich gereift. Die Hauptkategorien von Werkzeugen bedienen unterschiedliche Workflow-Kontexte.

Build-Tool-Integrationen

Für Seiten, die mit modernen Frameworks gebaut werden (Astro, Next.js, Nuxt usw.), ist Bildoptimierung als erstklassiges Framework-Feature oder gut gepflegtes Plugin verfügbar. Astros <Image />-Komponente wandelt und optimiert Bilder automatisch zur Build-Zeit. Next.js’ Image-Komponente übernimmt sowohl Optimierung als auch Lazy Loading. Diese Integrationen sind die beste Wahl für Seiten, deren Tech-Stack sie unterstützt — sie erfordern minimale Konfiguration und bieten automatische Optimierung für alle Bilder, die hindurchgehen.

CDN-Bilddienste

Bild-CDNs und Dienste mit Bildtransformationsfähigkeiten übernehmen Formatumwandlung und Komprimierung am Edge. Sie akzeptieren eine Standard-Bild-URL mit Transformationsparametern und liefern die passende Ausgabe. Diese Dienste verursachen Kosten, sind aber flexibel und erfordern keine Code-Änderungen, um verschiedene Formate an verschiedene Browser auszuliefern. Sie sind eine gute Wahl für hoch frequentierte Seiten mit großen Bildbibliotheken, bei denen Build-Zeit-Verarbeitung langsam wäre.

Browserbasierte Werkzeuge

Browserbasierte Komprimierungswerkzeuge sind am nützlichsten für Einzeldateien oder kleine Stapel — einmalige Optimierungsaufgaben, das Vorbereiten von Bildern vor dem Upload oder das Testen, wie eine Datei bei verschiedenen Qualitätseinstellungen aussieht. Sie erfordern keine Installation, keinen Server und keine Build-Konfiguration. Die Hauptgrenze ist der Durchsatz: Hunderte Bilder im Browser zu verarbeiten ist unpraktisch.

---

So stapelkomprimieren Sie ohne Qualitätsverlust

„Ohne Qualitätsverlust“ im Kontext verlustbehafteter Komprimierung bedeutet ohne wahrnehmbaren Qualitätsverlust bei der Anzeigegröße — nicht mathematisch verlustfrei. Das Ziel ist, den Qualitätsschwellenwert zu finden, unterhalb dessen die Minderung sichtbar wird, und darüber zu bleiben, während die Dateigröße so weit wie möglich reduziert wird.

Schritt 1: Aktuelle Bildgewichte prüfen

Nutzen Sie Browser-DevTools, ein Lighthouse-Audit oder ein Seiten-Crawl-Werkzeug, um Ihre schwersten Bilder zu identifizieren. Sortieren Sie nach Dateigröße und priorisieren Sie die Bilder, die am meisten zum gesamten Seitengewicht beitragen. Bilder oberhalb der Falz und der LCP-Kandidat sollten die meiste Aufmerksamkeit erhalten.

Schritt 2: Auf Anzeigeabmessungen skalieren

Skalieren Sie Bilder vor der Komprimierung auf die maximalen Abmessungen, in denen sie angezeigt werden. Ein Bild, das mit 800px Breite angezeigt wird und aus einer 3000px-breiten Quelle geladen wird, trägt die vierfache Pixelmenge. Skalieren Sie auf 800px (oder 1600px für 2x Retina) mit dem Bild-Skalierungswerkzeug unter /tools/image-resize/ oder einer Build-Tool-Integration.

Schritt 3: Format und Qualität wählen

Fotos: WebP bei Qualität 80 als Ausgangspunkt. Reduzieren Sie auf 70, wenn die visuelle Prüfung keine wahrnehmbare Minderung bei Anzeigegröße bestätigt. Oberflächenbilder und Screenshots: PNG für harte Kanten, verlustfreies WebP als Alternative.

Schritt 4: Verarbeiten und verifizieren

Verarbeiten Sie bei browserbasierten Werkzeugen die Dateien und öffnen Sie jede in einem Browserfenster, um die Qualität bei den tatsächlichen Anzeigeabmessungen zu prüfen. Bei Build-Tool-Integrationen führen Sie den Build aus und vergleichen Sie die Ausgabe mit den Originalen in der ausgelieferten Umgebung.

Schritt 5: Ausliefern und messen

Führen Sie PageSpeed Insights oder Lighthouse gegen die optimierten Seiten aus und verifizieren Sie die LCP-Verbesserung. Prüfen Sie die Audits „Bilder effizient kodieren“ und „Bilder korrekt dimensionieren“, um zu bestätigen, dass die Probleme gelöst sind.

Für tiefergehende Anleitung zum Schnittpunkt von Bildkomprimierung und Suchmaschinen-Performance siehe den Leitfaden zur Bildkomprimierung für SEO und Seitengeschwindigkeit. Für formatspezifische Anleitung siehe beste Bildgröße für Websites und den Leitfaden zum Komprimieren von Produktbildern für E-Commerce-Kontexte.

Häufige Fragen

Welche Qualitätseinstellung sollte ich für die WebP-Komprimierung verwenden?

Qualität 75-85 ist der richtige Startbereich für WebP-Fotos. Bei Qualität 80 sind die meisten WebP-Bilder bei typischen Anzeigegrößen visuell nicht vom Original zu unterscheiden. Testen Sie bei den tatsächlichen Anzeigeabmessungen, bevor Sie finalisieren.

Was ist der Unterschied zwischen verlustfreier und verlustbehafteter Komprimierung?

Verlustfreie Komprimierung verringert die Dateigröße, ohne Bilddaten zu verwerfen. Verlustbehaftete Komprimierung entfernt Daten, die visuell kaum auffallen. Verlustfrei eignet sich für Screenshots und UI-Grafiken; verlustbehaftet für Fotos.

Wie stark kann die Komprimierung LCP-Werte verbessern?

Bei Seiten, bei denen das LCP-Element ein Hero-Bild ist, kann der Wechsel von einem unkomprimierten JPEG zu einem korrekt komprimierten WebP die Downloadzeit des LCP-Elements um 40-70 % senken und eine Seite oft von 'Schwach' auf 'Gut' im LCP-Rating heben.

Sollte ich Bilder serverseitig oder im Browser komprimieren?

Serverseitige Komprimierung (mit Build-Tools oder einem CDN-Bilddienst) ist konsistenter und deckt alle Besucher ab. Browserseitige Komprimierung ist nützlich für Einzeldateien oder wenn Sie die Server-Pipeline nicht kontrollieren.

Welches ist das beste kostenlose Browser-Tool zum Komprimieren von Bildern?

Der ImgKit Image Compressor läuft lokal im Browser, wodurch Ihre Dateien nicht auf einen Server hochgeladen werden. Er unterstützt JPG, PNG und WebP mit Qualitätsreglern und einer Zieldateigröße.

Hilft Größenänderung genauso viel wie Komprimierung?

Oft sogar mehr. Ein Bild, das in beiden Dimensionen doppelt so groß ist wie nötig, enthält viermal so viele Pixel. Das Ändern der Größe auf die Anzeigeabmessungen vor der Komprimierung ist häufig der effektivste einzelne Schritt zur Dateiverkleinerung.