An agile approach to improving page speed
In this post, I discuss how to write user-story acceptance criteria to improve web page speed. Please visit Waterfaller.dev to fix page speed and core web vital issues on your web site.
In my experience, page speed is seldom discussed unless it is a problem. Stakeholders want to know why pages are slow and when they will be fixed. The agile approach I outline is a conservative but proven strategy for improving page speed. It assumes that the issue is complex and the fix requires more than a single release.
Time-Based Measures
To start, I do not start with time-based measures (i.e. largest contentful paint) as acceptance criteria in webpage speed user stories. In my experience, time-based criteria are untestable and misleading.
As an application, I want to make featured images smaller so that Largest Contentful Paint is less than 4 seconds.
This story presumes that it is the key to unlock LCP. On simple pages, this may be true, but not for complex sites and applications where I need to deal with blocking resources, cache configurations, or third-party scripts.
In my experience, time-based measures are best used in epics or initiatives.
Quantitative measures
I prefer to use quantitative measures in user stories. As quantities are unaffected by network latency, connection speed, or other changes in the release. I prefer to write a story this way.
As mobile blog reader, I want to view a small blog image so that I can quickly scan the content.
The acceptance criteria can be straightforward.
Scenario: Reader clicks a link in Twitter and lands on a blog post
“Given that I’m using my moto g4 phone
and using a fast 4G connection
When I land on a blog post
Then the featured image is not larger than 420px wide”
The story is testable and does not try to solve every web page speed issue.
Block and Tackle
Business owners often want one silver bullet story. Instead, I like to visualize the problem as lifting a heavy stone with a block and tackle (where a rope threaded between two or more pulleys can lift a heavy load). Likewise, this approach releases two or more stories that together make an application faster (and push toward the epic goal).
This approach is realistic. In my case, in order to address the largest contentful paint, I created an epic which then used a time-based measure.
Reduce largest contentful paint for mobile blog readers to less than 2 seconds
It had additional stories like:
- Move images to a fast CDN
- Get rid of unused CSS
- Inline critical styles
If you’re taking a block and tackle approach, then each story makes a measurable improvement, but it does not lift the entire load.
I then knit epics together to achieve the business initiative to sell more ads (or some other business objective).
I’m daily working to improve page speed, and as a side hustle, I created Waterfaller.dev. I appreciate your comments.
