A shopper opens several product galleries, changes filters, compares variants, and finally opens the cart. Your performance report contains the first group of requests but almost nothing from the later interactions. The store may still be making those requests. The collection method may have stopped retaining the evidence you expected to inspect.
EcomToolkit’s approach is to verify measurement coverage before interpreting an apparent improvement. This guide focuses on Resource Timing collection inside one browser document, including long sessions in headless storefronts. The diagnostic examples are hypothetical. They describe tests an engineering team can reproduce, rather than results observed on a named merchant or platform.
Table of Contents
- Understand which buffer you are reading
- Separate timeline retention from observer delivery
- Build a controlled late-request experiment
- Give retention and clearing one owner
- Preserve useful detail without storing raw shopping data
- Turn the result into a release check
- EcomToolkit point of view
Understand which buffer you are reading
The browser’s resource timeline is a bounded store of performance entries. MDN documents that the initial capacity must be at least 250 entries and that setResourceTimingBufferSize changes the desired capacity. A late call to getEntriesByType("resource") reads retained entries; it is not a complete network archive.
That distinction matters when monitoring code waits until checkout or page exit before taking one snapshot. An image-heavy browsing session may generate many more entries than a short landing-page visit. If retention fills during discovery, later timing evidence can be absent even though those later requests succeeded.
A navigation to a new document changes the scope of the investigation. Do not add request counts from several full-page navigations and compare them with one document’s timeline. Begin by recording the document boundary and the collector’s start time, then reproduce the journey within that boundary.
Separate timeline retention from observer delivery
A PerformanceObserver receives entries through a different delivery mechanism from a one-time timeline snapshot. The observe method supports requesting retained entries with buffered: true when using the type option. It cannot recover historical entries that are no longer available. Registering a resource observer early is therefore different from starting one after a long session.
Do not assume a full resource timeline means an already-running observer necessarily missed the same entries. Test the paths separately. An observer can also encounter delivery constraints, while your own array, batching logic, and transport can lose data independently. The Resource Timing specification is the reference for browser processing, rather than a guarantee that an application collector is complete.
For a controlled investigation, collect a timeline snapshot and observer counts side by side. Give each record a document identifier and collector version. Compare against a known set of eligible resource requests in a browser network trace. Avoid counting navigation entries or blocked requests as if every network row must produce an equivalent resource entry.
| Observation | Likely question | Evidence to collect |
|---|---|---|
| Late timeline snapshot stops growing | Did retention reach capacity? | Buffer configuration and full event |
| Observer has more records than snapshot | Are collection paths being confused? | Observer start time and delivery counts |
| Local records exceed server records | Is transport dropping batches? | Batch acknowledgements and retry state |
| Specific timing fields are zero | Are cross-origin details restricted? | Origin and timing permission headers |
| Counts reset during navigation | Did the document change? | Document identifier and navigation type |
Build a controlled late-request experiment
Create a staging journey that loads a known sequence of same-origin test resources without modifying commerce data. Assign the resources a predictable order and ensure caching behavior is understood. Record the observer early, take snapshots at intervals, and note when the buffer-full event fires. Then repeat with a deliberately larger retention limit.
Use a small test endpoint or static fixtures rather than generating hundreds of calls to production pricing or inventory APIs. The goal is to exercise instrumentation, not create artificial load on a merchant’s operational systems. Keep the number of resources and their response behavior stable between runs.
Suppose the fixture generates 400 eligible resource entries, and a late snapshot contains only the first 250. That is 62.5% snapshot coverage for this fixture. It is not proof that 37.5% of every real shopper’s requests are missing. It also says nothing about an observer’s completeness unless you measured that independently.
| Illustrative fixture result | Count | Interpretation |
|---|---|---|
| Eligible resources deliberately requested | 400 | Controlled denominator |
| Entries in the late snapshot | 250 | 62.5% snapshot coverage |
| Entries absent from that snapshot | 150 | Investigate retention boundary |
| Entries recorded by early observer | 400 | Separate collection path succeeded in this example |
| Records accepted by telemetry endpoint | 380 | Transport retained 95% of observer records |
The example exposes two different losses. Increasing the timeline buffer could improve the snapshot without fixing the 20 records lost after observation. Report each stage explicitly so a collector change cannot hide a transport problem behind a larger local count.
Give retention and clearing one owner
A larger buffer can help a diagnostic, but unlimited retention is not a production strategy. Decide how much detail the team needs for an investigation and how long local records remain useful. A collector that retains full URLs and every request indefinitely creates memory and data-management costs of its own.
Listen for the resourcetimingbufferfull event to detect the retention boundary. If the implementation clears resource timings, coordinate that operation with other monitoring libraries. A shared browser timeline may be read by more than one integration, and one script’s cleanup can remove another script’s expected evidence.
Copy the required fields into a bounded application queue before clearing anything your collector still needs. Define how the queue handles overflow and unsuccessful uploads. If it discards records, increment a counter with a documented meaning. Silent dropping creates an attractive chart at the expense of trustworthy coverage.
The appropriate buffer limit depends on actual route behavior, device constraints, and sampling. Start with measured entry counts from representative journeys and review the upper tail. A fixed large number chosen without evidence may work in a short test while adding avoidable overhead to every visit.
Preserve useful detail without storing raw shopping data
Resource URLs can include search queries, product selections, and identifiers. An analysis usually needs a normalized route or resource class rather than the entire query string. Design the collection schema around the question: image delivery, search response, cart retrieval, or script loading.
Keep timing availability separate from timing value. A missing field should not become zero milliseconds in a dashboard. Cross-origin visibility restrictions can limit detailed measurements even when an entry exists. Treat that as an observability boundary and consult the relevant response policy before diagnosing a zero as a fast request.
The RUM sampling guide addresses who appears in your monitoring population. Buffer diagnostics address what survives within a collected journey. Both matter, but correcting one does not establish that the other is reliable.
Use a stable classification for dropped batches, unsupported entry types, and deliberate sampling. Preserve enough release context to identify when a collector change began. When the schema changes, compare coverage before comparing latency, because the new implementation may simply observe a different subset of requests.
Turn the result into a release check
Write an acceptance test around the original failure: after the defined long browsing sequence, the collector should retain or transmit the expected diagnostic records within its documented sampling policy. Repeat under delayed uploads and with a second monitoring integration enabled. Confirm that cleanup does not interfere with the shopping interface.
Review the collection cost on a representative mobile device. A performance tool should not create substantial parsing, memory, or network work that competes with the cart. Batch compact records and measure the collector’s own requests separately, so monitoring traffic does not recursively inflate the resource statistics being reported.
For a release comparison, show eligible journeys, observed entries, deliberately sampled entries, and unexplained losses beside the timing distribution. A fall in measured request duration is persuasive only when the population remains comparable. The performance observability framework provides the wider commercial context.
EcomToolkit point of view
A performance dashboard earns trust when it explains its blind spots. Before optimizing a dependency that appears slow, verify that faster and later requests had a fair chance to enter the report. If the collection chain is unclear, request an audit of storefront measurement coverage and make that chain the first deliverable.
