It has been one of the “little secrets” of Acrobat since version 4, that loading a fillable form under the browser can take quite a long time, or that all of a sudden the form does not react for some time.
The reason for this behavior is that the document has been saved with “Optimizing for Fast Web View” on.
But shouldn’t that make the form faster on the web?
Normally, with “regular”, long, text-heavy documents, this is indeed true. The reason for this behavior is in the “byteserving protocol”, used when an optimized for fast web view document is called from the web server.
When saving a document optimized for fast web view, a few things happen. First, the internal structure of the document is cleaned up. Unused objects and their references in the xref table are discarded (that happens whenever we do a Save as...). Then, the internal structure of the document is rewritten again, so that the xref table comes first, and then all the objects which are either document overhead, or commonly used, such as fonts. Then the the contents of the pages follows, page per page.
When the document gets opened under the browser, the first page gets loaded, and then, when the user requests another page (via navigation elements or via bookmarks or via internal links), the requested page gets transmitted, but nothing else.
Viewing a “normal” document in the browser
In order to accomplish that, the server uses the already mentioned byteserving protocol. This protocol allows to transfer selected objects from the PDF document. Roughly, the following happens with every object requested from the server:
The viewer component (Acrobat) needs the object number xyz. It sends a request to the browser plug-in/Active-X component which handles the communication between the viewer and the server.
The browser plug-in opens a channel to the server.
After the handshake procedure, the browser plug-in requests the object xyz.
The server sends the object xyz chopped up in blocks.
The browser plug-in confirms the receipt of the blocks and assembles them to the object xyz.
When all blocks are transferred, the browser plug-in passes the object xyz to the viewer.
The browser plug-in sends a last confirmation to the server, and closes the channel.
These steps happen for each and every object requested from the viewer component. The browser can have typically up to 8 channels open at the same time.
A page of a “normal” longer document consists maybe of half a dozen objects (mainly contents streams). These objects can be transferred more or less parallel at the same time. This means that the page will be transferred quite fast.
Viewing a form in the browser
When the document is a fillable form, the situation is quite a bit different. A look at the PDF in a text editor reveals that a single text field may consist of a dozen object, and if it has additional values set, such as a maximum number of characters, it can be even more.
So, for transferring just a single text field, that transfer procedure has to be repeated a dozen times. The “payload” is small, but opening and closing a channel takes its time. Now, imagine how many times that has to be repeated if the form has some 150 fields on a page (which is not uncommon for a typical business form).
There have been comparisons between the optimized for fast web view and the non-optimized version of the same form. In order to make the network delays negligible, the form was called from localhost (a web-server running on the same machine as the viewer). The results were dramatic. The optimized for fast web view version took about a good minute to load. The non-optimized version was ready after 3 seconds…
What does that mean for us?
The conclusion of these experiments is clear. A form, particularly when it has more than one page, should never be saved “optimized for fast web view”.
If we work primarily with forms, the best thing is to deactivate this option in the preferences. This is in the Preferences dialog, General tab, deselect the “Save As optimizes for Fast Web View”.
Otherwise, the simple workaround is to do the Save as..., and then make a little modification (filling out a field and undoing it should already do it), and then save it with Save.
It would be nice to have the option to select whether to save with or without optimization in the file save dialog. In fact, that was the case until Acrobat 4…