Pingsivo · 1504 words · Updated 7 October 2026
English editorial adaptation prepared with AI assistance. Hypothetical examples are labelled. Technical sources accompany the relevant explanations.
A waterfall places network requests on a shared timeline so you can investigate discovery, transfer duration and dependencies. Start with the page's purpose and critical content rather than automatically fixing the longest request. Pingsivo shows the network details available from Lighthouse; missing DNS, connection or TLS phases remain unavailable instead of being reconstructed from guesses.
Understand rows and the time reference
Each row describes an observed resource request. The start position and duration help show when it occurred relative to other requests. A resource beginning late is not necessarily slow to transfer; it may have been discovered late.
Check the measurement profile and method before comparing runs. Device settings, caching, redirects and page state can change what is observed. A waterfall is a record of an experiment, not a permanent blueprint of the site.
Chrome's Network reference explains deeper inspection options. Use it when the summary available in Pingsivo is insufficient for the question you are investigating.
Start with the page's objective
Identify what the visitor needs first: a product image, an article heading, a booking form or another main element. Then find the resources and work required to make that content visible and useful.
The largest or longest request may be unrelated to the first meaningful experience. A late analytics call deserves different priority from a resource blocking the main content. Explain the connection between the observed request and the user's task.
Read the LCP guide for the main content and the INP guide for interaction responsiveness. A network-only view cannot explain all rendering or interaction work.
Separate discovery delay from transfer time
If an image starts late but transfers quickly, reducing its bytes may not address the principal delay. Investigate what made the browser discover it late: document delivery, styles, script-driven insertion or another dependency.
If a resource starts early but takes a long time, examine the available transfer observations and destination. Do not infer a precise DNS or TLS duration from a total when those phases were not captured.
Use a hypothesis tied to evidence. “The main image is discovered after this script runs” is testable; “the hosting is slow” is too broad without further observations.
Inspect dependencies and other domains
Requests can form chains: one document or script reveals another resource. A small request may be important because later work depends on it. Look beyond byte size when prioritising.
Pingsivo's different-domain filter compares hostnames with the tested page. It is an inspection aid, not proof of legal ownership or a complete first-party/third-party classification. A site-owned CDN can use another hostname.
Do not remove every external resource automatically. Identify its purpose and effect, then test a controlled change. Some components are necessary for the service, while others can be deferred or removed safely.
Read sizes, status and caching carefully
Transfer size and decoded resource size describe different quantities. Compression and caching can affect what crosses the network. Keep units and field meanings visible when comparing resources.
HTTP status filters can reveal errors and redirects. A redirect is not automatically a defect, and an error may affect an optional resource rather than the main task. Investigate impact before choosing a correction.
A subsequent visit can produce a different waterfall because the browser's state changed. Record whether a comparison uses comparable cache conditions instead of treating every variation as a regression.
Prioritise a concrete correction
Consider a hypothetical page whose main image is discovered late and whose largest download is a nonessential asset. Optimising the largest asset first might improve total bytes without substantially changing the main-content milestone.
Change one relevant factor and repeat comparable tests. Keep the original report and inspect both the metric and the visual result. The performance-budget guide explains how to turn improvements into ongoing limits and responsibilities.
Avoid promises about a precise gain before testing. Timing fields reveal useful relationships, but competing resources and browser scheduling can make actual outcomes differ from a simple subtraction.
Export without exposing unnecessary information
Pingsivo offers the original Lighthouse report where available and a deliberately partial HAR derived from network-request summaries. The partial HAR removes URL query parameters and fragments, contains no response bodies or headers, and marks unavailable timing phases as unknown.
It is not equivalent to a full browser-captured HAR. Request methods can also be unavailable, and derived timestamps have a stated limitation. Use the original browser tooling when complete protocol detail is required.
Even cleaned URL paths may contain private information. Review the file before sharing it. Do not assume that removing query parameters makes every report safe for unrestricted publication.
Work from an observed resource to a verifiable change
Begin by selecting a representative page and documenting its state. A product page with a chosen variant, a signed-out article and a search result can produce different requests from their default versions. Record the device profile and whether the report is a fresh comparable run. Then identify the visible element or task that matters. This gives the waterfall a question to answer. Without that question, sorting by size or duration can become an attractive but arbitrary exercise that does not address the visitor's actual delay.
Suppose a hypothetical main image begins late even though its transfer duration is modest. Follow the available evidence about what precedes it. A script-driven insertion or a resource discovered through another file is a candidate relationship to investigate, not something that should be asserted merely from similar positions on a chart. Use the relevant browser tools where necessary to confirm the dependency. The intended correction should name the relationship it changes, such as making the required resource discoverable earlier, and the repeat test should check whether that change affects the main-content milestone.
Use filters to reduce the inspection set, but remember that hidden rows still exist. A script-only view can help find JavaScript requests, while an error filter can highlight unsuccessful HTTP statuses. Neither filtered view represents the whole loading process. Restore the full set before making a broad statement about page weight or dependencies. When sharing a screenshot of a filtered table, include the filter state and the number of rows shown so that another reader does not mistake the subset for a complete inventory of the page.
The different-hostname option also needs careful wording. A request to a separate hostname may belong to infrastructure controlled by the same organisation, while a same-hostname request can still involve complex backend dependencies. The filter identifies a URL relationship useful for inspection; it does not determine ownership, privacy compliance or business responsibility. Use it to ask why a resource is present and what it contributes. If the question requires organisational classification, that needs information beyond the waterfall's hostname comparison.
For a partial HAR export, inspect the explanatory comments before using it in another tool. The export preserves available request-level observations and intentionally does not invent absent headers, methods or phase timings. A downstream viewer may display unknown fields awkwardly or expect a fuller capture. That does not justify replacing unknown durations with plausible-looking numbers. If a workflow needs complete network timing or header inspection, collect an appropriate browser capture with the necessary permissions and review its potentially sensitive contents before sharing it.
After a correction, compare more than one dimension. A reduced transfer size can be worthwhile even if it does not move the main-content timing much, while earlier discovery might improve the visible experience without changing total bytes. Describe the observed outcome rather than declaring every metric a success. Check the actual page content and interactions as well, because removing or deferring a request can break functionality even when a score improves. A performance change should be both technically effective and compatible with the user's intended task.
Keep a short record containing the original question, relevant rows, hypothesis, code or content change, repeated measurements and visual verification. This makes the result reviewable by another maintainer and provides a reference if the problem returns. A waterfall is most valuable when it supports this sequence of reasoning. It is less useful when treated as a decorative chart or as a source of precise causal claims that its available fields cannot independently establish.
FAQ: avoiding waterfall mistakes
Should I fix the longest request first?
Not automatically. Determine whether it affects the user's critical content or interaction. A shorter dependency can be more important than a long optional request.
Can a small image delay the main content?
Yes, if discovery or dependency timing is the issue. Size alone does not explain when a resource becomes available or is rendered.
Why do two visits produce different waterfalls?
Cache state, page content, redirects, device conditions and remote responses can change. Document comparable conditions before interpreting the difference.
Does Pingsivo replace Chrome DevTools?
No. It presents available Lighthouse observations in a simpler report. Use DevTools for detailed request and protocol investigation beyond those fields.
Can I publish the complete report freely?
Review it first. Resource URLs, paths, screenshots and other details may reveal sensitive information. Share only what is needed for the intended investigation.