Un gros document dont la première page s'affiche tout de suite
Vous envoyez à un client un catalogue de quatre cents pages. Il clique sur le lien, et rien ne se passe pendant huit secondes. Il n'attend pas la page quatre cents — il voulait juste regarder la première. Un document peut être écrit de façon que la première page apparaisse presque tout de suite et que le reste continue d'arriver derrière. Mêmes pages, mêmes lettres, à peu près le même poids.
Ce qui se passe quand on clique sur un lien vers un PDF
Un fichier PDF est écrit à l'envers. Tout ce dont le document est fait vient d'abord, et l'index qui dit où se trouve chaque morceau vient en dernier, tout à la fin du fichier.
Sur un disque, c'est très bien : le logiciel de lecture saute à la fin, lit l'index, et va droit aux morceaux dont il a besoin. Au bout d'un fil, c'est autre chose. Pour lire un index qui est à la fin, il faut avoir reçu la fin. Pour recevoir la fin, il faut avoir reçu tout ce qui est avant. Alors la personne attend quatre cents pages pour en regarder une.
Écrit dans l'autre sens, le fichier commence par la première page, par tout ce dont la première page a besoin, et par un petit index qui dit où commence chacune des autres. Le logiciel de lecture dessine la première page et va chercher le reste pendant que la personne lit. On saute à la page cinquante et il demande la page cinquante toute seule, pas le livre entier.
Rien d'autre ne change. Le même document, les mêmes pages, et quelqu'un qui l'ouvre depuis sa propre machine ne voit aucune différence.
Le mot, pour ceux qui le cherchent
Ça s'appelle linéariser un PDF, et un fichier écrit comme ça est un PDF linéarisé — ou linearized, à l'américaine, qui est la forme sous laquelle vous le rencontrerez le plus souvent dans un cahier des charges. Certains logiciels de lecture appellent la même chose Affichage Web rapide, et l'affichent par oui ou par non dans les propriétés du document.
Si c'est la ligne que vous avez à cocher, voilà la coche : notre moteur écrit du PDF linéarisé, et c'est un interrupteur.
Détail — 43 007 octets au lieu de 519 301
Un seul document, deux cents pages d'un tableau numéroté, écrit deux fois : une fois à l'ordinaire, une fois première page en tête. Rien d'autre ne diffère entre les deux fichiers.
- 519 301 octets — doivent être arrivés avant que la première page puisse être dessinée, sur le fichier écrit à l'ordinaire — c'est-à-dire le fichier entier.
- 43 007 octets — sur le fichier écrit première page en tête.
- 476 294 octets — qui ne sont plus attendus.
Soit 8 % du fichier.
Les chiffres sont lus sur les deux fichiers eux-mêmes, pas tapés à la main. La feuille sur laquelle ils sont imprimés est un document que vous pouvez télécharger, et cette feuille est elle-même écrite première page en tête.
Quand ça ne change rien
Bon à savoir avant d'allumer l'interrupteur, parce que c'est la partie que personne ne vous dit. Le gain ne se sent que quand le document est lu pendant qu'il arrive, et il faut pour cela que deux choses soient vraies.
- Le serveur qui remet le fichier doit savoir en envoyer un morceau sur demande. La plupart le savent, sans rien régler. Un serveur qui n'envoie jamais que des fichiers entiers remet le fichier entier, et le logiciel de lecture attend comme avant.
- Le logiciel de lecture doit s'en servir. Ceux qui sont dans Chrome, Firefox et Edge le font. Adobe Acrobat Reader aussi. Quelques autres lisent le fichier à l'ordinaire — et n'y perdent rien du tout, puisque c'est le même document.
Et ça ne fait rien du tout dans les cas où personne n'attend : un fichier joint à un courriel, un fichier copié dans un dossier partagé, un fichier téléchargé en entier puis ouvert. Dans tous ces cas-là, le document est déjà arrivé avant que quiconque le regarde.
Donc : si vos documents s'ouvrent depuis un lien, ça vaut la peine de l'allumer et ça ne vous coûte rien. S'ils partent en pièce jointe, ça ne change rien et ça ne vous coûte rien non plus.
Techniquement
Linéarisation au sens de la norme ISO 32000, article 7.5.8 : section de références croisées de première page et dictionnaire de paramètres de linéarisation en tête de fichier, la page un et ses ressources juste après, puis les objets restants, puis la section de références croisées principale. Les tables d'indications — flux d'indications des objets partagés et flux d'indications des décalages de page — permettent de calculer la plage d'octets de n'importe quelle page et de la demander en une seule requête partielle.
Le chiffre ci-dessus est l'entrée /E du dictionnaire de paramètres, qui donne le décalage de la fin de la première page : tout ce qui est avant est ce qu'il faut tenir avant de dessiner. Un fichier écrit à l'ordinaire ne déclare rien de tel, donc la réponse pour lui est sa propre longueur. C'est pour cela que les deux nombres se comparent — une seule mesure, appliquée à deux écritures d'un même document.
À vérifier de votre côté : le serveur doit répondre Accept-Ranges: bytes et honorer les requêtes Range par un 206, sur la route exacte qui sert les documents — un serveur frontal placé devant, une compression appliquée à la volée ou un réseau de diffusion réglé pour transformer le corps ramèneront chacun, silencieusement, les requêtes partielles à des transferts complets. Les réponses encodées sont le coupable habituel : un PDF servi en Content-Encoding: gzip ne se demande pas utilement par plages, et un PDF est déjà comprimé à l'intérieur, donc le servir non comprimé est de toute façon le bon choix.
Ça se combine avec tout le reste : flux d'objets, balisage, conformité PDF/A et PDF/UA, chiffrement, signature. C'est écrit en dernier, par-dessus le document terminé, donc ça ne change jamais ce que les pages disent.
Où regarder ensuite
Le document qui a été mesuré, et son programme Ce qu'est un PDF linéarisé, dans le glossaire Changer la bibliothèque qui écrit vos documents Le moteur à l'intérieur de votre propre programme