How to Plan and Deliver on Site Speed as a Team

One of the most challenging undertakings for teams is to make a slow website fast. Why? Competing priorities, choosing the right area to focus, limited time, knowledge or expertise. And that’s before we even consider coding challenges themselves!

We developed a lightweight, straightforward framework that you can follow to plan and deliver performance initiatives at your company.

If you have attempted to, but failed in making significant speed improvements, then it may be time to try something new. Read on!

Form a Speed Team

The first step in improving speed is establishing who is responsible for the effort. Other than responsibility, it’s invaluable to gather a diverse group who can contribute unique ideas to the brainstorming and evaluation session (more on that below). By including people from different business areas, you’ll allow knowledge to spread throughout the organisation more freely too.

We recommend including Project Management, SEOs or Marketers, Developers and Designers. At a minimum, there should be both management and tech team members in your group. That way, you are likely to be able to not only scope but also prioritise the outlined work.

If forming a team isn’t quite feasible, you can go through the strategy described below yourself and present your findings to whoever can prioritise the work. Having a team is not mandatory.

Book a speed evaluation session

Now that you have assembled your Speed Team, it’s time to book a session that will shed light on your current performance and possible improvements.

When facilitating this meeting, you should aim to:

• Present your sites current performance metrics: Core Web Vitals are a good starting point as they are flagged as ranking signals for Google SEO and are solid summations of user experience. Be sure to explain what metrics measure if anyone is unaware.
• Discuss overall goals and targets: Where do you want to get to? (e.g. “Meet Google's Core Web Vitals thresholds” or “Get Largest Contentful Paint to under 3 seconds on Mobile”). Be as specific as you can.
• Speak to facts and don’t cast blame: Create an environment where each team member has the opportunity to raise their ideas and ask questions. Use the initial session to discover the web performance knowledge gaps within the team.
• Be realistic when estimating perceived performance gains: “Finger in the air” estimates, e.g. “Speed up LCP by 3 seconds”, are valuable to start the session with, but it’s easier to estimate work when you have some data to back it—what’s most realistic for your use case? If a task isn’t likely to improve people’s experience, don’t shy away from saying so either.

With an actionable agenda, you are most likely to make the most of people’s time and develop the most impactful strategy.

Plan initiatives with Performance Workbook

When you’re limited by time or have competing priorities, the work you do must create the most amount of value in the least amount of time. There’s an abundance of development tasks in the performance world that we could implement to speed things up. When we don’t discuss risks and opportunities upfront, it can be challenging to know where to start.

---

Convincing management to invest in a solution with an unknown result is likely to be complicated or impossible.

---

A clear path forward can be forged with communication and documentation. That’s why the next step in your journey is to create a Performance Workbook for each project.

A Performance Workbook is a spreadsheet of ideas for making speed improvements you will be using during your speed evaluation session mentioned above.

Here’s an example:

Idea	Difficulty	Est Effort	Est Gain	Comments
Preload Fonts	Low	Low	3—5 seconds LCP improvement	To be scheduled
Use CSS font-display to render text immediately	Low	Low	Instant text rendering	To be scheduled
Remove all ads for slower devices	Moderate	Moderate	LCP multiple seconds faster, 1.4mb less download on initial load	To be scheduled
Remove all webfonts	Moderate	Moderate	90KB less download, instant text rendering	Need to follow up with design and brand to discuss if possible
Implement third-party facades	Moderate	Moderate	500KB less Third-Party JS, Multiple seconds of Main thread activity removed	To be researched
Remove cookie notice	High	Moderate	No cookie popup or analytics on page load. 350kb less third-party analytics tracking	Requires turning off analytics and replacing with server-side metrics
Rewrite site to be a Single Page App	Unknown	High	Unsure. SPAs always seem to be fast?	Risky

• Idea: a potential strategy to improve speed. Review current metrics and the factors that influence them. Look to Lighthouse audits as a starting point. Ask questions such as “Is the Largest Contentful Paint delayed due to webfonts?” or “Can we optimise, reduce or remove them altogether?”. Even if it sounds unrealistic, write it down.
• Difficulty: an estimation of how hard will it be to implement the strategy. Are there any hurdles to overcome? Will it require approval from anyone? Do we have the skills to do this work?
• Estimated Effort: an estimation on how much work will be required to get it done? (e.g. Low, Moderate, High).
• Estimated Gains: an estimation of potential customer and user experience impact. If you aren’t sure, stick to the facts (e.g.: “500KB less Third Party JS” or “Instant text rendering”).
• Comments: any information relevant to the strategy—is it worth committing to? Is there research or approvals required? Are there any fears or doubts? Summarise the next steps or potential blockers.

You should write each row in the table with honesty and facts. Allow Low Difficulty and Low Estimated Effort tasks to float to the top. More complex, more value-ambiguous tasks, such as “Rewrite site to be a SPA”, can be called out for what they are—risky and of unknown benefit.

Commit to Low Difficulty and Low Estimated Effort tasks, leaving the moderate tasks when they’re the easiest and “cheapest” items left. Unknowns or High effort tasks should be either researched further or discarded.

---

If the work you’ve committed to has no known customer gain, do more research. If the research doesn’t discover gains, it won’t help your audience.

---

By investing in exploring ideas as a group, you will identify low-hanging fruit that could be immediately scheduled and highlight tasks that aren’t worth investing in at all.

With the Performance Workbook framework at hand, you can brainstorm ideas and gauge the most impactful strategies.

The Speed Team should get together on a semi-regular basis to review past initiatives in the workbook and track progress toward goals. It’s your accountability mechanism!

Make site speed visible

As the adage goes: “What gets monitored gets managed”. Your team should have a comprehensive awareness of how your sites perform to go through this process and continue working on user experience.

For that, you will need a web performance monitoring tool.

A dependable speed system will allow your team to:

• Receive continuous feedback as they work.
• Stop speed regressions from being released to customers.
• Safely experiment with web performance ideas and strategies.
• Recognise improvements, realise goals and celebrate wins.

Test work in progress

Testing work-in-progress empowers developers to experiment and explore potential speed improvements from your Performance Workbook with reduced risk and greater clarity. Unfortunately, it’s often not easy as testing performance on local machines is not representative of production environments, leading to confusing signals.

At Calibre, we use Pull Request Reviews to post performance reports directly in GitHub. That way, we can compare deployment previews to production and estimate how our development work impacts speed before a release:

By introducing accountability directly in the development process, your team is less likely to introduce user experience regressions.

Set Performance Budgets

It can sometimes take many weeks or even months over many iterations for performance initiatives to be released. That’s why it’s essential work your way towards the goals you set in the speed evaluation session.

Performance Budgets are thresholds for speed metrics that keep your Speed Team accountable. Budgets also bring transparency to where your performance is at. You should set budgets and alerts for critical user-focused metrics, like Core Web Vitals, Third Party Script Data Transfer, Time to Interactive or Performance Score.

We use Calibre’s Performance Budgets to set our goals. It allows you to specify a speed metric, target value, devices, and pages to be tracked. While doing so, we see metric historical values and suggested ranges for fast measurements:

Once the Performance Budget is in place, we can track it over time. Problematic pages are highlighted, making it easier to know where the most focus is required:

Clear visibility of progress allows your team to quickly track down regressions or celebrate successes!

---

Performance work is never finished. With this process at hand, you will evaluate, plan and deliver on performance successfully over time.

When you embed consideration for speed and accessibility across your whole organisation, you’re most likely to see the benefits in ways of better user experience, conversions, search engine ranking and engagement. Delivering impactful work with tangible results is also a key ingredient for happy employees.

Let’s get planning!