Reducing live documents can still leave memory growing elsewhere if prepared reading data accumulates forever. I bounded automatic preparation by entry count, total bytes, individual size and idle age. After the earlier account of reference lifetime, this chapter focuses on how much retained cache remains.

Four tabs alone do not define a size bound

PagePreparation defaults to four entries, four MiB total, one MiB per entry and five minutes idle age. A large document can exceed several small ones, so count alone is insufficient. The implementation counts UTF-8 bytes of the serialized view, not characters as though they had uniform size.

This measures the retained cache representation, not all Electron memory or every internal object. Browser processes, renderers and other driver data remain separate. Removing a number of serialized bytes does not establish an equal reduction in RAM. I retain cache limits and process measurement as different forms of evidence rather than making one stand in for the other.

A recently read entry refreshes its idle lifetime

Prune expires entries by touched age and evicts least recently used data when count or total bytes exceed limits. A valid peek and unchanged prepared-content reuse refresh touched. This differs from deleting an entry at a fixed age after creation regardless of use; the policy follows idle lifetime.

The unit fixture inserts a and b, rereads a, then inserts c and checks that b is removed. A later explicit prune time expires everything. The test makes survival reasons inspectable rather than simply saying time passed. The new synthetic module demonstrates the same relationship with caller-supplied time and saved function-call records.

Do not repeatedly retain an oversized automatic page

A view exceeding the per-entry or total limit is not stored; its existing entry is evicted. State explains that the large page should be read as needed and sets an automatic retry delay. That avoids repeatedly rebuilding and attempting to retain the same oversized result at every preparation cycle.

The policy does not make large pages unreadable. Automatic preparation and explicit reading have different conditions. Ensure's explicit option bypasses automatic eligibility and retry delay, but does not ignore basic dormant/loading state. The size limit is not bypassed by widening permissions or reloading the actual page. Storage policy and reading capability remain separate.

Do not let a late observation become another document cache

Prepare captures URL, documentEpoch and generation, then checks current state after asynchronous verification and observation. It compares the observed revision with the current revision too. A document changing during the wait must not receive the earlier result as its own cache. Pending also coalesces concurrent preparation for one tab.

Evict and remove invoke the related driver-context release callback; not every entries.delete is identical to that release path. Entry removal, asynchronous generation fencing and auxiliary-context cleanup are connected responsibilities with separate checks. They are also a different question from the action-reference boundary covered in the earlier cache article.

The shared cache is a smaller synchronous experiment

The synthetic package accepts title/text and exercises LRU, byte limits, TTL and context changes. It includes removing an old same-tab value when an oversized replacement is rejected. It does not reproduce the original structured view, asynchronous reading or frame-map cleanup in full.

I reviewed current functions and the original limit fixture, and separately tested synthetic source and extracted ZIP. No operational page was crawled or user tab refreshed. I share a form whose limits can be changed and inspected, preserving the judgment that even convenience reading data needs a reason to remain and an explicit condition for removal.