Blog
Przegląd WordPressa

How do I perform a periodic review of WordPress?

Work on the website based on WordPress does not end after the completion of programming work. Everything is constantly evolving and WordPress and its ecosystem are no exception.

That’s why it’s worth doing a periodic review of your WordPress from time to time – especially if you earn money from your website.

Benefits of inspections

Let’s start with what such periodic page views can give you:

  • optimize your website,
  • you will eliminate unnecessary elements of the website,
  • increase the level of security of the website and its users,
  • you will detect in advance potential problems that could lead to a website failure in the future,
  • increase your chances of a better position in search results,
  • identify areas that need improvement or may work differently.

How often do I need to have an overview?

I believe that the frequency of reviews should be appropriate to the importance of the site for your hobby/business and the number of changes that are made to it. However, the minimum frequency is, in my opinion, twice a year – it’s the equivalent of spring and autumn orders.

We are, of course, talking here about websites that are rarely modified or run on a non-profit basis. In the case of more complex websites, you may find that you need to do a much more frequent review. In some cases, you will find that some of the elements of the review need to be done even every week.

What makes up a review of a website based on WordPress?

The full periodic review should consist of the following elements.

  1. Visual tests, aimed at checking whether the website looks and works properly in popular browsers and mobile devices,
  2. Functional tests to determine whether all key elements of the website are working properly,
  3. Analysis of website performance – thanks to it you will detect elements that slow down your website and may reduce its position in search engine results,
  4. Analysis of installed extensions – will allow you to detect unnecessary functions and speed up the operation of the website and increase its security,
  5. Error analysis – this is an element that will allow you to detect problems that are not yet visible to the naked eye, but they may let you know about themselves in the future.

In the case of small and simple websites, some elements of the review may not be necessary, although in my opinion it is worth doing them all twice a year if you earn money on your website.

Visual tests

Recommended frequency: 1-2 times a year.

Attention: Visual tests can be combined immediately with functional tests.

Theoretically, you do these tests quite often – depending on how often you visit your own website. However, there is a problem with this form of testing – you usually do it on one browser and one mobile device.

As a result, you may have no idea that your website is not working properly on other browsers or devices.

You should also remember that browsers receive updates every few weeks, and this entails the risk of errors that may not have existed at the time your website was put into service.

How to prepare such tests?

Start by preparing a list of subpages that are so different in appearance that it is worth to test them separately.

For example, it would be for a blog:

  • Home page
  • Category page
  • Page of the entry
  • Search page

In the case of the entry page – choose the best entry that uses as many typographic elements as possible offered by the theme.

Then you need to access various devices and web browsers.

I personally test the pages on:

  • Google Chrome,
  • Firefoksie,
  • Safari,
  • Microsoft Edge,
  • iPhone,
  • iPadzie,
  • Android phone from the average price range,
  • tablet with Android

The above range of browsers and devices can be extended or limited on the basis of statistics of your website. For example, it may turn out that a large part of our users use Internet Explorer 11, and for a change we practically do not have users using iOS.

Is it possible to test without test equipment?

If you’re not a professional web developer, it’s quite likely that you don’t have access to all the browsers and devices you need.

In this situation you have two options:

  1. Based on the courtesy of friends who have access to missing devices and browsers,
  2. The use of services that give access to testing websites on various online devices:

Unfortunately, online services for such tests are quite expensive due to the infrastructure required by such tests.

From my observations it appears that:

  • Safari on macOS in responsiveness mode quite well reflects the bugs that appear on the iPhone and iPad,
  • Chrome in mobile device mode, like Safari, allows you to spot many problems that may occur on Android devices,
  • the most problematic for testing are the problems on IE 10-11 due to disastrous development tools.

How to perform visual tests?

Once we have a full list of subpages to visit and a list of browsers and devices, as well as access to them – we can go to testing.

This part is unfortunately the most time-consuming and tedious – we have to visit each of the subpages on the list in each of the devices and capture all potential visual problems.

It is worth remembering that in the case of browsers on computers – users use different screen resolutions, so it is worth experimenting with changing the size of the window and watch if problems do not occur within a certain range of screen width.

Attention: Visual testing is best performed in a browser with incognito mode and adblock turned off. In this way, we will simulate better what you see when you visit our site for the first time.

When testing different resolutions, the development tools available in each browser will be very helpful:

They can also help you find the causes of problems.

The result of our tests should be (let’s hope the shortest possible) a list of corrections to be made to the website. Some of them may be insignificant enough to be ignored, while others may require an immediate response because they make it very difficult or even impossible to use the site.

Functional tests

Recommended frequency: it depends.

How to prepare such tests?

For each of the subpages it is worth to list the important functions, worth testing, e.g:

  • operation and behavior of the main menu,
  • the operation and smoothness of the animation (if any),
  • action of interactive elements (if any): shopping baskets, sliders, banners to encourage interaction, etc,
  • elements integrated with external services or infrastructure elements: contact forms, Disqus comments, newsletter subscriptions, etc.

Remember: although the menu works on the home page, it does not mean that it also works on the contact page, for example. It is worth to test the common elements on several subpages.

How to perform such tests?

In fact, everything here looks the same as with visual tests, so it is best to perform visual tests together as much as possible. Thanks to this we will avoid tedious overlapping through the list of subpages 2 times.

The result of the tests, as in the case of visual tests, should be a list of things to correct/repair.

What else is worth checking out?

If you use services such as logging in via Facebook, Google reCAPTCHA or Google Maps, it is worth checking whether the version you are using will not stop working in 3 months.

For example: reCAPTCHA version 1. ceased to work in March this year and Google Maps after the announcement of a new price list on many websites ceased to work and show the message “For development purpose only”.

Analysis of page performance

Recommended frequency: 2-4 times a year.

The speed of the website is one of the factors taken into account when determining the position in search results.

In addition, the speed of loading the page has a huge impact on the conversion rate.

How to analyze website performance?

It is advisable to test key subpages in several tools:

Based on the results, it will be possible to determine whether there are performance problems with the site and what to pay special attention to when fixing them.

Some of the problems can be fixed quite easily – for example by installing plugins such as Autoptimize, which will compress HTML, JS and CSS resources and improve our results in the above tests.

However, some of the problems may require programming knowledge or action on the part of the server administrators.

Why is it worth analysing the performance of the website from time to time?

There are many reasons, let me quote 3 examples of situations that may lead to a deterioration in the performance of the website after the website has been published on the Internet:

  1. We have installed a plug-in that slowly collects large amounts of information in our database – this can lead to performance problems, for example after a year,
  2. We make changes to the theme and install new plugins – some of these changes can be made without affecting the performance of the site,
  3. The team was joined by a new person who doesn’t know that placing 5000×3000 pixel images on the website and without passing them through compression tools such as TinyPNG is a bad idea.

Analysis of installed extensions

Recommended frequency: 2-6 times a year.

WordPress has two types of extensions: plugins and themes.

In the case of motifs the matter is quite simple – we make sure that:

  1. Always have only one theme installed,
  2. Have this only motif always up to date.

In the case of plugins, the matter is more complicated.

How to review plugins?

Go to the plug-in page in the cockpit and then:

  1. Make sure that all plugins are updated,
  2. Remove plugs that are switched off,
  3. Turn off and then remove plugins that are no longer in use,
  4. Think about whether there are no plugins on the list that are only seemingly necessary, but actually do not add value to our website and its functions..

Optionally we can manually verify whether all plugins used by us are still in the WordPress repository – unfortunately WordPress will not inform us that a plugin has been removed from the repository, and the reasons for such removal may be different and may endanger our site.

An example of a plug-in removed from the repository (in this case due to abandonment of work on it) is the No Longer in Directory plug-in, which ironically was used to detect this type of removed plugins.

In addition, it is worth checking if any plug-in does not delay the loading time of our site too much, although this should come to light at the stage of testing the performance of the site thanks to the Query Monitor plug-in.

Error analysis

Recommended frequency: it depends.

It is worth checking once in a while whether anything wrong happens under the mask of our WordPress.

Errors that appear on the pages can be divided into two groups:

  1. Server-side errors,
  2. Browser-side errors

In the case of errors on the server side we usually find them in the error_log file in the root directory of our website.

This allows us to discover errors that occur, for example, only in certain users, or only in specific situations. Thanks to the analysis of error logs we can detect such problems in time and fix them.

Learn from your administrators how (and if at all) error logs are stored and how to access them.

As far as browser errors are concerned, it is best to use the development tools of a given browser for analysis.

Sometimes browsers also display warnings in the console to let us know that certain features or elements of our website are currently working, but may stop working with one of the subsequent browser updates.

Let’s summarize

A website is a living organism and over time it is exposed to unplanned problems and errors. That’s why it’s worth spending several minutes to a few hours on its review once in a while (adequate to the complexity and business value of the website). This will allow us to avoid many problems and discover errors, the existence of which we might not have been aware of at all. And sometimes simple errors can be very expensive.

Stay up to date

Information about new articles and topics related to servers and WordPress on your e-mail.

Add a comment!