Resources Transferred: Does PDF Embed API download the full file?

Report · Aug 30, 2020

I have several PDF files that I am linking to on a page, with embedded lightbox buttons to let users browse documents without needing to download them.

https://mdpl.org/2020/08/21/ocean-drive-master-plans/

However, when I check the Google Chrome Developer Tools->Network console, I see that there is around 97kb transferred, but after clicking the button to open the first PDF, as I scroll down the PDF, I see about 230MB+ of 'resources transferred' which goes up with each page I scroll (see attached screenshot).

My question is, when embedding large PDFs in the PDF embed API, is the entire file being downloaded for the user in the background before becoming a lightbox? It would seem inefficient to download the full file, only to display the PDF in the lightbox.

I believe it would be helpful to understand how much of the file is actually transferred when showing the lightbox.. in this example, is it only 97kb or 230MB+?

Report · Aug 31, 2020

Is the PDF optimized for "fast web view" (check properties in Acrobat or Reader). If not the file cannot be displayed without download it all. If so, the client can download the parts of the file in order to render it - but you seem to say you aren't expecting the file to download... I originally thought this was server-based rendering but I now understand it to be client based, so the client has little choice but to download the PDF, whether you are showing it big or small.

Report · Aug 31, 2020

Hi, I am referring to the PDF Embed API... I am not sure if your answer is referring to that, or something else like just clicking a file link. Please advise. I also mentioned in my original post that the amount of data transferred appears low... compared with the size of what is listed as Resources.

Report · Aug 31, 2020

The PDF Embed API is an API for displaying a PDF in your page. To do that, it's going to need to read the PDF. All of it or part of it, according to the "Optimized for web view" option. I'm not sure what else you would expect it to do, other than read the PDF to the client (all or part) and render it? Thumbnails may not be a viable use of bandwidth.

Report · Sep 01, 2020

I'm told that in the current implementation, Embed API retrieves the entire file before it will be displayed. Even if the PDF file has been optimized for fast web view, Embed API cannot do page at a time loading. I'm not sure how to account for the behavior you are seeing.

Report · Sep 02, 2020

Ah, so it is currently supposed to download the whole file. Definitely not a lightweight preview. Just a small view of the whole thing! (Disappointing not to support fast web view, it was invented more than 20 years ago!)

Report · Sep 02, 2020

It's not as straightforward as you'd think. The server needs to be configured to support Byte-Range requests which is generally the default for static content but if it's an application that is serving up the PDF like Dropbox or Google Drive, the request headers would also need to be configured to support it. If the server process requires authentication for each request and the number of requests per minute is throttled, you can see how byte serving a PDF can become problematic. It's not as simple as just putting some code in the client.