PDFMove
PDF-Geschwindigkeit im Web: Linearisieren, Komprimieren oder Aufteilen?
Vergleich

PDF-Geschwindigkeit im Web: Linearisieren, Komprimieren oder Aufteilen?

7 Min. Lesezeit

Auf Ihrer Website liegt ein Produktkatalog mit 60 MB, und die Nutzer warten darauf, dass er sich öffnet. Sie haben drei Werkzeuge zur Hand: Linearisierung (die Struktur neu ordnen), Komprimierung (die Datei verkleinern) und Aufteilen (sie in Teile zerlegen). Alle drei werden unter der Überschrift "PDF beschleunigen" behandelt, doch sie arbeiten mit völlig unterschiedlichen Mechanismen und bringen unterschiedlich viel.

Die Mechanismen der drei Methoden

Die Komprimierung verkleinert die Datei selbst. Sie kodiert Bilder in niedrigerer Auflösung neu, entfernt ungenutzte Objekte und komprimiert Datenströme neu. Die Datenmenge, die heruntergeladen werden muss, sinkt.

Die Linearisierung ändert die Dateigröße nicht, ordnet die Objekte aber neu an: Alles, was die erste Seite betrifft, wandert an den Anfang, und eine Hinweistabelle wird ergänzt, die angibt, wo jede Seite liegt. So wird die erste Seite sichtbar, bevor die Datei vollständig geladen ist, und man kann zur gewünschten Seite springen.

Das Aufteilen zerlegt die Datei in mehrere Teile. Der Nutzer lädt nur den Teil herunter, den er braucht.

Vergleichstabelle

| Kriterium | Komprimierung | Linearisierung | Aufteilen | |---|---|---|---| | Verringert die Dateigröße | Ja, erheblich | Nein (erhöht sie um 1–2 %) | Ja, pro Teil | | Zeit bis zur ersten sichtbaren Seite | Verbessert sich proportional | Verbessert sich dramatisch | Verbessert sich | | Qualitätsverlust | Je nach Einstellung vorhanden | Keiner | Keiner | | Serverseitige Voraussetzung nötig | Nein | Ja (Byte-Range) | Nein | | Beeinträchtigt die Nutzererfahrung | Wenn die Bildqualität sinkt | Nein | Ja, man muss die Datei suchen | | Durchsuchbarkeit | Bleibt erhalten | Bleibt erhalten | Wird zerlegt | | Position im Arbeitsablauf | 1. | 3. (zuletzt) | 2. |

Szenario 1: Produktkatalog mit 60 MB auf der Website

Nutzer öffnen ihn im Browser und blättern; die meisten lesen ihn nicht vollständig.

Siegerreihenfolge: Komprimierung → Linearisierung.

Komprimieren Sie zuerst. Produktkataloge sind voller hochauflösender Fotos, die meist mit 300 DPI vorbereitet wurden – richtig für den Druck, zu viel für den Bildschirm. Eine Absenkung auf 150 DPI kann die Datei auf ein Drittel schrumpfen lassen, und am Bildschirm ist der Unterschied kaum sichtbar. Aus 60 MB werden 20 MB.

Linearisieren Sie danach. Die erste Seite der nun 20 MB großen Datei erscheint jetzt, nachdem einige Hundert Kilobyte geladen sind. Der Nutzer beginnt zu blättern, während die Datei im Hintergrund weiterlädt.

Das Aufteilen ist in diesem Szenario eine schlechte Idee: Der Nutzer will im Katalog stöbern, und ihm zu sagen "die Seiten 40 bis 80 liegen in einer eigenen Datei" verdirbt die Nutzererfahrung.

Szenario 2: Technisches Handbuch mit 500 Seiten

Nutzer kommen, um einen bestimmten Abschnitt nachzuschlagen, und lesen nicht das Ganze.

Sieger: Linearisierung, mit weitem Abstand.

Das ist genau das Szenario, für das die Linearisierung entworfen wurde. Dank der Hinweistabellen fordert der Browser, wenn der Nutzer auf Seite 347 springt, nur den Bytebereich dieser Seite an – ohne die 346 Seiten davor zu laden.

Auch die Komprimierung ist nützlich, doch technische Handbücher sind meist textlastig, und die Komprimierung bringt hier wenig. Die meisten Abbildungen sind Zeichnungen und Diagramme; sie zu reduzieren beeinträchtigt die Lesbarkeit.

Das Aufteilen wirkt hier verlockend (jedes Kapitel als eigene Datei), zerstört aber die Suchfunktion. Sucht ein Nutzer nach einem Begriff, weiß er nicht, in welcher Datei er steht.

Szenario 3: Archiv mit Monatsberichten von je 3 MB

Dutzende einzelner Dateien, die Nutzer wählen eine aus und laden sie herunter.

Sieger: Keine der Methoden ist nötig, aber Komprimierung schadet nicht.

Eine Datei mit 3 MB lädt über eine vernünftige Verbindung in wenigen Sekunden. Der Gewinn durch Linearisierung ist hier zu gering, um messbar zu sein, und sie fügt Ihrem Arbeitsablauf einen überflüssigen Schritt hinzu.

Die Komprimierung kann dennoch sinnvoll sein – besonders, wenn die Berichte aus Word nach PDF gewandelt wurden und die darin enthaltenen Grafiken unnötig hoch aufgelöst sind. Vorrang hat sie aber nicht.

Das Aufteilen ist bereits erfolgt (jeder Monat eine eigene Datei), und das ist die richtige Struktur.

Szenario 4: Gescanntes Archivdokument mit 200 MB

Von einer Behörde digitalisierte Altakten, die im Browser eingesehen werden.

Sieger: Komprimierung, danach Linearisierung – hinterfragen Sie aber zuerst die Scaneinstellungen.

200 MB deuten meist darauf hin, dass mit unnötig hoher Auflösung oder in Farbe gescannt wurde. Für ein reines Textdokument aus dem Archiv genügen 300 DPI in Graustufen mehr als reichlich, und die Datei wird deutlich kleiner. In Farbe gescannte Schwarzweißdokumente sind eine klassische Verschwendungsquelle.

Linearisieren Sie nach dem Komprimieren. Weil bei gescannten Dokumenten jede Seite ein großes Bild ist, fällt der Gewinn beim Seitensprung besonders deutlich aus.

In diesem Szenario ist auch das Aufteilen vertretbar: Archivdokumente bestehen meist aus eigenständigen Einheiten, und Nutzer suchen ein bestimmtes Schriftstück. Dann müssen Sie allerdings eine gute Indexseite oder eine Suchoberfläche bereitstellen.

Szenario 5: Nutzer laden die Datei herunter und öffnen sie lokal

Die Website bietet einen "Herunterladen"-Link, niemand liest im Browser.

Sieger: nur Komprimierung.

Der gesamte Nutzen der Linearisierung besteht darin, die erste Seite anzeigen zu können, während die Datei lädt. Lädt der Nutzer die Datei herunter und öffnet sie lokal, liegt sie bereits vollständig auf seinem Rechner; die Reihenfolge spielt dann keine Rolle mehr.

In diesem Szenario ist die einzige sinnvolle Optimierung, die Dateigröße zu senken – das verkürzt die Downloadzeit und senkt zugleich Ihre Bandbreitenkosten.

Wie weit man beim Komprimieren gehen sollte

Weil die Komprimierung in jedem Szenario gewinnt, sehen wir uns die Einstellungen genauer an. Die Frage, die die Bildauflösung bestimmt, lautet: Wie wird diese Datei genutzt?

| Einsatz | Empfohlene Bild-DPI | Hinweis | |---|---|---| | Nur Lesen am Bildschirm | 96–150 | Der aggressivste Gewinn | | Bildschirm plus gelegentlicher Druck | 150–200 | Sicherer Mittelweg | | Zu druckendes Dokument | 300 | Nicht darunter gehen | | Offsetdruck | 300+ | Nicht komprimieren |

Zudem sollte der verlustfreie Teil der Komprimierung immer durchgeführt werden: ungenutzte Objekte entfernen, eingebettete Schriften auf die verwendeten Zeichen begrenzen, Datenströme neu komprimieren. Das bringt bei den meisten Dateien 10–30 % Gewinn, ganz ohne Qualitätsverlust.

Die richtige Reihenfolge und warum sie wichtig ist

Wenn Sie alle drei durchführen, lautet die Reihenfolge:

1. Komprimieren. Hier liegt der größte Gewinn, und weil die anderen Vorgänge die Datei neu schreiben, muss dieser Schritt zuerst kommen.

2. Bei Bedarf aufteilen. Teilen Sie die bereits komprimierte Datei auf, ist auch jeder Teil komprimiert.

3. Linearisieren. Zuletzt. Denn jeder Vorgang, der die Datei neu schreibt, zerstört die Linearisierung.

In umgekehrter Reihenfolge ist Ihre Mühe vergeblich: Linearisieren Sie zuerst und komprimieren danach, schreibt die Komprimierung die Datei neu, und die linearisierte Struktur geht verloren.

Der vergessene vierte Faktor: die Serverseite

Unabhängig von den drei PDF-Vorgängen beeinflusst auch die Serverkonfiguration die Geschwindigkeit – manchmal sogar stärker:

  • Die Byte-Range-Unterstützung muss aktiviert sein. Sonst hilft die Linearisierung nicht.
  • Wenden Sie auf PDFs kein gzip an. PDFs sind intern bereits komprimiert; gzip bringt keinen Gewinn und stört Byte-Range.
  • Setzen Sie Cache-Header. Für einen unveränderlichen Katalog schaltet eine lange Cache-Control-Dauer den Download bei erneuten Besuchen vollständig aus.
  • Nutzen Sie ein CDN. Die geografische Entfernung macht bei großen Dateien einen erheblichen Teil der Verzögerung aus.

Diese Einstellungen bringen mitunter mehr als die Dateioptimierung und erfordern keinerlei Qualitätszugeständnisse.

Die Entscheidung im Überblick

Immer tun: komprimieren. Verlässlich, ohne Voraussetzungen, in jedem Szenario ein Gewinn.

Bei großen, im Browser gelesenen Dateien tun: linearisieren. Prüfen Sie aber, ob Ihr Server Byte-Range unterstützt, und machen Sie es zum letzten Schritt des Arbeitsablaufs.

Selten tun: aufteilen. Nur, wenn die Teile wirklich eigenständig sind und sich die meisten Nutzer für einen einzigen Teil interessieren. Weil es die Suchfunktion zerlegt, ist der Preis hoch.

Nicht vergessen: Die Serverkonfiguration gehört ebenfalls auf diese Liste, und dort finden Sie meist den günstigsten Gewinn.

Häufig gestellte Fragen

Wenn ich nur eines davon tun könnte – was sollte ich wählen?

Wählen Sie die Komprimierung. Die Dateigröße zu halbieren halbiert auch die Downloadzeit, und das wirkt unter allen Bedingungen, auf jedem Server und in jedem Browser. Der Nutzen der Linearisierung hängt dagegen von Voraussetzungen ab – der Server muss Byte-Range unterstützen und der Nutzer die Datei im Browser öffnen. Die Komprimierung liefert den verlässlicheren Gewinn.

Spricht etwas dagegen, alle drei zu tun?

Technisch nichts, doch die Reihenfolge ist wichtig. Komprimieren Sie zuerst, teilen Sie danach, falls nötig, und linearisieren Sie zuletzt. In umgekehrter Reihenfolge zerstört jeder Vorgang das Ergebnis des vorherigen – insbesondere die Linearisierung geht bei jedem Vorgang verloren, der die Datei neu schreibt. Zudem sollte das Aufteilen nur erfolgen, wenn es wirklich nötig ist, da es die Nutzererfahrung verkompliziert.

Wie stark senkt die Komprimierung die Qualität?

Das hängt von den Einstellungen ab. Ein Vorgang, der lediglich die Datenströme neu komprimiert und ungenutzte Objekte entfernt, verursacht keinen Qualitätsverlust, bringt aber nur begrenzten Gewinn. Der eigentliche Gewinn entsteht durch die Neukodierung von Bildern in niedrigerer Auflösung, und das ist ein sichtbarer Verlust. Für ein Dokument, das am Bildschirm gelesen wird, genügen meist 150 DPI; soll es gedruckt werden, sollte man 300 DPI nicht unterschreiten.

Ist es für Nutzer schlecht, einen großen Katalog aufzuteilen?

Meistens ja. Nutzer erwarten eine einzige Datei, wollen darin suchen und ihre Aufgabe mit einem Download erledigen. Das Aufteilen erschwert all das. Es ist nur dann sinnvoll, wenn die Teile der Datei wirklich eigenständig sind (jedes Jahr eines Jahresberichts, jede Kategorie eines Katalogs) und die meisten Nutzer sich nur für einen Teil interessieren.

Probieren Sie es gleich mit Web İçin Optimize Et aus.

Web İçin Optimize Et ausprobieren