Andrews Fasteners going Hugo!

I decided to move yet another website from WordPress to Hugo. This time the website has much more traffic than any other “of mines” (the ones that I am managing).

The main reason was speed (but also recent discussion about the environment and impact of technologies on it).

Speed was always the main goal of this website. Even that I made a lot of optimisation on it, including migrating to SiteGround (which helped a lot!), I still struggle to put the website on Green in Google Search Console - Core Vitals, which annoys me a lot!

So much good optimisation works, but Google still does not see that, despite that Lighthouse analysis showing a different picture.

I will not blame WordPress, however it is partly its fault.

Apart from speed, I think a lot about what impact this website has on the environment. The need for powerful servers to serve it just adds up to all the harm that we are doing to the environment.

Fast websites load quickly and reduce the amount of energy that is needed to display them. But that’s only half of the story. This is why I went back to basics and decided to go static with Hugo.

More about this you can read on the company official news post: Andrews Fasteners Limited website going green!

The other reason why I decided to resign from WordPress was security and stability.

Each update of WordPress, WooCommerce and other plugins causes me extra validation work to see if nothing is broken. I don’t have time for that when I need to concentrate on my main job as a Quality Manager.

I proved myself, by migrating other websites, that going static is a good solution.

It involves a lot of work in the beginning (it took me a month of intensive work to finally push it live), but it pays off later on, especially on the security aspect. No WordPress, no risk of hacking using known vulnerabilities, especially in light of recent discoveries.

The whole job wasn’t straightforward. I need to think upfront about what’s currently on the website and see how to replicate things on a static site. Just before I even started my Hugo project I spend weeks gathering all the information on how to achieve what is currently in WordPress version.

I worked with this website since it was redeveloped by a third party back in late 2014/beginning of 2015 and since then I modified it a lot. Because of my significant input move into static wasn’t as much pain as it could be (in theory).

Apart from content and layout (theme), which is easy to move, there were others, more dynamic things like:

• Contact and Enquiry forms;
• Calculators used by our customers to help them select the right product for their construction;
• Search
• CMS to add the ability for editing of the content by people without coding skills;
• Online Shop (eCommerce).

Before I started any work, the only one point from the above concerned me a bit - eCommerce.

The eCommerce part of the website (shop) was based on WooCommerce and payment gate offered by SquareUp (previously used PayPal, but SquareUp is much more cost-effective in a long term).

I didn’t want to introduce another payment processing company like SnipCart, which already provides a guide on their website, how to build a static site with a dynamic payment page. I would like to use what we already use, so I need to reach out to the SquareUp API (before I discover another way).

The last thing that I got in my head was to reduce costs related to the website. I didn’t want to go free, even though this could be achieved, but I don’t mind paying a portion when traffic grows and customers flow. Overall, our website has between 5,000 and 6,500 unique user visits in a month which is not bad.

Of course, up to 50% of this traffic are bots and people trying to hack our website rather than find a piece of useful information on it. After migrating into a static environment I expect to see a significant drop in numbers, especially after a couple of months, when WordPress parts will not be longer indexed in Google and other search engines.

Let’s see, how this all goes…

The site goes fully live on Friday evening, 12 November 2021.

Calculators

I started with calculators that I created using simple HTML forms with minimum user input backed by calculation using formulas in PHP.

The calculators have been very useful not only for our customers but also for our sales staff. They have been able, with its support, to correctly advise customers about what products they need.

To be able to use them on a static site, I will need to migrate them into Vanilla JavaScript which wasn’t a big problem for me. Once I sort new code on one day, I finish next day and they were placed on the website (still in WordPress) to see how they worked.

On PHP-based calculators data entered into the form has been sent to the server to be calculated on page refresh. This was not necessary but yet worked well. Using Vanilla JavaScript all data stayed local, no need to send anything to the server and no need to refresh the page to get a result.

In case somebody has been concerned about the privacy of the data entered, this issue has been closed once and for all.

Once I got my calculators served from ordinary HTML files, it was easy to implement them later on using Hugo Shortcuts.

What’s more important, once users will not see a big difference, they will feel it in speed and the whole experience when using them.

• - Job done.

Contact forms

Before I jumped into “easy” commercial solutions with contact forms and will start paying cash for their service, I decided to give it a try of form solution provided by Netlify. The site originally will be hosted by Netlify CDN hence why not?

Netlify Forms provide free of charge forms integration into your website.

In the free tier, you receive 100 approved submissions (excluding spam etc.) per month and if you need more, then you need to pay for that.

I have calculated over the last months how many filled forms we received from our WordPress (mainly our customers sending emails or giving us a call) page and think 100 will be more than enough, at least in the beginning.

• - Another job done.

eCommerce

The biggest struggle for me, as natively I am not a developer (more self-taught geek), was migrating from WooCommerce (user-friendly interface) into static equivalent with dynamic content using Vanilla JavaScript, JSON and API. Something, that I haven’t had much experience with, but would like to try.

However, with such a solution, I am gaining control on the one hand, but adding extra work to make sure it’s working daily. All payment APIs are changing from time to time and this will need to change with it as well.

This time I decided to take a different approach and use what our current payment provided (Square) is already providing - their equivalent of WooCommerce.

In such a way, I have been able to move a shop to them.

One part of the website will stay dynamic with the need for server behind, but the aspect on security and making sure it’s working well will be pushed into somebody else’s head. One less trouble for me.

The job wasn’t easy as involved a lot of labour. In this instance, I take an opportunity to review all the products and update prices so it wasn’t wasted time.

• - Another point to tick off

Search Form

Even on my static website, I haven’t sorted out a full search facility.

I have been thinking about that a bit but in the end, I decided to go into using someone else to do the job for me. Who will do this job better than… not Google.

I decided to use a search engine that respects the privacy of its uses, so I stick with DuckDuckGo.

The number of information indexed in DuckDuckGo about this particular website was already impressive. As, when finished migration, I maintained most of the important links to the content, I avoided too many 404 errors.

Maybe in the future, I will decide to integrate some different approaches, like this: In-Page Filtered Search With Vanilla JavaScript. For now, I ticked off this from my list.

After some feedback from users, I implemented search natively in Hugo using JavaScript as per post A simple javascript based full text search function in Hugo community. Now everybody is happy and can call this done!

• - Done!

CMS

The reason behind the popularity of WordPress is a fact, that if you knew how to use Word or any other text processing software (like Pages on macOS), then you knew how to add and edit content in a user-friendly editor right from your web browser.

I was in this migration project a bit forward-thinking, where I don’t need to.

I want to be sure, that if somebody in the company would like to add something to the website, they will be able to do this easily without teaching them again how to do this and that. But, as I have been mainly responsible for publishing content of the website (with the cooperation of others who advise the content and helped to make it “readable”) it was not necessary to concentrate on that solution only for one person - me.

As the content of the website is provided in widely readable Markdown format, this can be edited in any compatible app. I can send a markdown file for correction and get it back without the need of introducing something new, something that I will need to explain how to use.

At the end (or rather at the beginning) when I finished building the site with Hugo, I decided to do not to look into that.

However, when the need will come, I got an open option to try and implement into the site. That’s Netlify CMS and it’s integrating nicely with Hugo.

Netlify is not only serving our website, they can do a lot more. Overall if you will look at their website you will hardly say that this is a place where you can publish a website, but more likely an app or more complicated project.

They are developing quickly, but competition as well.

It will take some time before I will see the need for CMS so why waste my precious time? That leads me to the end.

• - “done”.

Here is a comparison between WordPress and Hugo after finishing the migration process.

A fully loaded website, according to Waterfall in GT Metrix, took 1.1MB of data with WordPress whereas with Hugo it’s only 35% of that!