3 Tips on Preserving Website Speed

Performance optimization is one of the best (if not the best) ways of making your website make more money.

After we published our Tesla.com speedup series, I got a question that prompted me to think about a much harder task: How to stay fast once you got there?

If you have ever built a slow website, then made it fast, you probably already know that long term commitments are much harder to keep than short bursts of productivity.

Performance commitment might demand a closer look at the code going into production, constant optimization of images (or introducing an automated system to do it), saying no to bloat masked as 3rd party shiny tracking tools, banners, support widgets, custom fonts, etc., or staying up to date with new browser features.

Say NO: performance IS business
Do regular performance tests
Have someone responsible

1. Say NO: performance IS business

This might be the hardest to do because as a dev you don't always have the leverage (or character) to say no to requests coming your way. By my estimation, this is the main reason why pages become nightmares with 200 requests and 30 third-party scripts that break website performance, user privacy, and — when any one of them times out — the whole page.

If you haven't seen research showing how page speed affects conversions, I highly recommend it — it is a great argument for spending time on performance optimization. It is one of the best (if not the best) ways of making your website make more money. Especially if it's an eCommerce site or your website heavily relies on SEO, as performance is a big factor in search rank calculation.

The faster everyone understands that a fast website is a business feature (and sometimes it is a business KPI, for a good reason) the better. Decisions about tag managers, that fancy new heatmap tracker or survey widget, or "chat with us now bot" are all business decisions that affect performance in a big way.

Here are some links worthy of sharing with decision-makers and business leaders:

A fast website not only makes it easier to get new customers but also instantly turns them into happy ones.

Information about third-party scripts and the risks you're introducing with them is also very important to know:

2. Do regular performance tests

There are many tools available for measuring performance both manually and automatically.

For manual testing, I use two: Webpagetest.org and Lighthouse

For automatic testing, I use one: Lighthouse CI (read my post on it)

Another great tool for measuring your user's performance (as opposed to running tests on some server) is Speedcurve.com, but it is not free.

It doesn't really matter which tool you choose, what you are looking for is changes over time, not absolute values. It is less important if the tool reports metrics always accurately (that does not mean you shouldn't aim for that), you want to know if you are making progress and notice when some terrible regression has been introduced. This means you need to record data over time, either in a tool or — if you prefer a low-tech version — in a spreadsheet.

A story from my experience

Some years ago, when my webperf passion was still in its infancy, I took the spreadsheet approach and measured a project I joined without telling anyone. After 8 months, when I shared some charts from it everyone was shocked. The boiling frog phenomenon (small changes over a long time are hard to notice, hence the frog can be boiled by increasing the temperature slowly) didn't allow them to notice that the application was so much faster than 8 months ago.

This discovery made the whole team aware that if you put a little bit of focus on performance for a long time, things just fall into place while at the same time you don't have to:

Cut back on features - we did everything from the backlog
Do tasks slower - nobody noticed that I was doing that, and as a team, we delivered faster than expected

But it does mean that all people will feel the improvement, especially that this application was used by people with slow average connections and lower-end hardware.

From that point on, I did the same for every new project I joined that I thought was not up to my standards.

What to write down?

Ideally, you should write down everything you have control over. If you own backend and frontend, then write down everything - it's better to have this data and not use it than not having it when you need it.

What I recommend as a minimum:

TTFB (Time To First Byte) - mostly backend metric, measures how long the server takes to respond with something (read more)
TTI (Time To First Interactive) - measures how long it takes for a page to become fully interactive (read more)
LCP (Largest Contentful Paint) - measures when the largest content element in the viewport is rendered to the screen. This approximates when the main content of the page is visible to users. (read more)

What you should aim for is progress every month - no matter how small.

Long term goal

In performance — as in most things in life — diminishing returns kick in hard at some point, so you need to be careful not to go overboard with optimizations. For example, our documentation page is so fast, that every time I try to speed it up, it just makes things worse. I tried instant.page, quicklinks, inlining fonts, extracting critical CSS, prefetching some assets based on usage. At the end of the day, the more your website is optimized, the harder and more time-consuming it gets to improve it further. It is good to know when to stop and focus on other things.

My recommendations for "slow 3G" is to aim for:

TTFB: Under 800ms
LCP: Below 3 seconds
TTI: Below 5 seconds
Lighthouse score: Over 90

I did not include any measurements in kilobytes, because it is very subjective, and if you write an SPA, you might blow the whole budget before you even write "Hello world" in your favorite framework. So just focus on user experience and you will have something to aim for without having to remember how bad today's Javascript ecosystem is.

Performance budgets

Some companies implement performance budgets with success and I would say it is a very good motivator for improvement. Nothing is as satisfying as seeing your long-term plan going well and month after month seeing numbers go lower and greener. Budgets are a way to constantly remind you that every time you add something, it adds weight, and maybe there is a different, better way.

Since in this article we are talking about optimized websites, you just need to set budgets to your current state and don't go over them. If you do for a good reason, update your budgets for the new reality. If you decide you want to improve, you can lower your budgets as a challenge, and see if you can satisfy more restrictive limits next month. It is certainly a good motivator. :)

Performance budgets 101

3. Have someone responsible

In my opinion, every team should have at least one performance-oriented person with OCD (like me) who loves to say no. This person should be a gatekeeper, responsible for every asset loaded onto the website. Ideally, your CTO already knows how important performance is for the business. Developers can't fight the same battles every month, or they will get discouraged and your website will gradually fall into Google Tag Manager's abyss. Remember the boiling frog effect? It goes both ways, every little widget, every little script... it all adds up.

I hope this article is relevant to as many of you as possible. I hope that if you had a slow website, now you have a fast one or soon will have. It's great to know and very promising for the future. Website performance in my opinion is still neglected today, which is a shame considering its impact for the bounce rate, user experience, customer experience, conversion rates, etc. No matter which measurement you choose to describe, a faster website means a better website. Cheaper to run, cheaper to use, and fulfilling business goals better.

platformOS