The following chapter is about the Technology/Performance Audit Checklist which is part of the full Website Audit Checklist definitive guide.
It’s important to do a review of your website’s technology stack, including all the different tools and systems that the website is integrated with.
As part of this review, you also want to assess the website performance which is partially dependent on the technology stack you’ve chosen.
Is it built on a platform suitable for the business?
WordPress, Kentico, Drupal, Joomla, Squarespace, Wix, Shopify all have their merits.
This will give you an idea of the market share of different platforms:
Even though WordPress is the most popular platform, it’s certainly not the only platform and may not be the best solution for everyone.
So you need to evaluate the business, the platform you are on and whether or not you’ve made the right choice.
What other tools/plugins are installed?
The easiest way to see which plugins and tools your website uses is with a tool like Builtwith. It’s fast and easy to use but it won’t pick up every technology your website is using.
If you’re using WordPress, the better way to see all plugins is to log into your website directly and look at the Plugins menu.
It’s important to make sure that the plugins you’re using are frequently updated and that they operate on the latest version of WordPress. This way you’ll avoid any security issues that can creep in with outdated plugins.
Do you regularly backup your site?
A key part of website security practices is to regularly backup your website.
That way, even if your website gets hacked, you can easily restore it from the latest backup.
How often you’ll make backups really depends on how frequently you update your website with new content.
For example, if you only publish one new blog post per week and don’t make any other updates, then backing up weekly will be enough.
However, you should make sure that your backups capture as much of your website data as possible, including your themes, categories, customer data, pages, blog posts, and more.
Is it maintained correctly?
Just like a car a website needs maintenance.
Regular maintenance and testing can help you identify and fix any issues that may prevent your site from running smoothly.
Here are some example maintenance tasks:
- Are there plugins installed that you don’t use anymore?
- Are there older versions of plugins that need to be updated?
- Has the website got slower over time for any reason related to the setup?
Anything of concern in Google Search Console?
In the SEO section we talked about areas of concern for search but there are also specific issues related to technology.
For example:
- The core web vitals section shows if there are any issues in relation to speed of the website.
- In the coverage section you may see some server errors that may need to be resolved.
- You want to make sure there are no issues in the security and manual action section.
Do the pages load fast enough?
The speed of your website is a ranking factor for Google but it also impacts user experience.
This is particularly important on a mobile device where we have to consider that the user may not have the fastest connection going.
And speed is not just about your homepage. Your homepage could be fast but your eCommerce shopping pages may be very slow.
That’s why you need to test your homepage as well as other important pages. If you have an eCommerce shop with lots of products it’s likely to be a products page. If it’s a service/product based business then you can test a service page or a blog page.
A great tool to use to measure performance is Google Page Speed insights.
Here’s an example of the results results you will see:
We want all these indicators to be green! Orange means it’s ok and red means it’s time to worry.
- First Contentful Paint – This is when a website visitor sees the first thing on your website as it’s loading.
- Time to interactive – This represents the time a page takes before the user can interact with it.
- Speed Index – This is metric takes into account how fast a page loads at various intervals. For example, if two websites load in 1.5 seconds but one displays some content on the screen before the other then it’s going to appear faster.
- Total blocking time – This is when a user is blocked from interacting (e.g. using keyboard). It measures the total amount of time between First Contentful Paint (FCP) and Time to Interactive (TTI) and ads up any chunks that take over 50ms (long tasks).
- Largest Contentful Paint – This is the time a page takes to display the largest content on the screen.
- Cumulative layout shift – This metric shows how often users experience unexpected layout shifts.
There are various issues that affect website performance, including:
- Size of images – If an image is 1000px and you display it in a 200px container then you have an image that you need to change to 200px before uploading.
- Caching – When information is stored in memory it is returned faster.
- Heavy CSS and JavaScript use – If you’re loading lots of scripts this can have a dramatic effect on performance.
Is there a CDN?
If you wanted to go and buy something from a store that had multiple branches you’d pick the closest one.
A content delivery network (CDN) is a geographically distributed network of servers that speeds up the the delivery of your website’s pages to users.
Simply put, a CDN delivers web content to a user based on their location i.e. from a location nearest to them. This helps to improve your website speed.
Is the most suitable hosting package used?
The speed of your website is also impacted by a hosting package you have signed up for.
For example:
| Type of Hosting | What it is | Advantages | Disadvantages |
|---|---|---|---|
| Shared hosting | Your website is hosted on servers that are shared with other businesses. This means memory, processing power etc. is shared. | It’s cheap! Security updates are handled automatically. | Not that secure Other websites can hog the machines and you end up with poor performance. |
| VPS (virtual private server) | A server is split into virtual machines using virtualisation software to provide you with dedicated (private) resources. | It’s more private than shared hosting. You can get good performance and it’s not too expensive. | You are sharing server resources so spikes in usage on the machine from other websites can affect you. |
| Dedicated server | This is where you have one or more machines which are dedicated to your website(s). No one else can use these machines. | No one else is using the machine so you have the full power and no one else can be responsible for breaking it. | You need skilled people to maintain. It’s expensive. |
| Cloud | With a cloud VPS you have lots of servers clustered together. So it’s not like one machine is shared amongst multiple websites. You have many machines shared by many websites and if you require extra bandwidth it’s automatically provided by using up available resources. This is a utility like electricity. You pay based on what you use. | Easy to scale up and down e.g. with AWS (Amazon) you can add additional RAM and memory within minutes. | Expensive (e.g. AWS is very expensive) |
So we need to evaluate your hosting package.
The following tool measures the response time of your hosting setup:
How does the website work behind the scenes?
You’ll want to open up the website in your browser and use the developer tools to analyze it.
For example, on Chrome you can use Chrome Dev tools. Using these tools you can see how things are working technically with your website.
When your website is loading it’s also loading a series of scripts in parallel, after each other or a combination of both.
For example, you could be loading a Google Analytics tracking code (see the network tab).
So you’ll want to check:
- How are scripts loading and can they be optimised?
- Are there errors in html?
- Are there errors in CSS?
It’s also useful to go through the page source and see if you spot any issues. For example, you’ve probably already analysed your titles, meta descriptions etc. but there’s no harm in going through this again in page source.