A credible website speed improvement report preserves the baseline, explains the change, and shows comparable evidence afterward. It does not select the worst old run and the best new run, hide failed measurements, or turn a single route's improvement into a claim about the entire application.
Performance measurements can vary with underlying conditions. That is why a repeatable method matters more than an impressive pair of screenshots. [1]
Decide the comparison before seeing the result
Write down the routes, device profile, test method, and review window before collecting the after-state. Choose a repeat-run policy and apply it consistently. You do not need a complex experiment to be honest, but you do need rules that are not rewritten after the numbers arrive.
Keep the baseline reports and release identifiers. If the site was already changing during the baseline period, say so. A clean comparison requires a reasonably clear definition of the old and new implementations.
Do not discard failures without explanation. A failed test can be a collection problem or a product problem. Either way, the record should preserve what happened and how the observation was handled.
Report the measured route, not the brand as a whole
Name the exact page or page group. A faster homepage does not establish that signup, pricing, documentation, and authenticated workflows all improved. Use a route-level statement unless the study actually covers the broader claim.
For a group of routes, explain the aggregation. Are you reporting the median across routes, repeated runs on one route, or real-user observations? These are different units of analysis. Do not combine them into one number without a reason.
A reader should be able to identify the object of measurement from the headline and opening paragraph, not discover the limitation only at the end.
Show absolute values alongside percentage changes
Percentage changes can exaggerate the practical importance of a small baseline. Include the original and new values, the units, and the calculation. A difference in score points should be described as score points rather than casually translated into a percentage increase in speed.
For an illustrative example, moving a timing measure from 2.0 seconds to 1.5 seconds is a reduction of 0.5 seconds, or 25% of the original duration. That example demonstrates the arithmetic; it is not an IndieTools result.
If the metric is a composite score, explain it as a score. Do not label a ten-point change as “ten percent faster” without a valid measurement model connecting the two.
Distinguish observation from explanation
You can observe that a route improved after a release. Claiming that one particular code change caused the improvement requires stronger evidence, especially when several changes shipped together.
Describe the intervention precisely. “We replaced the first-load video embed with an on-demand preview” is a concrete implementation statement. “We fixed SEO” is not. If the release included other changes, list the relevant ones and acknowledge the attribution limit.
A useful report can still be valuable without proving a single cause. It can document a reproducible outcome and explain which hypotheses deserve further testing.
Include the experience that the score cannot describe
Confirm that the page still works. Check the main call to action, content visibility, keyboard interaction, forms, and recovery from errors. A faster result achieved by removing essential functionality is a tradeoff, not an unqualified win.
For an AI or media product, explain whether the demonstration remains representative. A static example can be a sensible first view, but it should not be presented as a live workflow test.
This section makes the report useful to founders who care about the product, not only to readers collecting optimization tips.
Preserve a reproducible evidence package
A public summary can stay concise while an accompanying evidence record retains the full reports, collection dates, route list, and method version. Where a genuine dataset is published, describe its scope and access clearly; Google's Dataset documentation is about describing actual datasets, not decorating unsupported claims. [2]
For a blog article built around IndieTools, connect the product identity to the dated observation and explain what your own investigation added. A live leaderboard is context; a case study should contribute a method, a tested intervention, or a clearly bounded finding.
Avoid implying that a blog author personally performed tests that were only read from a public source. Attribute public observations and label your own experiments separately.
A concise report structure
Open with the measured outcome and its scope. Follow with the baseline, the change, the comparable result, and the functional checks. End with limitations and the next unresolved question. This sequence gives readers the answer without hiding the method.
The report should make it easy for another founder to ask whether the same intervention is relevant to their page. It should not promise that copying the change will reproduce the same result on a different stack or workload.
Questions about public case studies
Should unsuccessful changes be included?
Include them when they materially affect interpretation or help explain the final decision. A failed experiment can prevent readers from repeating an unhelpful approach.
Is a dramatic headline necessary?
No. A specific, checkable result is more useful than an oversized claim. Name the route, the metric, and the context so the reader knows exactly what improved.
Explore related IndieTools resources: weekly website speed measurements and product categories.
Continue your research
- Track Website Speed Week Over Week
- Publish Original SaaS Benchmarks Responsibly
- Build a Citation-Worthy SaaS Benchmark Dataset
Sources and verification
Sources consulted for this article on October 1, 2026. Product capabilities are documented claims unless an actual test is explicitly described.
