In a 2019 study from Milliseconds Make Millions by Fifty-Five and shared on Google’s official blog found several interesting insights on small speed increases.
37 brands qualified for study, after qualitative checks, with speed data measured via Google Lighthouse and aggregated against each brand’s Web analytics. The study targeted four key speed metrics. The results were fed into a Logarithmic Regression model to extract meaning.
Non-exhaustive summary of findings for a 0.1s faster performing mobile sites alone (not factoring in the effect on desktop decisions):
- 8.4% conversions increase for retail consumers; 9.2% increased average order value
- 10.1% conversions increase for travel consumers; 1.9% increased average order value
- More sales funnel progression (direct correlation); improved bounce rates for travel homepage, retail product listings and travel by 6.5%, 5.7%, and 5.4% respectively
In short, learning how to optimize website performance can disproportionately grow the bottom-line. Let’s learn how to optimize website performance from two levels:
- The first section of this guide is dedicated to tools that give you a useful overview for your continuous development pipeline.
- The second are practical fixes to the most performance-hitting issues that affect websites.
Track Your Resources During Development
Create KPIs via the RAIL model
You can’t optimize what you don’t measure. RAIL (Response Animation Idle Load) is a user-centric conceptual model used for analyzing and designing your website performance. User experiences are categorized into key actions (for instance, scroll, tap, load) so you can better create KPIs for each item. The model assumes four key phases in the web app life-cycle:
- Response—how quickly does the end user get a response? It is recommended to get this under 100ms from the moment the user clicks or taps on a button. Anything over this will not feel immediate to the user psychologically.
- Animation—this includes things like dragging, scrolling and other visual animations. The upper limit recommended is 16ms at 60 frames per second.
- Idle—This is work done in the background. This is considered part of the 100ms response time.
- Load—how quickly the first meaningful paint is reached; e.g. the expected time is under a second. After this is accomplished, your single aim is to sustain your application’s responsiveness for the user.
Speed budget with Google Lighthouse
Lighthouse has gained popularity over the last few years as a performance auditing tool—its central function is to score webpages in the categories of accessibility, performance, SEO, and best practices. You can also, however, use it as a performance budgeting tool.
Budgeting with Lighthouse CLI
This is one method for creating a budget in Lighthouse. This is done as an extension from page speed insights or through DevTools. You can use npm to install the Lighthouse CLI; see a full guide here.
Budget for individual objects as a resource array. This can be assigned to a: document, image, font, media, script, stylesheet, third-party, total, or other. Multiple performance budgets are possible in single stores, such as giving the homepage and blog posts different performance budgets.
Once you’ve completed setting up your budget, you will receive a normal report with performance indicators, plus an extra column showing budget results. It will highlight over budget resource types.
Once you’ve established your budget, it should be tracked in correspondence with the bottom-line. This is your top-line starting point for optimizing your website(s).
Shore Up the Largest Website Performance Inefficiencies
The following five issues are the most under-addressed and high-impacting—according to a 2018 research study on how to optimize website performance by SEMrush—arranged in order of importance starting with the most important issue:
- Slow page load speed (HTML)
- Uncompressed pages
This is a high ROI—for your time—place to start when shoring up website performance inefficiencies. Two fixes can address these issues.
First start with heavier pages that contain more resources and take longer to load. A good aim for your total JSS and CSS transfer file size is 2MB, no more. Anything over this is considered heavy. An auditing tool like SEMrush will for instance generate an error. 2MB is enough for complicated websites with breakthrough technologies.
Videos and images take up the largest portion of your page’s diet, so start here. What are the resolution, quality, or format of your visual content, which can substantially shrink your page. Clinically evaluate the value of each visual. Would emojis work better in some cases, for instance…🙋♀️? These are basically shrunken images.
Optimize server performance
Another aspect of slow page loading speeds—which is the second most critical issue that underperforming websites face—and inefficient web hosting is a more common cause for sluggishness than is a large HTML page size (which can be as little as 1% of a contributing factor). Reevaluate your hosting provider and specific package; if your numbers are substandard, change your provider or consider paying for a dedicated server.
Extra server fixes
This Think Google calculator can help you to estimate how site speed improvements could affect your revenue. Other key factors that can influence your server response are: slow database queries / routing / application logic, and starvations of libraries, frameworks, resource CPU, or the memory. Here is an overview on fixing the latter from Google.
On top of that you can find application performance management tools such as Retrace which will help you with speedy troubleshooting and problem solving. Spending less time on looking for resolutions and being quick at getting back on your feet can also affect your revenue as per the following ROI calculator.
Redirect loops and chains are an old website performance issue. Fixing this can clean up delays between the moment that users click for your webpage and when it actually appears on-screen. This also reduces confusion that crawling bots face. The more redirects you have, the more that SEO score-assigning bots may cut away at your rank. Note that the older your website is and the more redirects you have accumulated, the trickier that it can be to keep your site schema tidy.
Cleaning up redirects
301-directs are permanent, and denote when a page has been moved or deleted, giving visitors the ERROR 404 message. 302-directs are temporary, and means you are redirecting traffic to another page for a while. This is not an especially common issue, so you could check whether you have redirect issues first using free tools like Redirect Mapper, Broken Requests, Redirect Detective, and Screaming Frog Bulk Request Redirect Checker (more thorough).
Optimising site performance as a two fold process.
Measuring your starting/ongoing points is the project management half of the equation. We’ve mentioned RAIL and Lighthouse budgeting. Google PageSpeed Insights is another great tool to begin with—it’s free, capable, and generates mobile and desktop reports for your site, with a focus on criteria that Google treats seriously.
The second half is to practically shore up inefficiencies that affect your website’s performance. I’ve gathered these into two broad tasks with many subtasks—plus a bonus—to lighten your pages and optimize server response times.
With the two together, you’ll have a rigorous optimization plan on how to optimize website performance.