Caching on the Web
In order to let your users experience a fast PDF viewer, the loading performance of assets — especially your PDF files — is critical. In this guide, you will learn how to make your assets load fast and how to cache them for a long time.
gzip and Brotli
All modern browsers support gzipped content. This allows your server to deliver a compressed version of your assets with a reduced file size. The browser will take care of uncompressing the assets as soon as it has received them.
Many web servers like Apache or Nginx can gzip responses automatically right before they get sent to the client. However, unless your assets are created dynamically for every request, an even smarter solution is to create gzipped versions of your assets when you deploy them.
Tools like webpack offer plugins to gzip your assets at build time. Once you deploy them, make sure your server sends the gzipped version of the file if the user’s browser supports it. In this case, the user’s browser will send the following header with the request:
Accept-encoding: gzip, deflate
An even better compression method for your assets is Brotli. Using Brotli, you can achieve a 20 percent decrease in file size in comparison to gzip. However, Brotli is not as well supported by browsers as gzip is. If a browser supports Brotli, it will include it in its
Accept-encoding: gzip, br
There is also a webpack plugin which compresses your assets with Brotli at build time.
Once your users have downloaded your assets, you should make sure they don’t have to download them again every time they need them. The easiest and most efficient way to do this is to tell the browser to cache your assets for a very long time and to give them a unique path that changes whenever the asset’s content changes.
In this way, the browser only needs to download an asset once and can serve further requests for the same assets from the browser cache. When an asset changes, tell the browser about the new path, for example by passing the new path in PSPDFKit’s
To tell the browser to keep your assets for a certain time without fetching them again, pass the following HTTP header along with the asset response:
This tells the browser to keep your asset in its cache for up to 100 days (100 _ 24 _ 60 * 60 = 8640000 seconds).
Inspecting Asset Loading in Your Browser’s Dev Tools
To check if your assets are delivered with the correct encoding and headers, you can use your browser’s dev tools. In this example, we’ll use Chrome’s dev tools, but you’ll find similar tools in every modern browser.
We can see above that the PDF was served with a
Cache-Control header, which prevents refetching when we access the same file again within one day.
Our browser also states that it supports gzip compression, but apparently our server can’t deliver a gzipped version; otherwise, there would be the response header
Content-Encoding: gzip. In order to improve loading performance of the PDF, we should configure the server to deliver a gzipped version.
Content Delivery Network
If you serve customers all around the world, you should consider using a Content Delivery Network (CDN). CDNs store your assets on several servers in different parts of the world. Your CDN will make sure your users always receive content from the closest available server. This will reduce latency and download speed, and it will take the load away from your production server, which will no longer have to serve the assets.
An additional benefit of CDNs is the high availability of your content: Should one server become unreachable, your content can still be delivered from another available server.
Typically, CDNs let you configure the caching headers your assets are delivered with, and you can also provide a gzipped version of your files, which gets served automatically if the user’s browser supports it.
For more information on how to set up caching with your CDN of choice, check out the following links: