When publishing a site that claims to be lightweight, relying entirely on the browser cache may not be ideal if users are expected to open the HTML site repeatedly.
Because caching is not fully controlled by the site itself, the actual amount of data transferred may be higher than the developer expects.
As a mechanism that can be controlled by the site, I created a system that saves the main HTML document to IndexedDB on the first visit and restores it from IndexedDB on subsequent visits.
The browser cache can still provide its usual benefits.
For a practical implementation, I recommend providing both a regular version and a version designed to reduce traffic on subsequent visits. Most users can use the regular version, while frequent users can be guided to the traffic-reduction version.
Here is a working sample:
https://uni928.github.io/Uni928PublicHTMLs/index80English3B.html
I created this by taking https://uni928.github.io/Uni928PublicHTMLs/index80English3.html, making a few minor adjustments, and then applying the process I am introducing here.
Here is the tool for creating this type of site:
https://uni928.github.io/Uni928PublicHTMLs2/index23MakingEnglish.html
How it works
The structure consists of two files. The index portion can be replaced with any filename.
index.html
indexBody.html
The general flow is as follows:
Open index.html
↓
Check IndexedDB
↓
If saved, restore the HTML from IndexedDB
↓
If not saved, navigate to indexBody.html
↓
Save the main HTML document to IndexedDB
↓
Return to index.html
In other words, the large main HTML document is normally loaded only on the first visit.
On subsequent visits, the browser loads a lightweight restoration page and displays the main site from IndexedDB stored in the browser.
A tool for creating the files
The tool can convert a regular HTML file to this format. Simply drag and drop an HTML file, enter the desired filename, and download the result.
The tool generates these two files in a ZIP archive:
chosen-name.html
chosen-nameBody.html
The generated files use the name you specify in place of chosen-name.
Important considerations
IndexedDB is managed per origin, so the two files should generally be hosted on the same domain.
Even when the main HTML document is restored from IndexedDB, requests for external images, CSS, JavaScript, and other resources will still occur separately.
For this reason, the approach appears particularly suitable for:
- Sites that are close to a single-HTML structure
- Sites with a relatively large HTML document
- Use cases where the same page is opened repeatedly
Summary
This approach reduces repeated transfers of the main HTML document by fetching it only on the first visit and restoring it from IndexedDB thereafter.
Service Workers can also be used for similar purposes. This implementation uses a relatively simple two-file plus IndexedDB structure.
Top comments (0)