A smaller memory figure alone does not explain what changed. The historical browser comparison retained the same twenty saved tabs while changing how many documents loaded at startup. I reread the samples and measurement code and recalculated the figures, retaining those conditions as part of the result.
The list matched while the loaded document count differed
Independent version 0.1.61 and 0.1.62 fixture profiles used the same twenty local test URLs and starting selection. The new version displayed the whole list while loading one document, leaving nineteen renderer PIDs at zero. The table does not compare twenty fully active real websites on each side.
That condition explains what lazy loading changed; it is not an inconvenient detail to hide. Claiming the same reduction with every document simultaneously running would describe another experiment. Tab count, renderer count, starting selection and artifact type belong together so readers can compare the result with their own workload.
Private memory differs from a summed working set
Measure-memory reads an explicit parent PID and its descendants and aggregates USS, private commit and working set separately. The table's private RAM uses USS, a different measure from a working-set sum containing shared pages. The same MiB unit does not make their meanings interchangeable.
Process creation time helps check identity. A child that exits or denies access is skipped, so such a sample cannot automatically be called exhaustive. Saved samples retain twenty-five counted processes before and six afterward. Process counts and conditions matter alongside the aggregate. The measurement script does not terminate other programs or forcibly trim working sets to manufacture a lower number.
Take multiple samples after a stated stabilization period
The startup test waits fifteen seconds before invoking the measurement script, which records seven samples three seconds apart. I distinguish the script's own wait argument from stabilization performed by its caller, avoiding an accidental claim that the same delay occurred twice. The result does not select one transient low point.
Recalculated private-RAM means are about 562.75 MiB and 225.10 MiB; private-commit means are 864.60 MiB and 337.25 MiB. These are calculations over the existing seven samples, not fresh RAM measurements. Source hashes and recalculation are retained privately to compare with the rounded historical report.
Before/after figures from a user session answer another question
The historical report also contains before/after figures from actual use, but elapsed runtime, page state and operating-system pressure differ. I do not merge those with the controlled startup fixture to produce a fixed reduction rate. Preservation of login or drafts is another check, separate from attributing memory change to a specific cause.
This small startup experiment does not validate leaks, long-duration behavior or every site's video, WebSocket and WebRTC state. Reloaded documents also need an explicit account of temporary state that may be lost. I retain the observed resource change beside its unverified conditions rather than turning one low figure into a product-wide superiority claim.
A cache-limit test cannot replace process measurement
A decrease in the shared module's cached bytes concerns its serialized reading representation, not renderer RAM. The module closes no tab and measures no process memory. Numeric fields from different layers are not merged into a single test result merely because they all describe resource use.
This article reads code, historical results and saved samples and newly checks only arithmetic. It launches or terminates neither the original browser nor other user processes. An account of another improvement can retain comparable data, starting state, metric and sample count in the same way. Publishing conditions lets readers assess both the convenience and limits created by the maker's choice.