18th August, 2022
Intro
I have to admit, I haven't made a lot of time recently for "web stuff" out with work. Back when I was a senior developer (and had no kids) I used to spend a bit of my own time on prototypes of ideas I had for the day job, I really enjoyed the creativity. That's what I love best about the web, the act of creation. It is imagination come alive in digital form. It has been 10 years since I left Allsaints, you can imagine how much of the site has changed in that time, but I can still look at the site and see features I created. Ideas that popped in to my head, I quickly prototyped and demonstrated to the business and more than a decade later they are still there, so that's a pretty good return on investment!
But times change. My career path took me away from development. I was a competent developer, never a rock star, but my real interest was in the "business of websites", what changes could and should be made to a website to make it more effective? One of the reasons I joined Schuh was because I was looking for an opportunity to use my technical knowledge about how websites work but to have an even greater say on the roadmap. Not just the list of projects on the roadmap but to have a clear view as the quality of implementation of those projects.
With lack of time spent on web development, my back-end expertise has become a bit rusty. However, somewhat ironically, my front-end skills are better now than they were when I was a developer, as back then I was mostly focused on databases, servers and back-end code execution. While at Schuh I got much sharper on the front-end of web development, not for actually building sites but I have a real interest in web performance and front-end skills are a must if you're to make a website as fast as possible.
I tinkered with a few bits and pieces but never had the chance to dedicate much time to it. I occasionally built demo scripts to illustrate a particular solution or approach, for example a placeholder image concept or making the case for optimising SVGs or illustrating to a payment provider why part of their fraud detection tool was slowing down the checkout. Between having two young kids and building an extension on the house, building my own website was never a priority.
Time for a change
I'm 46 this year, and I'd describe my mid-life crisis as "taking stock of what is important to me and pushing myself physically and intellectually to achieve more". I made the decision on the day before my birthday that I wasn't happy to slide slowly in to middle-age unfitness and increasing weight, so I started running, which you can read about here: How and Why I started to run. I have been able to make good progress with my running which I think has been an incredibly empowering experience. That empowerment has also given me a mental kick up the ass and made me realise that I was ready for a fresh challenge at work.
What has this got to do with your website, I hear you ask?
Well, I thought a change of jobs was as good a reason as any to get back to doing some web development in my spare time. If I'm changing jobs, I'll need to update my CV, and what better way to illustrate that I really do understand websites than to build one to expand on my CV content. It would also be a great opportunity to brush up on some skills.
Website Priorities
In order for me to consider the site a success, there are a number of boxes I want it to tick:
- It must illustrate my skills and experience to potential employers/clients.
- It should be visually pleasing, however I'm no designer, so there are limits on this one...
- It must be well executed. This means:
- The HTML must be valid and semantically correct. And beautiful.
- The CSS must be valid.
- It must be accessible.
- It must be very fast.
- It must be very SEO friendly.
- It must get 100% scores in Lighthouse, desktop and mobile.
- It must be truly responsive, working well on all screen sizes.
- It must be secure.
My Approach
Going for a framework or pre-built CMS was never an option. To tick all the boxes above, I was going to have to hand-code it. It makes sense for a small site like this for it to just be plain HTML, but this approach would not necessarily work for everyone. But if I want every byte to be as I intend it then it really is the only option. I can write HTML almost as quick as I can type a document in Word and it means that I'm using exactly the HTML tags I intend. If you look at the source on something like Neil Patel's website, for example, which is built on Wordpress, the HTML is a mess, with mediocre Lighthouse scores (even in the SEO category). That's just typical of the output from all major platforms, and without a lot of work they would not meet my criteria above, if it could be done at all.
This site is an opportunity for me to put all I know about best-practice in to practice. And this is why I would advocate anyone who works on optimising websites to do the same. Speaking as someone who talks to a lot of vendors and third-parties, who claimed they could make my businesses website better, the first thing I do when they get in touch is look at their website. If they can't get their own website to be great, then I have no confidence that they could do any better on my business's website. Medice, cura te ipsum!
While the hand-rolled approach is not feasible for a large website, what I would still advocate is the attitude. Do not accept "good enough", set the bar high. Attention to detail is what separates mediocre websites and great websites. Learn how high the bar can be set.
My Learning Platform
Another big motivator for me when I decided to build the site was a chance to improve my skills. While my HTML skills are not bad they could be better, there are newer techniques which I'm not familiar with. This site is a great opportunity to play. Related to that, I'd like to improve my SVG skills, for no reason other than "just because".
But my two key areas I really want to focus on are Google Tag Manager and Google Analytics 4. I've dipped in and out of GTM over the years, but the product has moved on massively. I'm a heavy user of Google Analytics, specifically Universal Analytics. But I'm not yet familiar enough with GA4, and it is so very different to UA.
It is also a chance for me to improve my SEO skills, I have used SEMRUSH a bit in the past, but I want to take the chance now to properly get in to it.
In Summary
This website is small, and very new, and still needs a lot of polishing. But I'm really happy that I have put some time in to it to get it off the ground. And I'm enjoying writing the content.
If you at all work in Digital, I would strongly encourage you to learn how to code your own personal website.
Some technical notes
For those interested, in no particular order, here are some of the technical implementation details.
- The site is hosted by Fasthosts on a Virtual Private Server.
- SSL from Let's Encrypt.
- I check HTML markup validity using the W3C Markup Validation tool.
- I check CSS validity using the W3C CSS Validation tool.
- I use the WebAim WAVE accessibility evaluation tool.
- I use Webpagetest to benchmark my site speed
- I use Chrome's Lighthouse tools as a first-pass check for speed, accessibility and SEO.
- I use the amazing and free Squoosh app to compress all my images
- The site uses Google Tag Manager for tag deployment.
- Currently the only tag deployed is for Google Analytics 4.
- I use Search Console to look at crawl stats, errors, etc.
- I use SEMRUSH's excellent Site Audit tools to have a site-wide view of my SEO implementation.
- I have implemented a fairly strict content security policy, the only external calls on the site are Google Tag Manager and Google Analytics. I have also blocked all iframes.
- So far I have avoided the use of media queries, instead electing to use viewport width-relative dimensions in a lot of cases to allow the site to flex between viewport sizes. I did this to hopefully reduce the CSS complexity, but also to make it more flexible for all viewports. It also reduces byte count.
- Some site speed specifics:
- As mentioned, this is a static HTML site, so no server-side code needs to execute before Apache initiates the response. However, even if I had built it in PHP/Python/C#/Java I would have put systems in place to cache pre-rendered HTML pages, I've done this in the past using memory caching. Anything dynamic could then be loaded later. Dynamic sites don't need to be slow.
- It is a text-heavy site, which is inherently faster than one with dozens of images. I elected to keep most of the image bytes to the backgrounds. The layout does not depend on them, the browser can crack on and start rendering before the images arrive. They could not arrive at all and the page would still be usable.
- Images have been compressed as much as possible, and on the big background images I have tried to select images that would compress well, or adjust them so they would compress. This means choosing images with some out-of-focus areas, and with as few hard lines in them as possible.
- I elected to use modern image formats which typically have better compression ratios. I did not include any fall-back formats for older browsers, as the images are not critical to the function of the website.
- No CDN has been used for the site, all content is delivered from the same host, this saves on the overhead associated with connecting to a new domain. And would be overkill for this site.
- I have enabled HTTP/2 on my server.
- As I'm using HTTP/2, I thought I would also implement
HTTP 103 Early Hints, while it is not yet widely supported by the browsers, it is the replacement for HTTP Push. I want to hint to the browser that it should start downloading the main stylesheet ASAP. I discovered that there was a bit of an issue for iOS Safari users, they weren't getting the external stylesheet so the page was unreadable. I have added some logic to only use the feature on Chrome. - I have enabled OCSP Stapling in Apache, which eliminates a request to check for SSL certificate revocation.
- The site has a preconnect/preload/prefetch strategy. I am anticipating that most people will land on the home page, so it has some different code than all the other pages. But first of all, in the HTTP response header there are preconnect links to Google Tag Manager and Google Analytics, telling the browser to initiate the HTTP connections to those domains as they will be needed. Then there is preload link to the homepage main background image, this tells the browser that it is of high importance and it should prioritise it. I tried omitting this as I have a <style /> block at the top of the page with some critical CSS, which includes the background image, but that reduced the priority of the image. There are then prefetch links to the background images used on the rest of the main pages. The browser considers these low-priority, and will not use bandwidth necessary for the current page load. But they do make loading the next page considerably faster. I have done the same on the main blog listing pages, prefetching the backgrounds for the last three blogs.
- I send charset encoding and language HTTP headers, as this can improve rendering time as the browser doesn't need to wait and parse the response body.
- The site also has a CSS strategy for performance. Firstly, I have tried to use browser-default behaviour wherever possible, it reduces bytes, is highly accessible and is easier to maintain. At time of writing, the CSS file is only 846 bytes and contains most of the style information. But not all. As mentioned above, every page has a small <style /> block at the top. This is for a) critical styles to accelerate the rendering process and b) where a style varies per-page. A good example is the main background image, this is different for every page so there is no point in putting it in a cached CSS file.
- Speaking of CSS, I have tried making it asynchronous, using the
media="print" onload="this.media='all'"technique. It improved the start render by 0.1s on mobile but introduced a larger layout shift. I could have inlined a lot of CSS, but it was getting to the point of not being worth it. - The only JavaScript that is on the site is for Google Tag Manager. The classic trade-off between valuable data and performance impact. However, the impact is marginal on a fast 3G connection this slows the full load of the site down by only 0.05s, well worth it. I have placed this at the bottom of the page, which isn't what Google recommends, but the page loads so quickly it should have zero impact on data collection.
- I have chosen not to use any custom fonts. Some may argue that this looks a bit boring. I don't think there is a right or wrong answer on this one. There are some workarounds I could use, I'm just not convinced it is worth my time.
- The only other thing I could do is spend more money on hosting. Apache is running well, doing its bit in 1500 microseconds - the benefit of just serving static HTML. The rest of the hosting is fine, there are faster options out there but it is just not worth paying for them for a personal blog. I think the site is pretty much at its speed limit.