- Maybe the most important part
of creating a performance budget is making it realistic
and data driven.
A performance budget that is too light
will never be taken seriously.
And a performance budget that is not based on real data
and analysis has little practical value.
To get started on a performance budget of your own
here are some best practice metrics
recommended by industry leaders,
including researchers at Google.
Make sure that your site meets a speed index
under three seconds.
That time to interactive is under five seconds,
that the largest contentful paint is under one second,
that the max potential first input delay
is under 130 microseconds,
that the maximum size of the Gzipped JavaScript bundle
is under 170k,
that the total bundle size is under 250k
and that all of this happens on a low powered
feature phone on 3G.
Now these performance budget metrics are severe
and really difficult to hit.
They're also the metrics being used
by tools like Lighthouse to test for performance.
So how do you go about creating
a realistic performance budget for your own site
or your own app?
Here's some tips.
When developing performance budget it's common to
create different budgets for different scenarios
and serve different solutions to different users.
This all centers around getting the sites
to the user as fast as possible
and not wasting any of the user's bandwidth or data caps.
In practical terms creating a performance budget
typically starts by doing a performance audits
of your own project and also any relevant competitors.
Your goal will always be to beat your competitor
on performance.
Next, set some reasonable goals that you can meet
with some work.
This could be bringing the speed index down
under three seconds or reducing the total page size
or hitting largest contentful paint under one second
or a combination of some or all of these features.
Then test the production version of your projects
against these metrics to see where you currently stand.
And when you do that, make sure you use
one of these third party testing providers
because then we can test it from different locations
in the world using different server configurations
and browser configurations and everything else.
The answer to these tests will almost always be
way over budget at first.
In that case, do a closer inspection
to find out where the bottlenecks and performance hogs are
so that you can deal with them.
Once you have relevant competitor information,
baseline performance metrics for your own project
and the recommendations I introduced
at the top of this movie,
you can map out your own performance budget
and start working with it.
One important thing to keep in mind as you start this work,
performance budgets are individual
to each project and there is no one size fits all here.
Your project may require a higher budget
than what is recommended, and that's fine
as long as you don't use that higher budget
as an excuse to waste the user's time and data cap.
Also remember that performance budgets can change over time.
As your project evolves
new features may need to be considered
or new performance tools or best practices
may come into play to help you drag that budget down.
If, and when you decide to change the performance budget
try to always change it for the better.
Bring your metrics down to make the site more performance,
any increase in a performance budget
means increased load time and cost for the end users.
So any increase requires a very good reason.