Tracking website speed over time means following comparable observations, not collecting unrelated screenshots. A weekly chart becomes useful when you can connect a movement to a release, a changed test condition, or a different group of pages. Without that context, the chart may create concern without telling you what to fix.
IndieTools Speed exposes current and archived weekly views. Those views can support discovery and historical context, while a founder's own release log explains what changed on the website. [1]
Choose stable objects to follow
Track the exact page or a clearly defined page role. A product can change its homepage path, redirect to a new domain, or move documentation to a separate host. Keep an identity record that distinguishes the product from the tested URL.
For your own site, begin with the routes that represent acquisition and activation: homepage, pricing, signup, and a representative first-use page. Keep their histories separate. Averaging them together can hide a slow signup journey behind an excellent homepage result.
When a route is replaced, record the transition. Do not silently join two different page types into one uninterrupted series and describe the result as a simple performance trend.
Keep the test conditions in the dataset
Store device profile, test method, collection time, and the measurement configuration available to you. A change in test conditions can create a discontinuity that resembles a product regression. Lighthouse documentation notes that underlying conditions can affect repeated measurements. [2]
A minimal weekly record should include the route, release identifier, score, underlying timing values, result status, and a short note. Preserve failed runs as failures. Removing inconvenient observations after seeing the result makes the record less trustworthy.
A weekly cadence is a reporting choice, not a promise that important regressions only happen weekly. Critical release checks can run more frequently while the public summary remains weekly.
Use paired comparisons for cohort claims
For a single website, compare the same route across periods. For a directory-wide statement, first identify products with valid, comparable measurements in both periods. This paired group answers a different question from the full current board.
Consider an illustrative example: this week includes many newly added fast websites. The current average improves, but the returning websites are unchanged. That is a change in the composition of the board, not evidence that existing products became faster.
Report both views when useful: the current cohort describes what is present now; the paired cohort describes change among continuing participants. Keep the sample counts attached to both.
Annotate releases instead of guessing causes
A release annotation should describe a concrete event: new hero video, updated consent manager, changed hosting region, redesigned pricing page, or framework upgrade. Do not write “SEO improved” when the observation only concerns a page metric.
After a significant movement, inspect the report and compare the relevant resource or processing stage. The release log narrows the investigation, but timing alone does not establish causation. A deployment and a slower result can occur together for reasons unrelated to the code change.
Use a retest or a controlled rollback where appropriate and safe. Keep security changes and essential functionality intact; do not reverse them merely to recover an attractive score.
Distinguish imported history from native history
When a website-performance product is migrated or two datasets are combined, the earlier records may use a different collection method. Preserve a source label and a method version. Historical continuity is useful, but it should not imply identical measurement conditions when those conditions are unknown.
A public chart can display a visible boundary where the source changes. A report can explain that earlier values provide context while precise before-and-after claims begin with the comparable period. This is more credible than smoothing over the boundary.
For an IndieTools-based article, use the archive to identify the period, then explain whether the comparison is same-method, same-URL, and same-device. Do not claim a long-term improvement merely because an imported record is numerically different.
Write a weekly report that leads to action
A useful report answers what changed, who was affected, how confident the observation is, and what happens next. Keep a short investigation queue rather than an exhaustive dump of every metric.
For example: “The pricing route slowed after the calculator release; the homepage remained stable; inspect calculator initialization and repeat the mobile test.” That is an actionable statement. “Performance is down” is not.
Maintain the raw evidence separately from the narrative. The narrative should make the decision clear; the evidence should let another person verify the reasoning.
Questions about performance history
Can a weekly rank fall while the site gets faster?
Yes. Rank depends on the other participants as well as your own measurements. Review the raw values and the composition of the board before interpreting the movement.
Should old results be deleted after a redesign?
Usually preserve them with a clear version boundary. They remain useful history, but they may no longer represent the same page or measurement conditions. Label the discontinuity rather than pretending it never happened.
Explore related IndieTools resources: product categories.
Continue your research
- Performance Regression Tests for SaaS Releases
- Website Speed Leaderboards: Read Ranks and Ties
- Domain Rating History: Read Weekly Changes
Sources and verification
Sources consulted for this article on October 1, 2026. Product capabilities are documented claims unless an actual test is explicitly described.
