If I could only do one, which should I pick?

Pick compression. Halving the file size halves the download time, and that works under all conditions, on every server, in every browser. Linearization's benefit depends on conditions — the server has to support byte-range requests and the user has to open the file in a browser. Compression delivers a more reliable gain.

Is there any downside to doing all three?

No technical downside, but the order matters. Compress first, split if needed, and linearize last. In the reverse order each operation undoes the previous one's result — linearization in particular is lost with every operation that rewrites the file. And because splitting complicates the user experience, it shouldn't be done unless it's genuinely needed.

How much does compression reduce quality?

It depends on the setting. An operation that only recompresses streams and drops unused objects causes no quality loss, but its gain is limited. The real gain comes from re-encoding images at lower resolution, and that's visible loss. For a document to be read on screen, 150 DPI is usually enough; if it will be printed, don't go below 300 DPI.

Is splitting a large catalog bad for the user?

Usually yes. The user expects a single file, wants to search it, and wants to be done in one download. Splitting makes all of that harder. Splitting only makes sense if the parts of the file are genuinely independent (each year of an annual report, each category of a catalog) and most users only care about one part.

PDF Speed on the Web: Linearize, Compress, or Split?

Your site has a 60 MB product catalog and users are sitting there waiting for it to open. You have three tools: linearization (reorganizing the structure), compression (shrinking the file) and splitting (breaking it into parts). All three get described under the heading "speeding up a PDF," but they work through completely different mechanisms and deliver different amounts of gain.

The mechanism behind each

Compression shrinks the file itself. It re-encodes images at lower resolution, drops unused objects and recompresses streams. The amount of data to download goes down.

Linearization doesn't change the file size but reorders the objects: everything for the first page comes to the front, and a hint table is added saying where each page lives. That way the first page appears before the file has fully downloaded, and you can jump to any page.

Splitting breaks the file into multiple parts. The user downloads only the part they need.

Comparison table

| Criterion | Compression | Linearization | Splitting | |---|---|---|---| | Reduces file size | Yes, significantly | No (adds 1-2%) | Yes, per part | | Time until the first page appears | Improves proportionally | Improves dramatically | Improves | | Quality loss | Depends on setting | None | None | | Requires a server condition | No | Yes (byte-range) | No | | Hurts the user experience | If visual quality drops | No | Yes, they hunt for files | | Searchability | Preserved | Preserved | Fragmented | | Position in the workflow | 1st | 3rd (last) | 2nd |

Scenario 1: A 60 MB product catalog published on a site

Users open it in the browser and browse; most don't read the whole thing.

Winner ordering: compression → linearization.

Compress first. Product catalogs are full of high-resolution photos, usually prepared at 300 DPI — right for print, excessive for screen. Dropping to 150 DPI can shrink the file to a third and the difference on screen is nearly invisible. 60 MB becomes 20 MB.

Then linearize. Now the 20 MB file's first page appears after just a few hundred kilobytes have arrived. The user starts browsing while the file keeps downloading in the background.

Splitting is a bad idea in this scenario: the user wants to browse the catalog, and telling them "pages 40-80 are in a separate file" breaks the experience.

Scenario 2: A 500-page technical manual

Users come to look at a specific section, not to read the whole thing.

Winner: linearization, by a wide margin.

This is precisely the scenario linearization was designed for. Thanks to the hint tables, when a user jumps to page 347 the browser requests only that page's byte range — without downloading the 346 pages in between.

Compression helps too, but technical manuals are usually text-heavy and there isn't much to gain from compression. Most of the images are drawings and diagrams; degrading those hurts legibility.

Splitting looks tempting here (a separate file per chapter) but it fragments searchability. When a user searches for a term, they don't know which file it's in.

Scenario 3: An archive of monthly reports, 3 MB each

Dozens of separate files; users pick one and download it.

Winner: none of them is necessary, but compression does no harm.

A 3 MB file downloads in a few seconds on a reasonable connection. Linearization's gain here is too small to measure and it adds a needless step to your workflow.

Compression may still make sense — especially if the reports were converted from Word to PDF and the charts inside are at needlessly high resolution. But it isn't a priority.

Splitting has already been done (a separate file per month), and that's the right structure.

Scenario 4: A 200 MB scanned archive document

Old paperwork digitized by an institution, reviewed in the browser.

Winner: compression, then linearization — but question the scan settings first.

200 MB usually indicates the scan was done at needlessly high resolution or in color. For a plain-text archive document, 300 DPI grayscale is more than enough and shrinks the file noticeably. Black-and-white documents scanned in color are a classic source of waste.

Linearize after compressing. In scanned documents each page is a large image, so the gain from page jumping is especially pronounced.

Splitting is also defensible in this scenario: archive documents usually consist of independent units and users hunt for a specific record. But then you need to provide a good index page or a search interface.

Scenario 5: Users download the file and open it locally

The site offers a "Download" link and nobody reads it in the browser.

Winner: compression only.

Linearization's entire benefit is showing the first page while the file is still downloading. If the user downloads the file and opens it locally, the whole file is already on their computer; the ordering doesn't matter at all.

In this scenario the only meaningful optimization is reducing file size — that shortens download time and lowers your bandwidth cost.

How far to go with compression

Since compression wins in every scenario, let's look at its settings a little more closely. The question that determines image resolution: how will this file be used?

| Use | Recommended image DPI | Note | |---|---|---| | Screen reading only | 96-150 | The most aggressive gain | | Screen plus occasional printing | 150-200 | A safe middle ground | | A document that will be printed | 300 | Don't go below | | Commercial printing | 300+ | Don't compress |

Also, the lossless part of compression should always be done: dropping unused objects, subsetting embedded fonts to the characters actually used, recompressing streams. These deliver 10-30% on most files with zero quality loss.

The right order and why it matters

If you're doing all three, the order is:

1. Compress. The biggest gain is here, and since the other operations rewrite the file, this has to come first.

2. Split if needed. If you split from the compressed file, every part comes out compressed too.

3. Linearize. Last. Because every operation that rewrites the file undoes linearization.

Done in the reverse order, your effort is wasted: if you linearize and then compress, the compression rewrites the file and the linearized structure is lost.

The forgotten fourth factor: the server side

Independent of the three PDF operations, server configuration also affects speed and sometimes makes a bigger difference:

Byte-range support has to be on. Without it, linearization does nothing.
Don't apply gzip to PDFs. PDFs are already internally compressed; gzip gains nothing and breaks byte-range.
Set cache headers. For a catalog that doesn't change, a long Cache-Control lifetime eliminates the download entirely on return visits.
Use a CDN. Geographic distance is a significant share of the latency on large files.

These settings sometimes deliver more than file optimization does, and they cost you no quality at all.

Decision summary

Always do: compression. Reliable, unconditional, a win in every scenario.

Do on large files read in the browser: linearization. But verify your server supports byte-range, and make it the last step of the workflow.

Rarely do: splitting. Only if the parts are genuinely independent and most users care about a single part. Its cost is high because it fragments searchability.

Don't forget: server configuration is part of this list, and you'll usually find the cheapest gain there.