Skip to content

Instantly share code, notes, and snippets.

@davidhund

davidhund/performance-budget-notes.md

Created April 21, 2017 14:07
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save davidhund/1e477dee679685a9192013c54dec3d73 to your computer and use it in GitHub Desktop.
Save davidhund/1e477dee679685a9192013c54dec3d73 to your computer and use it in GitHub Desktop.
Download ZIP
Performance Budget
Raw
performance-budget-notes.md

Front-end Performance

The Case for FED Performance Optimisation

A fast website is essential for a good user experience (UX), conversion and findability.

Performance == User Experience == Conversion

For real-world examples of this see https://wpostats.com/

The average website us more than 2MB heavy which is due mostly to images. But also the rise of popularity of Web fonts and JavaScript contributes to this (see: https://www.soasta.com/blog/page-bloat-average-web-page-2-mb/ & https://boagworld.com/usability/performance-ux/)

The Performance Golden Rule:

Steve souders famously stated:

“80-90% of the end-user response time is spent on the frontend. Start there.”.

He discovered that, contrary to what people thought at the time, many performance issues were due to the front-end code (not the back-end).

A Performance Budget:

A 'Performance Budget' is a tool to protect the UX and to make consequences of certain development practices on FED performance clearer.

It is:

  • a 'Budget': ‘cost’ on certain 'metrics'
  • a set of requirements around performance, scores, etc.
  • a 'talking piece' and works towards creating a ‘Culture of performance’

For example:

  • “The combined weight of the site remains under 1.5MB”
  • “Pages should be loaded within 3 seconds on Cable”
  • “A minimum PageSpeed score of 80”

Metrics:

What we measure could change per site. However all metrics should be relevant to UX.

  • Milestone times: load-time, ‘first-render’…
  • Quantities: number of requests, bytes…
  • Scores: SpeedIndex, PageSpeed, ySlow…
  • Custom: Twitter: ‘Time to first tweet’…

Clearer consequences of development choices

A performance budget can help to make the consequences on performance more clear:

For example:

“Adding this Hero image adds 255kb extra weight. If we also add this JavaScript functionality, we'll go over our budget of 1.5MB…”

a 'talking piece':

For example:

“Do we really need separate Web-fonts? It's 4 extra requests, 200kb, and makes the page slower. Do we not rather have XYZ?”

Gone 'over budget'?

There are a couple of options when we go over budget:

  • Do not add the files or functionality
  • Optimize the files or functionality
  • Remove the files or functionality

How to implement? Realistic, but ambitious:

  1. Inventorize: target audience, requirements, etc.
  2. Analyze: current state, ‘competition’, best-practices
  3. Create a Budget: base-mark (nulmeting), benchmarks
  4. Document: What? How? Test-settings, etc.
  5. Re-test: Periodically, after delivery. DIY or use services/tools

Some tools/services:

Try and work towards a 'Culture of Performance' and always keep UX in the back of your mind. Keep up with performance best-practices and work with e.g. a Performance Checklist when developing (new) features.

One could test manually (with e.g. YellowLab) at certain times (e.g. before committing) with scripts, browser extensions etc, auto-collect certain stats in e.g. Google Analytics or continue to monitor FED performance through (online) services.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment