Let’s assume that you sometimes help companies with strong global brands have a decent technical web presence. What would you consider, from a tech hygiene perspective, when updating your own little website?

A couple of weeks ago, I wrote about how we, as shoemakers, are dealing with our own shoes regarding alignment between goals and metrics. You find the text here (in Swedish):

https://www.linkedin.com/pulse/alignment-mellan-syfte-mål-och-mått-jimmy-nilsson

Today, I continue with that mission with regard to our updated web (https://factor10.com). As shoemakers, what do we have to fix?

I do realise that a website is no better than its content and that’s what really counts. That said, the technical hygiene also needs some attention otherwise it will affect the content readers negatively. Below you will find a few fairly easily used tips for how to improve the technical hygiene of your website.

But before going over to the tips, here are just a few more words about our main character of the day.

What’s the problem with the shoemakers?

Actually, I don’t think there is anything wrong with the shoemakers. On the contrary. Well, of course the kids of the shoemakers should be taken care of, but one way that is done is by having external focus on the shoe buyers. Providing excellent service and quality to the customers is a great way of taking care of their children.

If we move over to the topic of websites… There is only so much time for internal matters such as your website typically is, and since content is king, of course it should come first when there is time over from client work. After fixing the content, maybe also do some tech fix.

I’m rooting for the shoemakers! :) That said, over to the tips. Hopefully you’ll find some of them useful. The first one is…

Tip 1: Check that you have good performance, accessibility and SEO

There’s a multitude of tools out there to check that you have decent performance for your site and that you don’t cause unnecessary friction for consuming your content or finding it. As a tiny consulting company for software development, we don’t rely on search engines for getting new projects, but there is still little reason not to take care of performance in a reasonable way.

Since Google will punish your ranking if you fail in those aspects, they provide a tool that is a good starting point for getting an overview of how they see you are doing. You can find the tool here:

https://pagespeed.web.dev/

Try it out on your own website! Where 100 is max, I reckon 90+ for performance is OK.

Of course this is not a one-off activity because not only will your numbers be affected by changes made to the site (including content) but Google updates their criteria from time to time. Therefore this should be measured on a regular basis (with automation) so as to be proactive about problems cropping up.

In 2020 we had a breakfast webinar on the performance subject which I still think is relevant:

Web Site Performance - Per Rovegård - 2020-11

Tip 2: Not capturing personal information

We have no reason to capture personal information about web visitors, so we don’t. Instead of using Google Analytics, we use Plausible (https://plausible.io) to only gather information about our visitors on an aggregated level. In this way we don’t have to ask our visitors for consent with an annoying popup.

We think it’s reasonable for people to be able to browse websites without unnecessarily revealing identifying information about themselves. Not sending, say, information about Europeans to the US is also in accordance with European law. This leads us to the next tip…

Tip 3: Host in the EU if you’re an EU company

Very much on a hygiene (and actually legal) level, we don’t want to send information about visitors outside of the EU. One easy piece of that puzzle is to host your site in Sweden, for example (and in a Swedish company).

If you are interested in how to think about personal information in the EU, we have hosted a couple of breakfast webinars on this topic. You find them here (in Swedish):

Tip 4: Four eyes content updates

We are strong believers in pair programming and/or pull request reviews for increased quality and knowledge sharing, say. We believe that the same principles also apply for content work on websites.

The content of our updated website can be created/updated with markdown and ordinary git pull requests which are reviewed and approved before they are automatically deployed by build pipelines.

Tip 5: Continuous Integration/Continuous Delivery (CI/CD)

We wouldn’t dream of manually deploying code changes to production. Why do that for content changes? Instead, use a pipeline for taking care of the deployment of those changes too.

The pipeline is also a great place for automatically executing checks. If a problem happens once, a check should be added to make sure the same problem never causes a negative effect again.

Further on, the pipeline is useful to move execution time from when a user visits a page to when the code or content of the page is changed. That means to move from dynamic pages created just in time, to static pages created after a change.

Tip 6: Paying back when using open source

We are big fans of the open source community. When we benefit from open source tools, we think it makes sense to pay back. Some of the open source tools (such as Plausible) were used in a managed manner, so we we’re paying for them that way. On the other hand, with 11ty (https://www.11ty.dev/) we donated a small amount (https://opencollective.com/11ty).

Our company’s design of having a target of 80% invoiced work means the consultants are able to spend work time on open source projects as a way of achieving what we call “personal exposure”. That’s of course a very powerful way of giving back a lot.

Tip 7: Make it harder for malicious actors

Even though we have very few visitors to our website, we don’t want those people to have their safety breached and certainly not due to our site. Therefore we monitor security threats and deal with them when they crop up.

We also use tools to check for common risks. Again, automation is your friend so that your checks aren’t a one time thing, but something that is done on a regular basis and automatically.

The four eyes content updates also help here, making the risk smaller.

Tip 8: And iterate!

After we published the updated website, we used https://webperf.se to get a more thorough review than just through Google’s PageSpeed Insights. A problem well-stated is half-solved. We started with a total grade of 4.36 and, after fixing a few easy things, went up to 4.68.That step took around an hour. My point is that it’s usually easy to quickly fix low hanging fruits. The report mentioned a few weaknesses that we disagreed with, so we skipped them. For instance, we got a lower score since our 404-page is not in Swedish. (Webperf has a mainly Swedish target group, in our case though, and we think that since the site is in English, the 404 page shouldn’t be in Swedish.

We also got a question whether we are fulfilling accessibility to a level of AA for WCAG 2.1. We thought we had a decent level for accessibility, but we had a closer look with https://pa11y.org/ for all the pages and found two contrast problems on one page. That was fixed in a matter of minutes. According to the accessibility expert, we do fulfill AA for WCAG 2.1.

What about the shoemakers?

Going back to shoemakers, it’s always a risk deciding to take care of stuff for yourself which is similar to what you help clients with. One trick might be to take external help to avoid that trap. Therefore we set up a tiny team of our people and external consultant Peter Antonius to do the development of the site.

A fun story is that when the updated site was starting to take shape, we checked performance. While starting the check, I said that I would buy everybody in the company a bottle of wine if the performance didn’t need to be improved in some way. For as long as I can remember the first performance measurement in every situation has always been like that. Not that I was worried, as it’s often quite easy to do the first two performance improvement iterations and get good effects. This time I was totally wrong, the performance numbers were 97+ at first measurement. I have bought wine, and Peter will get two bottles, since he has pulled the most weight. :)

Final comments

These were a few tips on how to improve the technical hygiene for a website when there is time to focus on such things. What do you think should be added?

Finally, is our updated web technically perfect? Of course not! But we do strive for excellence, so when we find something that needs to be improved and we find the time, we will fix it.

This article was originally published on LinkedIn. Join the discussion and read more here.