← Zurück zum Blog

Wie viel Ihres CDN- und Bucket-Rechnungsbetrags ist unnötig gezahlt?

Dieser Artikel zitiert keine „Branchendurchschnittszahlen“. Die in den Text enthaltenen Komprimierungsdaten stammen aus eigenen Tests, und die Kostenermittlung basiert auf Formeln, die Sie mit Ihren eigenen Einzelpreisen aus der Rechnung berechnen können. Wenn man jeden Monat die Cloud-Rechnung prüft, schauen die meisten Menschen nur auf die Gesamtsumme: Etwas mehr als im Vormonat, aber immer noch innerhalb des Budgets, und so geht es vorbei. Wenn man die Rechnung jedoch aufklappt und nach Produkten aufschlüsselt, stellen viele Websites, Mini-Apps und Content-Plattformen fest, dass die beiden Spitzenplätze meistens nur zwei Dinge sind: …

Teilen

Dieser Artikel zitiert keine „Branchendurchschnittszahlen“. Die in den Text enthaltenen Komprimierungsdaten stammen aus eigenen Tests, und die Kostenermittlung basiert auf Formeln, die Sie mit Ihren eigenen Einzelpreisen aus der Rechnung berechnen können.

Wenn man jeden Monat die Cloud-Rechnung prüft, schauen die meisten Menschen nur auf die Gesamtsumme: Etwas mehr als im Vormonat, aber immer noch innerhalb des Budgets, und so geht es vorbei.

Wenn man die Rechnung jedoch aufklappt und nach Produkten aufschlüsselt, stellen viele Websites, Mini-Apps und Content-Plattformen fest, dass die beiden Spitzenplätze meistens nur zwei Dinge sind:

  • Objektspeicher: Speicherkosten pro GB·Monat
  • CDN / Internet-Verkehr: Kosten für den heruntergeladenen Datenverkehr pro GB

Und in beiden Bereichen nimmt meistens die Bildkompression den Großteil ein.

Das Problem ist, dass ein erheblicher Teil dieser Bytes vom Nutzer gar nicht wahrgenommen wird, Sie aber jeden Monat für sie bezahlen.


1. „Komprimiert beim Hochladen“ bedeutet nicht, dass genug komprimiert wurde

Viele Teams sagen: „Wir komprimieren beim Hochladen.“

Wir haben diesen Fall speziell getestet. Das Sample war eine Website, die das Hochladen von Bildern erlaubt, die beim Speichern bereits eine übliche Komprimierung durchlaufen hatten: 78 Ordner, 4624 Bilder, insgesamt 1,41 GB.

Größe Relativ zum Original
Originaldatei nach Webseitenkomp. 1,41 GB —
Als ZIP gepackt 1,41 GB -0,2%
Komprimierung durch ImgZilla 0,75 GB -46,8%

Auf der Basis „bereits komprimiert“ wurden weitere fast die Hälfte eingespart. Und bei allen 4624 Bildern konnte jede einzelne weiter komprimiert werden; kein einziges war „zu Ende komprimiert und direkt übersprungen“.

Der Grund ist nicht kompliziert: Die meisten Speicherkomprimierungen verwenden nur einheitliche Qualitätseinstellungen oder begrenzen die Größe, was eine konservative Einmalbearbeitung ist und das Kodierungsspektrum für jedes Format bei Weitem nicht ausnutzt.

Wenn Ihr Bildarchiv Fotos direkt aus der Kamera, Exporte aus Designvorlagen oder Originalbilder, die von der Redaktion hochgeladen wurden, enthält, ist der Speicherplatz noch größer. Wir haben das an 32.188 direkt aus der Kamera aufgenommenen JPEGs getestet und die Gesamtgröße um 76,8 % reduziert.


2. Speicherkosten sind eine Addition, Verkehrsgebühren sind eine Multiplikation

Das ist der Punkt, der am leichtesten übersehen wird.

  • Speicherkosten: Eine Datei wird im Bucket gespeichert und einmal im Monat nach ihrer Größe berechnet.
  • Verkehrsgebühren: Eine Datei wird einmal pro Zugriff nach ihrer Größe berechnet.

Deshalb machen sich 300 KB ungenutzter Bytes auf der Speicherrechnung kaum bemerkbar, aber wenn sie täglich 100.000 Mal aufgerufen werden, summieren sich das auf ca. 29 GB pro Tag auf der Verkehrsrechnung.

Je beliebter ein Bild ist, desto mehr Geld wird für unnötige Daten gezahlt. Und die beliebtesten Bilder sind genau die, die auf der Startseite, als Hauptproduktbilder oder als Artikelbilder „einfach so“ als Original hochgeladen werden.


3. Berechnen Sie Ihre eigene Rechnung

Glauben Sie niemandem Schätzungen, sondern holen Sie sich Ihre letzte Rechnung und wenden Sie die folgenden beiden Formeln an:

Monatlich zu ersparnder Speicherkosten ≈ Gesamtbildspeicher (GB) × Komprimierungsrate × Speichereinzelpreis (Yuan/GB·Monat)
Monatlich zu ersparnder Verkehrsgebühr ≈ Monatliche Bild-Downstream-Verkehrsmenge (GB) × Komprimierungsrate × Verkehrspreis (Yuan/GB)

Die Komprimierungsrate kann zunächst konservativ mit 40 % geschätzt werden (weniger als die bei unseren „bereits komprimiert“-Tests gemessenen 46,8 %), und Sie können die tatsächlichen Zahlen später durch Ihren eigenen Bildlauf ersetzen.

Hier ist ein Beispiel zur Demonstration (die Einzelpreise sind hypothetisch; ersetzen Sie sie durch Ihre eigenen Zahlen):

Projekt Wert
Bildspeicher 500 GB
Monatliche Bild-Downstream-Menge 10 TB
Speichereinzelpreis (hypothetisch) 0,12 Yuan/GB·Monat
Verkehrspreis (hypothetisch) 0,20 Yuan/GB
  • Speicher: 500 × 40 % × 0,12 ≈ 24 Yuan/Monat
  • Verkehr: 10240 × 40 % × 0,20 ≈ 819 Yuan/Monat

Man erkennt, dass der Großteil des Geldes im Verkehr liegt. Die Ersparnis beim Speicher ist nur ein Randbetrag, während die Ersparnis beim Verkehr das echte Geld ist. Und dieser Betrag wird monatlich gezahlt; so lange Sie die Bilder nicht bearbeiten, wird es weiterbezahlt.

Es gibt noch einige Erträge, die auf der Rechnung nicht sichtbar sind: schnellere Seitenladezeiten, weniger Datenvolumen für mobile Nutzer, bessere LCP-Werte und es ist einfacher, die Hauptpakete von Mini-Apps unter das Limit zu bringen.


4. Warum wissen wir, dass es komprimiert werden sollte, wird aber niemand dazu gebracht?

Wir haben viele Entwickler und Webmaster gefragt, und die Antworten sind im Grunde drei:

1. Angst vor Pfadänderungen.
Traditionelle Online-Komprimierungstools erfordern „Hochladen → Herunterladen → Umbenennen → Ersetzen → Referenzen im Code ändern“, und bei Projekten mit tausenden Bildern trauen sich niemand etwas daran zu tun.

2. Angst vor Qualitätsproblemen.
Nach der Komprimierung wird das Bild von Designern, der Redaktion oder dem Chef als „unscharf“ kritisiert, und niemand möchte dafür verantwortlich sein.

3. Zu umständlich.
Ordnerhierarchien sind verschachtelt, das Bearbeiten jeder einzelnen Datei ist nicht realistisch, und Skripte erfordern Parameteranpassung und die Handhabung verschiedener Formate.

ImgZilla wurde entwickelt, um genau diese drei Probleme zu lösen:

  • Komprimierung direkt am Ort: Nach der Komprimierung werden die Originaldateien direkt ersetzt, Dateinamen und Ordnerstruktur bleiben vollständig unverändert, Zeilenweise müssen keine Referenzen im Code geändert werden.
  • Visuell verlustfrei: PNG und SVG sind wirklich verlustfrei; für JPEG, WebP, AVIF und HEIC werden Parameter pro Format separat eingestellt, um sie im Bereich des Sichtbaren ohne Unterschied zu halten. Ein integriertes Vergleichsfenster mit geteiltem Bildschirm erlaubt es, auf echte Pixel zu vergrößern und den eigenen Check durchzuführen.
  • Einfach einen Ordner hineinziehen: Alle Unterordner werden rekursiv verarbeitet; es muss kein Datei ausgesucht und kein Regelschieberegler bedient werden.
  • Lokale Verarbeitung: Interne Assets und unveröffentlichte Produktbilder müssen nicht auf Drittservers hochgeladen werden.

5. Praktischer Prozess zum „Herunterbrechen“ (Schlankmachen) des Buckets

Wenn Ihre Bilder bereits im Objektspeicher liegen, sieht der Prozess ungefähr so aus:

  1. Synchronisation zum lokalen Laufwerk: Verwenden Sie Tools wie rclone, ossutil, coscmd, aws s3 sync, um das Bildverzeichnis auf den Mac zu ziehen.
  2. Zuerst eine Sicherung erstellen: Es ist eine gute Gewohnheit, und nicht deshalb, weil das Tool unzuverlässig wäre.
  3. ImgZilla hineinziehen: Ziehen Sie das gesamte Verzeichnis hinein und warten Sie, bis es fertig ist.
  4. Synchronisation zurück in den Bucket: Verwenden Sie dasselbe Tool für das Überschreiben und Hochladen; die Pfade bleiben gleich.
  5. CDN-Cache leeren: Führen Sie einen Verzeichnis-Leerlauf für das Bildverzeichnis durch, damit die Edge-Knoten die neuen Dateien erhalten.

Vergessen Sie Schritt 5 nicht. Wenn Sie dies nicht tun, verteilen die CDN-Knoten weiterhin die alten Dateien, und die Verkehrsrechnung sinkt erst, wenn der Cache abläuft.


6. Ehrliche Erklärung

  • ImgZilla ist derzeit nur für macOS verfügbar (macOS 12.3 oder höher), es gibt keine Windows-Version.
  • Abgesehen von PNG und SVG sind andere Formate visuell verlustfrei, nicht pixelgenau verlustfrei. Wenn Ihre Anforderungen an Pixelgenauigkeit absolut exakt sind (z. B. medizinische Bilder oder Assets, die für Pixelvergleiche benötigt werden), sollten Sie diese Dateien nicht neu kodieren.
  • Die Komprimierungsrate variiert von Bild zu Bild. Unsere gemessenen Einzelkomprimierungsverhältnisse lagen zwischen 32 % und 86 %. Wir empfehlen, zuerst ein Verzeichnis zu testen, die tatsächlichen Zahlen zu sehen und dann zu entscheiden.

Schlussbemerkung

Cloud-Anbieter weisen Sie nicht darauf hin, dass Bilder noch kleiner sein könnten, und in der Rechnung wird keine separate Zeile für „ungültige Bytes“ angezeigt.

Aber sie sind da, jeden Monat nach GB berechnet und einmal pro Zugriff erneut verlangt.

Ziehen Sie Ihr Bildverzeichnis in ImgZilla und lassen Sie es laufen. Vergleichen Sie die nächste Rechnung.

👉 ImgZilla herunterladen: https://imagetool.app/ImgZilla

Kleinere, schnellere Bilder?

Lade ImgZilla herunter und komprimiere lokal — deine Bilder verlassen den Mac nie.