As expert financial services software developers we’re obligated to understand the inner-workings of webpage performance so as to be able to ensure our clients’ websites are blazingly fast.
For all industries, but particularly domains where trust is paramount such as financial services, it is absolutely essential that your webpage performance is optimal to ensure a delightful user experience.
Among many other pertinent reasons, a particularly crucial one is that: performance directly affects user conversion. In this highly competitive space, that is of the utmost importance.
What are we going to cover in this article?
Some necessary background understanding
- Why does webpage performance matter?
- How performant does a web page need to be?
- How is performance measured?
The Steps to take:
- Step 1 – Start with the right infrastructure
- Step 2 – Make everything smaller
- Step 3 – Load assets in the right order
- Step 4 – Cache and expire what you can
- Step 5 – Don’t forget about databases
- Step 6 – How to architect correctly for webpage performance
- Step 7 – Remember to keep this going
Why does webpage performance matter?
It all boils down to money. It turns out webpage performance really matters and can greatly impact the number of users who find your webpage, those who then use your services to become customers and what those users and customers end up thinking about your business. This directly affects the bottom line.
There are three main reasons for this:
Poor performance web pages are indexed less often by search engines
Search engines have what is known as a “crawl budget” or a “crawl limit” and will not continue crawling pages that have high server load or whose pages timeout or are slow to load and crawl. This means that your slow webpage will be indexed less often and changes will be taken into account more slowly and will therefore be less visible. You’ll end up having fewer users.
High performance web pages ranked higher by search engines
Google uses page speed as a direct ranking factor and will rank pages higher that perform better than their competitors for the same terms. We don’t know exactly how they use speed in their algorithms but we know that they do and go as far as to provide detailed tools to help admins evaluate and improve their page speeds. You’ll end up having fewer users.
High performance web pages convert more users into customers
I’ll quote just a few of the easily available statistics and damning studies below:
“When the page load time increase from 1 second to 10 seconds, the chance that a mobile site visitor bounces increases by 123%” – Google
“The probability of a user bouncing increases 32% when the page load time goes from 1 to 3 seconds.” – Google
“The highest conversion rates are on pages with load times between 0-2 seconds.” – Potent
“Website conversion rates drop by an average of 2.11% with each additional second of load time (between seconds 0-9).”- Potent
These all mean that you’ll end up turning fewer users into customers…
How performant does a webpage need to be?
So given that we’ve concluded now that page speed is important, how fast exactly do we want our pages to load? The answer isn’t super straightforward in totality but we can dig into the details a bit further down.
The simple answer, that Google has been pretty clear on and answered directly is…
A Google Webmaster video had Maile Ohye stating that “2 seconds is the threshold for e-commerce website acceptability. At Google, we aim for under a half-second.”
And that was 6 years ago…
Take a quick break, visit Google’s page speed insights and see how your page shapes up now.
How is webpage performance measured?
It is worth noting that page speed isn’t all that simple when it gets down to it and there are actually three other things one needs to consider concurrently.
This is the time that your page takes to show the user the largest content on the screen. Google apparently only considers the content above the fold here. We’ll get to how to tackle this later.
This is the delay before a user is able to interact with your page. Pressing a button, clicking on a form field. This should be very quick.
3. Cumulative layout shift
This gets complicated and you can read more about it here but essentially you don’t want your page to move and jump around much while it’s loading as that can be a bad experience for users who try to click on a button that then moves out of their way, and as we’ve determined, Google punishes us when we provide a bad experience to users.
Right, with all that said, let’s get into the steps you need to take to ensure that your pages are blazingly fast for your users and successfully turn them into customers.
Step 1 – Start with the right infrastructure for webpage performance
To set off on the right foot it’s important that you choose the correct infrastructure for the task at hand. For a simple webpage, this may mean a simple server with a common hosting provider. For a modern web application this will likely mean dedicated servers or a setup with AWS, Google Cloud or Azure.
Whichever solution you pick you’ll need to ensure that you have sufficient resources that are correctly configured and in the appropriate locations for your users.
The main things to ensure are:
- Use a content delivery network or CDN to serve users in many locations.
- Configure your server correctly for Gzip compression.
- Although this is usually standard these days.
- Ensure that your server response time is under 200ms.
- Google recommends the above these days but try get it as low as possible.
- Time to first byte or TTFB is an important indication of the response speed of your server. It measures the duration of time from the user making an HTTP request to the first byte of the page being received by the browser.
- Choose a fast DNS provider.
- The list I linked to ranks providers.
Step 2 – Make everything smaller
Every item on your webpage is data requested from a server and sent over HTTP to the user’s browser. The fewer requests for data and the smaller the requested data, the faster your webpage will load. So…
- Make fewer HTTP requests.
- One of the best ways to reduce HTTP requests is to combine or ‘concatenate’ CSS and JS files.
- Although this needs to be used carefully. Since HTTP/2 we can request multiple files simultaneously without slowing a site down. This means that we don’t necessarily want to concatenate ALL our files.
- Minify all of your CSS and JS.
- Reduce the size of all the individual files by removing whitespace, shortening variable names etc through a process called ‘minification’.
- Remove all unused or unnecessary files.
- Reduce image file size by compressing images as much as possible while retaining sufficient quality.
- Sufficient depends on your preferences and use cases.
- Image types – use next generation image formats like WebP or AVIF which are new formats that maintain quality at much smaller sizes. As not all browsers support these, this often needs to be implemented either client side or on your CDN.
Step 3 – Load assets in the right order
Since this will be a measure for performance and affect our ranking as well as the user experience we want to ensure that the content above the fold loads as quickly as possible, becomes interactive as quickly as possible and doesn’t jump around while loading.
To do this well we should ensure the following:
- Defer the loading of CSS and JS not required above the fold so that you don’t block the rendering of this content.
- Load the required CSS and JS or fonts early enough such that the content above the fold doesn’t jump around while loading.
- Use ‘Lazy loading‘ to defer the loading of any image not visible above the fold.
- Delay the loading of any large scripts used for animation etc
- Say you have a great but complex animation halfway down the page, you could only load the animation library for this as a user begins to scroll.
- Defer the loading of tracking scripts and all other 3rd party scripts until a reasonable time. This is a slightly more complex issue.
Step 4 – Cache and expire what you can
A detailed explanation of what and how to cache would be an article on its own, so I’ll be brief here and explain the most important concepts only.
A cache is “a reserved storage location that collects temporary data to help web pages, browsers, and apps load faster.”
Don’t require the user to reload a file that hasn’t changed since they last used it. Notify their browser that it should save this file for reuse later.
- Configure your build tools correctly – more on this below.
- Use hashes in file names to allow long cache times and instant cache busting as required.
- Tell the user’s browser to cache files and for how long to cache them using expiration headers.
- Using a CDN allows you to cache files near a user’s location so that even if it isn’t cached in their browser, it’s still cached closest to them.
- Cache your API endpoints appropriately so that even when the page isn’t cached on the server and needs to be built, the API response can be cached and faster.
- Use service workers where practical.
- Use AMP or Accelerated Mobile Pages by Google to cache the mobile version of your site directly on Google’s servers for ultra fast loading.
Step 5 – Don’t forget about the database
It’s important that I mention optimising the databases for performance as well. For a mostly static site one can get away with a non-performant database through extensive caching but for a more dynamic site one needs to be sure that the database is as performant as possible as well.
There are many ways to do this and it is again a subject on it’s own but some important considerations are:
- Correct use of indexing. Both too much and too little can be a problem.
- An index is essentially a data structure that helps to improve the speed of data retrieval.
- Optimise queries to run efficiently and only return the necessary info.
- Be specific and avoid using things like ‘*’.
- Cleanup any unused tables as these can make lookups take longer.
- Avoid using correlated subqueries.
- Add a cache like REDIS for frequently accessed, slower queries.
- Consider splitting out API calls so that only the queries required to render above the fold content can be run first.
Step 6 – Architect correctly for webpage performance
This step is very dependent on the sort of web page or application you are building and so I cannot go into too much depth here broadly speaking but it needs to be mentioned.
You’ll want to architect and build your web application for the purpose it will be serving so that it can be made as performant as possible from the ground up.
Some important topics to consider here are:
- Build tools and pipelines
- Separating out services
- Server side rendering. Serve as much pre-rendered HTML to the browser as possible rather than wait for JS to be able to render. Similar to other points above, this applies especially to above the fold content.
Step 7 – Remember to keep this going
Optimisation isn’t a do once and forget kind of thing. As time marches on your site will bloat, Google will update its rules, new technology will emerge and you’ll need to revisit your webpage performance and make the necessary updates.
- Optimise your code and architecture based on the usage patterns of your users and the load on your server.
- If one specific part of your application is used 100’s or 1000’s of times a day but the rest is used only dozens then it might make sense to break this part out into its own micro-service and optimise for its specific use case.
- Limit redirects
- Over time some pages will be removed and others will be added and you’ll add redirects. Redirects slow things down. Avoid overusing them.
- There’s nothing wrong with returning a 404 to a user if that page has been removed and there is no 1-1 alternative.
- Dynamic vs static
- Follow new google rules
- Keep abreast of Google’s changes and recommendations.
- Re-run page speed insight tests and ensure you remain within the recommended guidelines.
- Remember that optimisation is on a per page basis so you’ll need to regularly check each individual page for performance and not only your home page for example.
So, there you have it! If you follow every step in this guide on webpage performance then your site will be blazingly fast!
Do you think I left anything out? Do you have further recommendations? Any questions? let me know in the comments!
Do you have a new FinTech project in mind that needs to have ludicrously good webpage performance? – book a consultation with us and we’ll see how we can work together.