Si solo pudiera hacer una cosa, ¿cuál elijo?

Elige la compresión. Reducir a la mitad el tamaño del archivo reduce a la mitad el tiempo de descarga, y eso funciona en cualquier condición, en cualquier servidor y en cualquier navegador. El beneficio de la linealización, en cambio, depende de las condiciones: el servidor tiene que admitir peticiones byte-range y el usuario tiene que abrir el archivo en el navegador. La compresión da una ganancia más fiable.

¿Tiene algún inconveniente hacer las tres cosas?

Técnicamente no, pero el orden importa. Comprime primero, divide después si hace falta y lineariza al final. Si lo haces al revés, cada operación estropea el resultado de la anterior; la linealización, en particular, se pierde con cualquier operación que reescriba el archivo. Además, como la división complica la experiencia de usuario, no debería hacerse salvo que sea realmente necesaria.

¿Cuánto baja la calidad la compresión?

Depende del ajuste. Una operación que solo recomprime los flujos y descarta los objetos sin usar no provoca pérdida de calidad, pero su ganancia es limitada. La ganancia de verdad viene de recodificar las imágenes a menor resolución, y eso sí es una pérdida visible. Para un documento que se va a leer en pantalla, 150 PPP suele bastar; si se va a imprimir, no conviene bajar de 300 PPP.

¿Dividir un catálogo grande es malo para el usuario?

Normalmente sí. El usuario espera un único archivo, quiere poder buscar y quiere terminar con una sola descarga. Dividir complica todo eso. La división solo tiene sentido si las partes del archivo son realmente independientes (cada año de un informe anual, cada categoría de un catálogo) y si la mayoría de los usuarios solo se interesa por una parte.

Velocidad del PDF en la web: ¿linealizar, comprimir o dividir?

Tienes en tu web un catálogo de productos de 60 MB y los usuarios esperan a que se abra. Dispones de tres herramientas: linealización (reordenar la estructura), compresión (reducir el archivo) y división (partirlo en trozos). Las tres se presentan bajo el título de "acelerar el PDF", pero funcionan con mecanismos completamente distintos y aportan cantidades diferentes.

El mecanismo de cada una

La compresión reduce el archivo en sí. Recodifica las imágenes a menor resolución, descarta los objetos sin usar y recomprime los flujos. La cantidad de datos que hay que descargar disminuye.

La linealización no cambia el tamaño del archivo, pero reordena los objetos: todo lo de la primera página pasa al principio y se añade una tabla de pistas que indica dónde está cada página. Así, la primera página se ve sin que el archivo haya bajado del todo y se puede saltar a la página que se quiera.

La división parte el archivo en varios trozos. El usuario descarga solo la parte que necesita.

Tabla comparativa

| Criterio | Compresión | Linealización | División | |---|---|---|---| | Reduce el tamaño del archivo | Sí, de forma notable | No (lo aumenta un 1-2 %) | Sí, por trozo | | Tiempo hasta ver la primera página | Mejora proporcionalmente | Mejora de forma dramática | Mejora | | Pérdida de calidad | Según el ajuste | Ninguna | Ninguna | | ¿Exige algo del servidor? | No | Sí (byte-range) | No | | ¿Empeora la experiencia de usuario? | Si baja la calidad visual | No | Sí, hay que buscar el archivo | | Capacidad de búsqueda | Se conserva | Se conserva | Se fragmenta | | Posición en el flujo de trabajo | 1.ª | 3.ª (la última) | 2.ª |

Escenario 1: catálogo de productos de 60 MB publicado en la web

Los usuarios lo abren en el navegador y lo hojean; la mayoría no lo lee entero.

Orden ganador: compresión → linealización.

Comprime primero. Los catálogos de producto están llenos de fotos de alta resolución preparadas normalmente a 300 PPP: correcto para imprenta, excesivo para pantalla. Bajarlas a 150 PPP puede dejar el archivo en un tercio y la diferencia en pantalla es casi invisible. De 60 MB pasa a 20 MB.

Después lineariza. Ahora la primera página del archivo de 20 MB se ve tras descargar unos pocos cientos de kilobytes. El usuario empieza a hojear mientras el archivo sigue bajando en segundo plano.

Dividir es mala idea en este escenario: el usuario quiere navegar por el catálogo, y decirle que "las páginas 40 a 80 están en otro archivo" empeora la experiencia.

Escenario 2: manual técnico de 500 páginas

Los usuarios entran para consultar una sección concreta, no lo leen entero.

Ganador: linealización, con diferencia.

Este es justo el escenario para el que se diseñó la linealización. Gracias a las tablas de pistas, cuando el usuario salta a la página 347 el navegador pide solo el rango de bytes de esa página, sin descargar las 346 anteriores.

La compresión también ayuda, pero los manuales técnicos suelen ser de mucho texto y la compresión no aporta demasiado. La mayoría de las imágenes son dibujos y esquemas; degradarlos estropea la legibilidad.

Dividir parece atractivo aquí (una sección por archivo), pero fragmenta la capacidad de búsqueda. Cuando el usuario busca un término, no sabe en qué archivo está.

Escenario 3: archivo de informes mensuales de 3 MB cada uno

Decenas de archivos independientes; los usuarios eligen uno y lo descargan.

Ganador: no hace falta ninguna, pero comprimir no hace daño.

Un archivo de 3 MB baja en unos segundos con una conexión razonable. La ganancia de la linealización es aquí demasiado pequeña para medirse y añade un paso innecesario a tu flujo de trabajo.

La compresión puede tener sentido de todos modos, sobre todo si los informes se convirtieron de Word a PDF y sus gráficos están a una resolución innecesariamente alta. Pero no es la prioridad.

La división ya está hecha (cada mes en un archivo) y esa estructura es la correcta.

Escenario 4: documento de archivo escaneado de 200 MB

Documentación antigua digitalizada por una organización y consultada en el navegador.

Ganador: compresión y después linealización, pero antes cuestiona los ajustes del escaneo.

200 MB suele indicar que el escaneo se hizo a una resolución innecesariamente alta o en color. Para un documento de archivo de texto plano, 300 PPP en escala de grises es de sobra suficiente y reduce el archivo de forma notable. Escanear en color documentos que son en blanco y negro es una fuente clásica de desperdicio.

Después de comprimir, lineariza. Como en los documentos escaneados cada página es una imagen grande, la ganancia al saltar de página es especialmente evidente.

En este escenario la división también es defendible: los documentos de archivo suelen constar de unidades independientes y el usuario busca un expediente concreto. Pero entonces tendrás que ofrecer una buena página de índice o una interfaz de búsqueda.

Escenario 5: los usuarios descargan el archivo y lo abren en local

El sitio ofrece un enlace de "Descargar" y nadie lee en el navegador.

Ganador: solo la compresión.

Todo el beneficio de la linealización está en poder mostrar la primera página mientras el archivo baja. Si el usuario descarga el archivo y lo abre en local, el archivo ya está entero en su ordenador; el orden pierde toda importancia.

En este escenario, la única optimización con sentido es reducir el tamaño del archivo, lo que acorta el tiempo de descarga y reduce tu coste de ancho de banda.

Hasta dónde llegar con la compresión

Como la compresión es la ganadora en todos los escenarios, miremos el ajuste un poco más de cerca. La pregunta que determina la resolución de las imágenes: ¿cómo se va a usar este archivo?

| Uso | PPP recomendado para las imágenes | Nota | |---|---|---| | Solo lectura en pantalla | 96-150 | La ganancia más agresiva | | Pantalla + impresión ocasional | 150-200 | Término medio seguro | | Documento que se va a imprimir | 300 | No bajes de ahí | | Imprenta | 300+ | No lo comprimas |

Además, la parte sin pérdidas de la compresión debería aplicarse siempre: descartar los objetos sin usar, limitar las tipografías incrustadas a los caracteres realmente usados y recomprimir los flujos. Eso aporta entre un 10 y un 30 % en la mayoría de archivos sin ninguna pérdida de calidad.

El orden correcto y por qué importa

Si vas a hacer las tres cosas, el orden es este:

1. Comprime. Aquí está la mayor ganancia y, como las demás operaciones reescriben el archivo, debe ir primero.

2. Divide si hace falta. Si divides a partir del archivo ya comprimido, cada trozo estará también comprimido.

3. Lineariza. Al final. Porque cualquier operación que reescriba el archivo destruye la linealización.

Si lo haces al revés, tu esfuerzo se pierde: si linearizas y después comprimes, la compresión reescribe el archivo y la estructura linealizada desaparece.

El cuarto factor olvidado: el lado del servidor

Al margen de las tres operaciones sobre el PDF, la configuración del servidor también afecta a la velocidad y a veces marca una diferencia mayor:

El soporte de byte-range debe estar activado. Sin él, la linealización no sirve de nada.
No apliques gzip a los PDF. Los PDF ya vienen comprimidos por dentro; el gzip no aporta ganancia y rompe el byte-range.
Configura las cabeceras de caché. Para un catálogo que no cambia, un Cache-Control largo elimina por completo la descarga en las visitas repetidas.
Usa una CDN. La distancia geográfica es una parte importante de la latencia en archivos grandes.

Estos ajustes a veces aportan más que la optimización del archivo y no exigen ninguna concesión en calidad.

Resumen de la decisión

Hazlo siempre: comprimir. Es fiable, incondicional y aporta en todos los escenarios.

Hazlo en archivos grandes que se leen en el navegador: linealizar. Pero confirma que tu servidor admite byte-range y déjalo como último paso del flujo de trabajo.

Hazlo pocas veces: dividir. Solo si las partes son realmente independientes y la mayoría de los usuarios se interesa por una sola. Su precio es alto porque fragmenta la capacidad de búsqueda.

No olvides: la configuración del servidor también forma parte de esta lista, y ahí suele estar la ganancia más barata.