Version
Use the release name your team recognizes, such as v2.4.0, checkout-redesign, or a short deployment identifier.
Release markers
A small, useful record
Save only the release context the timeline needs
Release markers are created manually at project level and apply as context when you review the project’s individual page histories.
Release time
Place the marker at the actual deployment time so it sits correctly between the Lighthouse runs around it.
Notes
Record the useful clue: a new bundle, image migration, template change, campaign, or rollback.
Release Markershttps://storefront.example
Example dataAdded versions
| Version | Date | Notes | Actions |
|---|---|---|---|
| v2.4.0 | Aug 4, 2026, 06:00 PM | Checkout image delivery update | |
| v2.3.0 | Jul 15, 2026, 10:00 AM | Homepage campaign components |
Manage the record
Add a release once, then correct it when the details change
The dashboard keeps the marker form and the project’s added versions together. Existing entries can be edited or deleted without changing the underlying test results.
- Create a marker with version, date and time, and optional notes.
- Edit the label, timestamp, or notes when release information is corrected.
- Delete a marker after confirmation when it no longer belongs in the project history.
A marker records timing, not causation. It helps you form a better hypothesis; it does not prove that the release caused the change.
See the complete performance history workflowQuestions
Release marker FAQ
Build the timeline first
Make the next release visible before the next score moves
Start with a free Lighthouse test. Then add the important pages to a project, build a repeatable history, and place releases beside the results.