A collection of my thoughts and learnings. Hopefully some of it will help you.

A collection of articles and blogs on various topics that my clients and colleagues may find useful or interesting.

My thoughts

Over my career, I've seen so many website rebuild projects and the one thing that is always underestimated is the amount of work involved in migrating your content from the old site to the new one.

Even if you're sticking with the same CMS, content migration will still be needed in most cases and it can be a tedious and time-consuming job to do manually.

Set aside some budget for a content audit. This should produce a report about which content can be migrated using some form of automated process, which content you might not want to migrate at all and which content you will need to migrate manually.

For most sites the vast majority of content will be blogs or articles and, unless you've used some kind of page-builder for these, your developers can likely write a script to migrate these automatically. There may be other types of content in your site that can be migrated automatically too.

Automatic migration doesn't necessarily mean cheaper. There's a lot to consider when writing automated migration tools such as:

Migrating inline/embedded media files like images and ensuring that the content is updated to reflect the new media location.

Updating hyperlinks to internal content to wherever the new location of that content is (and flagging up broken links).

For the content that can't be migrated automatically, you will need to figure out how much time it will take you to copy and paste the content from the old CMS to the new one, including reuploading any images or other assets, re-linking inline hyperlinks and creating redirects. This can be a long and tedious job on large sites so ensure that you have enough people around to help you do this.

Planning and preparation are key here. Don't let content migration derail your whole project by not investing enough time and money into it upfront.

If your content and URL structure is changing (which it likely is if you're rebuilding your site) then you need to have a plan in place to create redirects from the old to the new.

I have seen businesses literally disappear overnight by not doing this. 

If you don't redirect your pages when the new site launches then you will lose ranking in search engines. If enough of your pages suddenly start returning "404" errors then Google may de-index your site entirely.

It's a really simple task to have your SEO scan your old site and work with your developers to produce a redirect map that can be implemented into your new site from day 1. This will save you a massive amount of pain after launch.

You are going to be changing the way that your users interact with your website. The way they browse and find your content. Hopefully, that change is for the better but you can increase your chances of success by investing a little time and budget in the early stages of the design process to carry out some user testing with the new designs.

This will give you valuable feedback at a time in the projects lifecycle where you can still make changes without incurring a lot of extra costs. Spending some time and money at this stage can actually reduce the overall cost of the project by ensuring that you won't launch something your users hate.

I wrote this article because these three things are the things I see almost everyone gets wrong when planning website rebuilds. They are things that either get left until the end of the project or are forgotten entirely and then rushed in at the end of the project causing delays and additional costs.

Website projects will usually have a finite budget, but sometimes you need to spend a little more time and money upfront to make greater savings in the long term. Putting some of your budget into these things can save you more by the time your new site launches.

Rebuilding a website can feel a lot like moving house, with all the stress that comes with it. In this article, I'm going to look at a few ways you can reduce the stress involved.

Website rebuilds are stressful enough. Here are 3 simple things to save you stress on your next website rebuild.

3 simple things to save you stress on your website rebuild

In my time working in an agency, I've seen a lot of projects and a lot of discussion around how best to plan and run various projects in the agency environment. Distinction's 2020 brand repositioning to the strategy agency that's all about the action led to some interesting discussions and changes in the way we think about and plan for projects.

It's been clear for over two decades now that the old way of planning and managing projects, known as the Waterfall methodology, just doesn't cut it in today's world of high-speed change. The COVID-19 pandemic and the changes that came with it (and continue to come) show us, beyond a doubt, that even the best-laid plans are meaningless in the face of a world that changes so rapidly from one day to the next.

So why do agencies continue to present rigid, up-front plans to clients? Why do clients continue to insist on having a contracted scope and budget for their project up-front? 

In short, businesses want things to be done in a certain amount of time and they don't want to spend more than a certain amount of money to do it.

This means that agency sales teams feel they need to promise clients exactly what they are asking for in order to win the pitch.

This way of thinking from clients to sales teams leads many agencies into adopting a waterfall approach from the start of their sales process and this can make it very difficult to transition into a more agile approach for project delivery since all of the estimates are already seen as "fixed" by the client. What do you do as a project manager or developer when you're asked to produce more detailed estimates and they end up being more than the estimates that sales used to win the project? It puts project managers in a difficult position and invariably ends up in some very uncomfortable conversations with both the agency leadership and the client.

Firstly we need to move the conversation from features and more towards goals. This is a subtle but important distinction to make. A feature is "how it's done" whereas a goal is "the outcome we want". Once the client is talking about their goals the "how we get there" is much more flexible.

We can then begin to refine the client's high-level goals into more actionable requirements. These then form the high-level epics of the project and the next step is to get the people that will most likely be doing the work to give these high-level epics some estimates - but not time estimates.

A good way to estimate these high-level epics, and my personally preferred method, is to use "Story Points" based on the Fibonacci sequence. Get the delivery people in a room (real or virtual) and play a game called "planning poker".

Timebox each epic - 5 minutes for example - and allow the group to discuss it and ask questions to the people that worked with the client to define it. At the end of the 5 minutes, each person that will be involved in the delivery makes a secret "bid" of story points from the sequence below.

In the Fibonacci sequence, each number is the sum of the two preceding ones, starting from 0 and 1. The sequence "1, 2, 3, 5, 8, 13, 21" is commonly used for planning and estimation in software development projects.

Everyone reveals their bid at the same time and if they are all the same that is the estimate for the epic. If there are differences you just discuss the outliers and come to a consensus quickly. Any discussion at this point should also be timeboxed - the idea is to estimate quickly and move on.

These estimates will give you an idea of the complexity of each epic and while these points don't translate directly to time at this point, they are useful in determining where the majority of time will likely be spent.

Once you've estimated all of the epics look for any that have been awarded the highest value allowed in your sequence. These estimates typically come from a lack of knowledge or something that is too broad in scope. Each of the epics at the top end of the estimate range should be discussed separately to determine why the estimates are so high with a view to either getting more information from the client or breaking them down into more manageable pieces. Eventually, you should end up with a list of epics where each epic alone doesn't feel like a big daunting piece of work and you feel like you have all of the information you will need to produce it.

Now that you have a list of well-defined requirements and an idea of how much effort each will require to deliver each, it's time to go back to the client and talk about priorities.

I like using the "MoSCoW" system for this as it helps the clients to prioritise their requirements without getting bogged down in too much detail. Ask the client to mark each requirement as one of the following:

This process helps to define the intended scope of the project. Everything in the "Must", "Should" and "Could" categories should be considered as "in-scope" at the start of the project.

Items in the "Would like to have" category can be kept in the project backlog as "stretch goals" but it should be clear to all parties that those items will not be planned into the completed project or worked on unless everything else is complete.

Prioritising items in this way helps us to understand the order in which features or stories should be completed. Ideally all of the "Must have" items would be completed before any "Should have" items are started, and so on.

No project ever runs to completion without something changing. Whether it's a new requirement, a change in the client's business priorities, delays from third parties or just that one of the requirements ends up being more complicated than expected.

In these cases, the conversation with the client is much easier to start because they've been thinking about priorities all the way through so far. When that new priority comes in or the big "must-have" feature takes longer than expected we can talk to the client about either extending the budget/timeline or dropping one or more of the lower priority items from the project to take account of the change in circumstances.

Since, in an agile project, you'll be talking to the client much more frequently than you would in the old waterfall method, they can be made aware of these things sooner avoiding any surprises towards the end of the project.

It's a fact of business life that clients will want to have some assurances of both when they will get what they're paying for and how much it's going to cost them. In established agile teams it's relatively easy to estimate a timeline for a project based on the team's velocity (number of points completed over time) on previous projects. This is much harder to do in an agency where you may not be working with the same team members for every project.

It's also a fact of software development that there will always be surprises in any project. There's no way that we can know all of the ins and outs of a clients business processes at the start of a project. There will always be things that only come out once we start actually building the project and, most of the time, the project can cope with them but there are those occasions where a feature turns out to be far more complicated than originally described.

The answer is to change the question. Rather than promising fixed scope and a fixed budget to clients, just pick one. You know your client best. Which is more important to them; the budget or the scope?

Make sure that they understand that you will do as much as can be done well with the time/budget available. Things lower down their priority list may need to be dropped from the scope to achieve that. Most clients will be fine with this in the early stages of discovery and development and, if it becomes an issue later, you have set expectations early and at that point, the client can choose to either drop a low-priority feature or add to the budget so that it can still be completed. In most cases they will drop the feature since getting the project to market will be more important.

It's better to get it to market and then improve on it than to never get it to market at all.

The other side of this is where the client must have all features to make their product viable. In these cases, they must be prepared to increase their budget to cover any surprises, or to be more flexible with the scope to allow lesser implementations of their features in version 1. 

Overall, communication with the client is key.

In my experience any project where scope and budget are fixed is doomed from the start. By having both set in stone you only encourage corner cutting and the product you end up with will not be well built and will be difficult to change and maintain in the future.

Do yourself and your business a favour - work with this process and allow lower priority items to drop out of scope if needed. You can always add them in later once your project is live and bringing you some return on your investment.

In my time working in an agency, I've seen a lot of projects and a lot of discussion around how best to plan and run various projects in the agency environment.

Diving into my experiences of agile software development in an agency environment and how agile can be used in an agency effectively.

Agile in an agency

In my profession, I often come across businesses looking to move to new hosting or host a new website. In many cases, I get the chance to talk to them about the different options and help them choose the best hosting for their purposes.

Sometimes though, companies already have their own infrastructure, be it co-location, dedicated servers or some sort of virtualised environment such as Azure VMs, VPS etc. and they are reluctant to even discuss other options after having sunk so much money into staffing, training and the hosting its self.

The trouble is that all of these types of hosting have one thing in common –  they cost you a lot more than you think they do and continue costing you over time. You have to constantly manage:

The operating system configuration and updates (which can also cause you issues)

“Bare metal” backups to restore if something goes wrong

Drivers and their updates (which can cause you issues too)

The web server (IIS, Apache, Nginx, etc) and its configuration and updates

And that’s all before you even get to managing your website(s)!

Sometimes these companies will employ people or teams of people whose only job is to maintain all of this architecture.

Worse still, I’ve had to deal with issues that arise from internal IT and infrastructure teams applying updates to OS or drivers that have then broken integrations with 3rd party APIs or just outright broken the client’s website altogether. These infrastructure teams often have no idea what the websites hosted on the infrastructure are using or communicating with and will often just apply “recommended” updates without adequate testing.

Most companies could achieve suitable (or better) hosting for their website(s) and databases using cloud alternatives and rid themselves of the overhead and headache of maintaining infrastructure themselves.  Better yet, cloud hosting is held to a high standard when it comes to the types of changes that can be made and you will usually be notified of any upcoming major changes with enough time to update your websites or tweak the settings as needed.

For .Net, PHP or NodeJS based hosting you could use a container-based service such as Azure App Services.

The difference between an App Service and a VM? With an App Service, You don’t have to manage the server at all! You can just concentrate on your website and leave the hardware, system updates, etc. to the cloud provider.

In addition, if you need additional power for your website to cover busy periods it is much easier to scale the hosting up and have the app service deploy additional load-balanced versions of your site than it is to provision new servers or VMs.

Backups are a pain to manage with most database systems. The best I’ve ever seen a company set up their database backups is to have nightly full backups. That’s a potential 24 hours of lost data if anything goes wrong. With cloud databases, it can be like having a full backup every minute.

Whether you need Microsoft SQL Server or MySQL, the cloud has you covered there too.

For MSSQL database my go-to service is Azure SQL databases. They provide you with a to-the-minute point in time backups and restoration system all managed by Microsoft.  If you ever need to restore from a backup you just enter the date and time you want to restore to in the Azure Portal and let it do its thing.

For MySQL, a similar service exists called Azure Database for MySQL server. These have a very similar feature set.

If you’re looking to host a WordPress site, using a specialist WordPress host with a containerised environment such as Pantheon or Flywheel can be incredibly liberating. You don’t have to worry about webservers or databases yourself – you can just focus on your website.

Gatsby, Gridsome and other JAMStack built sites

If you’re using JAMStack static site generators then you likely already have a good grasp of the benefits of a fast site. Specialist hosting such as Netlify or Vercel can simplify both your hosting and your deployment processes.

Even if you want to go the route of setting up your own hosting, a simple CI/CD pipeline, some Azure Blob Storage and a CDN are still much simpler than hosting an entire server.

Long story short, stop wasting time, money and people-power on maintaining servers. Instead, leave that to the specialists and focus on making your website deliver a better experience for your customers.

Cloud hosting and container based hosting architecture has come a long way recently and can be a very cost efficient way to host websites, but many businesses continue to spend a lot more on in-house or dedicated hosting systems and architecture.

Stop making hosting hard for yourself!

In the ever-changing landscape of devices and web browsers that your visitors will be using to access your website, one thing remains constant: A fast website is better than a slow one.

In 2020, over 50% of internet traffic was from mobile devices.

Google has taken note of this for some time now in their Google Page Speed  Insights tool, and in the Lighthouse software that powers it. They routinely test your websites speed by using simulated mid-range mobile devices and by recording real-world speed data from your visitors’  devices.

It’s no secret that Google has been using page speed as a  ranking indicator for some time. Indeed, many clients I talk to cite page speed as one of their main concerns.

Stop building your pages on every request!

In  a traditional website, whether it’s powered by a CMS such as WordPress,  or some custom-built solution, every visitor to your site follows this  process to view a web page:

The visitor enters your web address into their browser or clicks a link.

Their browser makes a request to your server for the page.

Your server runs that request through some programming code that makes multiple requests to a database to retrieve raw content and then runs more code to inject that content into some sort of template to produce an HTML document.

Your server then sends that HTML document back to the visitor’s browser.

Out of those 4 steps, #3 typically accounts for between 0.5 and 2 seconds of real-time that your visitor has to wait before their web browser even begins to display anything and every visitor is seeing this on every page load. This is called the “server processing time”, sometimes called the TTFB (Time to first byte).

What if I told you that you could eliminate that time from your visitors’ experience altogether?

Well,  you can, and here’s how; You need to use something called a Static Site  Generator. These are sometimes referred to as JAMStack or SSGs.

Two of the most popular SSGs out there at the moment are Gatsby and NextJS.  Both provide excellent developer experiences based on the React  JavaScript framework but, most importantly, both have thriving communities of developers building plugins and addons to help other developers create stunning, fast websites quickly.

A static site generator is only one-third of the puzzle though. While a static site  generator will do the work of building your website as a package of  static files, you still need two other things:

Some way of editing your content in a place that the SSG can retrieve it.

Somewhere to host the static files that the SSG builds.

Technically,  you can host a statically built site on any hosting you like. You can even host it in Azure blob storage or an AWS S3 bucket.

You could do those things. You would need to create and manage your own build pipelines using something like CircleCI or Azure Pipelines, but it is possible.

Alternatively, you could host the statically generated site with a service that is designed to manage the build process and hosting from start to finish.

Netlify is one of the most established hosts for JAMStack sites. In fact,  Netlify also supports most SSGs, including Gatsby and NextJS, and make it very easy to get a site deployed quickly.

Gatsby has its own offering for hosting which, when hosting GatsbyJS sites is comparable to Netlify.

For next the best choice in my opinion is Vercel as it gives you other features and options with NextJS that are not available on Netlify or any other static site hosting that I know of.

With the hosting sorted, it just leaves you needing a place to write and edit your content.

Content can literally go anywhere that is web-accessible when you’re using a  static site generator. I know developers who will write all of their content in MarkDown files and stick them in a separate git repository for the SSG to pull from.

For most businesses and non-technical users though, my recommendation is always a headless CMS such as Prismic or Contentful.

With a good content management strategy and a developer that understands headless content management, you can not only make the most of your statically generated site but also make your content much more portable.

Portable content is amazing because it means that if you want to rebuild your site in a few years using the next great advancement in website technology you don’t have to worry about migrating your content again as well.

Content migration from one CMS to another is hard and time-consuming and even if you manage to get some automation in there you will always end up with a lot of manual work to do. It might seem daunting to go through all of that with a headless CMS but trust me,  it’s worth it to never have to do it again!

As of this writing, Google is planning to make a core algorithm update in May 2021 that will include a new factor – Page Experience – which means it will affect rankings.

They launched web vitals last year that outlined how they planned to measure this. The key outlines to this appear to be:

Speed (loading, interactivity and visual stability)

Mobile-friendliness (reducing code, browser caching, and reducing redirects).

Mobile  experience (The webpage design should be simple and responsive to  appear attractive on smaller screens. Site structure, too, should be  optimised for mobile.)

While a static site generator won’t solve all of your speed issues, you still need your developer to write efficient code and follow Google’s web vitals when building the front-end of your site, but by eliminating that server response time overhead and making your content more portable you give yourself, and your site, the best possible foundation for speed.

3 things you need for a blazingly fast website

Website builders are becoming more popular and many web developers go to great lengths to trash-talk them out of a fear that they will someday lose their job to a website builder.

My goal with this article is to look at the pros and cons of website builders and attempt to provide an unbiased view so that you can make up your own mind about whether you should use a website builder for your business or employ a  web developer.

A website builder is a company or service that provides you with visual tools that allow you to design and build a website without needing to know anything about the code that makes it all work.

One of the reasons that they have become so popular is that they make it very easy for business owners or their staff (non-developers) to quickly create a  website.

They offer pre-built templates and colour selections to get you up and running quickly.

All you have to do is provide the content and make a few choices about colours and layouts and, of course, pay them a monthly or yearly fee for the services they provide.

If I had to summarise the pros into bullet points, they’d look something like this:

Website builders work very well when your website follows the established designs or patterns that they have catered for. They tend to struggle or become overly restrictive whenever you want to do something a little bit different.

In business, it’s often that something different that sets you apart from your competition so when you start trying to make it work in a website builder it can become incredibly frustrating.

Website builders often struggle with performance too. Their platforms cater to a  lot of websites, all sharing the same resources in most cases. This can mean that traffic spikes on other sites hosted by them can affect the performance of your site. In addition, the templated nature of the website designs they offer can often leave you with a site that performs poorly on page speed which can affect your search rankings.

In addition, just because they make it easy to build a website that doesn’t mean it will be a good looking website or that it will provide the best user experience for your customers. Website design and development is often about more than just code and even if you can get away without a  developer you still need someone that has a “designer’s eye” to build something that looks good and provides the excellent user experience that will keep your customers coming back.

Not very flexible. You have to stay within their pre-defined templates’ limits.

No code doesn’t mean you don’t need to employ someone to help you build the site.

I don’t have one. The conclusion is up to you.

A  website builder might fit your needs perfectly, or provide you with an easy and simple way to get to market quickly. You might find yourself employing a developer further down the line to rebuild your site with more bespoke features and integrations, but you need to get there first.  If this sounds like you then a website builder might just suit your current needs, but you can make that decision now, knowing what you’re getting into.

You might have read through this and decided that your needs are more than a website builder can accommodate. That’s fine too.

This post was not about promoting a website builder or about talking you out of them. It was to give you the information to make an informed decision.

If you’ve got this far and you’re still unsure, I’ve included some of my opinions in the bonus thoughts below.

Website builders, in my opinion, will never replace designers or developers. There will always be a place for both.

Whenever a business needs to integrate their website with their CRM, warehouse management system or manufacturing processes developers will be needed.

Likewise, using a website builder doesn’t mean you don’t need a designer either.

I’m a big believer in using the right tool for the job. If a website builder can get you to your goal quicker, then maybe it is the right tool for your job.

Is a website builder the best choice for your business?

The most common way of managing content on a website is with a Content Management System or CMS.

Whether you’re building a completely new website or updating an existing one,  the choice of how your business will publish pages and news content on the site will have constant and lasting effects on your business for the next 5 or more years.

There are many content management systems available today and it can be daunting to try to select which one will power your website for the coming years.

You may already have one in mind. You may have heard stories about certain ones, both good and bad. I’m a big believer in using the right tool for the job at hand.  I’ll ask you to now put those preconceptions aside and ask yourself five simple questions.

How many people will use the CMS to edit or publish content?

Do you require that content is written by some people but is reviewed by other people before being published?

Do you sell products or services online (customers can buy and pay on your website)?

I’ll talk through each question and the choices it presents below. Then at the end of this article, I’ll offer some thoughts on other things you might want to consider too.

1 – How many people will use the CMS to edit or publish content?

Some content management systems have limits on the number of user accounts or the number of users that can be logged into the system at a given time. If you need a lot of staff users and editors or expect to have a  lot of visitors that log in to your site, then you may need to consider this when choosing your CMS.

This type of restriction is common amongst headless content management systems.

2 – How often will you publish new content?

For most traditional content management systems, how often you publish new content doesn’t matter too much. When you publish your content it becomes available on the website immediately.

With headless content management systems though, you might opt to build your website using a static site generator such as Gatsby or NextJS. These systems can blow away the competition when it comes to site speed and performance but they do this by removing the server-side component.

Where a  traditional CMS will need to make queries to a database every time a  visitor loads a page, static site generators pre-generate the pages in such a way that the only thing left for your web server to do is serve the static HTML file. This greatly reduces the page load times but the tradeoff is that when you make a change or publish new content there is a  delay between you clicking that publish button and the new page being visible on the live site.

This delay can be anywhere from a couple of minutes to 30-40 minutes depending on the site generator, the hosting and the amount of content you have.

3 – How much content will your site have?

Some content management systems limit the number of pages you can have based on the license or tier you choose to purchase. This can apply to both headless and traditional content management systems.

4 – Do you require that content is written by some people but is reviewed by other people before being published?

In content management systems this is often known as “workflow”. Some systems allow you to set roles for your users and configure approval steps that content must pass through before it is allowed to be published.

This can be useful if you have a lot of content editors/creators and need to have oversight on what is published. It can also be useful for larger content teams where content needs to be checked by a proofreader or your legal department before it can be shown to your visitors.

If you are the only person that will be managing content or you have less than 3 people writing content, you probably don’t need this.

5 – Do you sell products or services online (customers can buy and pay on your website)?

If your answer to this is “yes” then it will greatly reduce your choices.  In my experience, there are only two well-supported options for e-commerce websites these days; WooCommerce or Shopify.

Getting a good page load speed on your website is not completely dependant on which CMS you choose. It’s more dependent on the design and how the front-end HTML, CSS and JavaScript is implemented.

The CMS does play a part in how easy it is to get a good page speed though.

As my recent post about increasing the performance of a WordPress site shows, WordPress can be made to give “ok” performance for most sites.  Other content management systems such as Umbraco or Kentico can also give fairly good site speed performance.

If you’re looking for something that scores well (80+) in speed metrics such as Google Page Speed Insights then you may want to consider a headless CMS along with building your site using a static site generator.

When reading some of the points above it may seem that headless content management systems are worse than traditional ones on some points.

The truth is, they have different objectives. A headless CMS will really shine if you want to have a single place to manage all of your content but the content is used in lots of different places. Maybe you have multiple websites that all need to share some content (such as meet-the-team pages or FAQs) but not everything. A headless CMS will let you keep and manage everything in one place and, most importantly,  makes your content 100% portable.

Portability means that if in a  few years, you want to build a new website or change your existing website to use new technology, you don’t need to worry about migrating all of your content again. That new technology or website can just link up to the headless CMS and use the content from there.

Overall,  headless is a different way of thinking about content that separates it from how the content is displayed. Once understood, this is a good thing as it focuses your content writers on writing good content rather than having them spend time tweaking page designs and layouts. Leave that to your designer.

5 things to consider when choosing a Content Management System for your business

Most clients that I deal with specifically ask for WordPress. It’s the most popular CMS for small businesses and despite my past reservations about the software I decided it was about time I took a  deeper dive into it. In this article, I will share with you the top 5  things I’ve done on this website to improve performance.

My previous experience with WordPress has been that it has poor performance illustrated by low scores in Google Page-Speed Insights, GTMetrix and other performance checkers.

When clients ask me to look into the performance issues I normally find that they are caused by page builder plugins or by having lots of JavaScript firing off above the fold when the page first loads. In most cases, this problem is usually inherited from an “off the shelf” theme.

So that I can better serve my clients, and for my own curiosity, I wanted to see if a WordPress site could be built using a page builder and still perform well.

For this experiment, I decided to rebuild my own website in WordPress using the Elementor Pro page builder.

I’ve listed below the key plugins I used to tune the performance of this site. I do have others, but these are the key ones for performance.

Asset CleanUp is used to disable several default features in WordPress that I’m not using on the site, such as comments, emoji, XML-RPC and oEmbed. It also allows me to optimise the loading of fonts by preloading them.

Autoptimize and Async JavaScript work together to optimise the delivery of HTML, CSS and JavaScript.  They will combine files and minify them to provide optimised asset payloads to the browser and reduce render-blocking scripts and styles.

Cloudinary is used to host images from my site. Their service provides a CDN as well as image optimisation & manipulation services. They have a free account that is quite generous and their plugin is also free.

Disable Comments does exactly what the name suggests. It disables the WordPress comment system. It also disables all of the features, JavaScript and APIs that the comment system uses which results in less code to load and execute and a more secure system.

Elementor and Elementor Pro are my page builder plugins of choice. I find that they strike a good balance between usability and flexibility.

jQuery Updater simply updates the version of jQuery used on the site to the latest version. This helps ensure that we’re using the most optimised version and that there are no known security vulnerabilities included.

Lazy Load Background Images for Elementor is another simple plugin that does just what the name suggests – it allows background images on Elementor sections and widgets to be lazy-loaded in the browser as the user scrolls down the page. This can have a huge impact on a page’s performance.

Rank Math SEO  is used instead of the more well known YOAST SEO because Rank Math can do everything YOAST can do (possibly more) has faster performance and has the ability to turn off features I’m not using, which improves performance.

WP-Optimize is disabled most of the time. I only enable it to do periodic maintenance on the WordPress database, such as removing tables left behind by old plugins or cleaning up auto-drafts, post revisions, etc. This helps the site query the database more efficiently.

The choice of base theme is important when it comes to performance and the key is to choose a theme that is as bare-bones as possible. There are several suitable  themes available:

Since I’m using Elementor I decided to go with the Hello Elementor theme. This is a very basic theme designed for use with Elementor Pro.

WordPress and code performance can only be as good as the hosting it uses. In my career one thing has always been true in regards to hosting; You get what you pay for.

With that in mind, I decided to host this site with Pantheon. They have an excellent global CDN and caching architecture which means I won’t need to configure any page-caching plugins.

The page-speed scores for this site look pretty good compared to many WordPress sites I’ve worked on and I  will be continuing to look for ways to improve them further.

Overall, I don’t think WordPress will win any contests on speed, but it is good enough for most sites.

If you’re looking for a blazing fast website experience for your visitors with a nice admin experience for you and your editors, I would recommend Gatsby or NextJS along with a headless CMS, but for most  sites, WordPress can be made to be “fast enough” if you follow five  simple rules:

This is the number one rule for a reason. If you don’t have good hosting, nothing else you do will make much difference.

2 – Optimise your “above the fold” content

Don’t use anything “above the fold” that uses JavaScript if you can avoid it.  This includes things like sliders, carousels, fancy text effects and even some animations.

JavaScript changing things above the fold will increase your “First Contentful Paint” time, lowering your page-speed score.

3 – Perform regular maintenance on your database

Blog articles