Freeze the baseline before changing anything
On August 24, 2026, the public homepage returned a 37 performance score, 83 accessibility score, 92 SEO score and 11.4-second LCP in a Lighthouse mobile-profile run. The same run showed 850 milliseconds of total blocking time and an estimated 178 KiB of unused JavaScript. These are controlled lab observations from one date and profile, not a promise about every visitor or the finished result.
Start with the resource that controls the first impression
The LCP is the first practical question: which element is late, when does its request begin, and what has to finish before it can paint? I would trace that chain, remove work that is not needed for the first view, and then address the named accessibility failures. Smaller image or CSS opportunities can wait until the critical path is understood.
- Confirm the actual LCP element
- Trace when its request begins
- Remove or defer non-critical JavaScript
- Repair named accessibility failures
- Repeat the same profile for comparison
Publish an after only when it exists
The credible case study keeps the baseline and waits for a reproducible after-audit. Until that run exists, BunnyFlowStudio stays labelled as optimization in progress. That is more useful to a reader than a polished success story with an invented ending.