I thought I would show my old website klu.io as it is about to be retired in the coming weeks but it has some interesting features I thought you all might like.
Unfortunately (for the site) just as I "finished" it (as it isn't finished 😋) a great opportunity presented itself and the site got forgotten about.
Every few months I pop on it and try to improve stuff (but normally end up breaking more things than I fix!) but other than that it has sat "unloved" for almost 2 years 😪
When I launch my new company and website in the next couple of weeks it will no longer be in use (I might leave it up for posterity but I won't be monitoring it anymore) so I thought I would give it a proper send off and see what people think of it.
I have learned a lot since it went live so there are loads of things I would do differently but despite that here are a few things that I am still quite proud of....
Contents
- Why did I build this site?
- A unique design
- It gets top marks in Lighthouse
- Security - it gets 125 / 100 in Mozilla Observatory
- Accessibility
- What would I do differently?
- Rounding Up
Why did I build this site?
I had become interested in the technical aspects of websites. I was mainly back-end focused but I really wanted to get into the front-end world due to accidentally stumbling into accessibility on a project.
It may have started with accessibility and that is now one of my biggest passions, however it was one of those "down the rabbit hole" moments where accessibility and the technical aspects of HTML etc. lead me on to all technical aspects of front-end design.
It evolved into looking at best practices, speed etc. because of Lighthouse. Then it lead onto security headers because of Mozilla Observatory.
So it was built as a "technical showpiece", it isn't built for conversions, it isn't built for SEO, it is built purely to score well in synthetic tests and as a learning exercise. I would not recommend it to any clients let's put it that way!
Along the same lines the site works without JavaScript, just in case it fails for any reason and even works all the way back to IE9. Those were two restrictions I placed on myself just to add an extra challenge!
There are hundreds of things I would do differently now (especially when it comes to accessibility as ironically that is probably it's weakest point!), but it still "kicks arse" in synthetic tests (and in a lot of real world scenarios as a result).
Finally I was not much of a designer and if I wanted to venture into the front-end world that would have to change! I also got sick of seeing "bootstrap" websites that all looked the same so the first task was starting with a design that stood out.
A unique design
As I said, I wanted to challenge my design skills. I am not a designer so there are probably things that could be done better but every single asset you see is designed by me.
I took inspiration from a mobile game (see if you can name it in the comments) and set about emulating that style.
I can't remember where the little robot people idea came from but I always liked them as they were race neutral and that aligned with my remit of inclusion.
I really wanted a site with unusual aspects, yet again to stretch myself. The page shown above is the "what makes a great website" page on the site and that was the most interesting design challenge.
I wanted to try and tell a story with each image matching with each item that I believe makes a great website.
So I built up the landscape and then created different mini scenes that (kind of) represent the area of "what makes a great website".
For example the little robot painting the landscape for design.
However as you can see a lot of the detail is lost when you are looking at the whole scene.
Zooming in for detail
This is one thing that really challenged me at the time. I had spent all this time designing the assets but a lot of the detail just was not visible.
So I designed the page that when you clicked an item we zoom in on the part of the image that is applicable.
The challenging part was ensuring the image was located in the same place each time when zoomed in.
In the end I just manually set up a coordinates system for x, y positions and zoom level. If I did this again I would just measure the containing rectangle and calculate the centre and size so I didn't have to manually set these, but yet again I was also still learning front-end so I hacked my way to a solution like all good (bad?) developers do!
Animation
I could probably write several posts just on how I achieved each animation. From the train smoke to the little robot security guard destroying the invading virus and the waterfall. If that interests people then let me know in the comments and I will write a post on them.
Someone could then probably write several posts on how to do it better 😋!
The main thing I wanted to make sure was that the animations could be easily switched off for people who have vestibular disorders and may have set their preference for reduced motion on the page (which we can ascertain from the prefers-reduced-motion media query).
As such the animation CSS ended up in a separate file, which made it really easy to manage and something I have adopted in all projects now. I then see if the media query matches in CSS and switch animations on if it doesn't (off by default in case JS fails).
Anyway that is all of the design stuff, as I said, not my strong suit. The really interesting part of the site is how it scores in synthetic tests.
It gets top marks in Lighthouse
Quick aside: One thing I just found out today is if you get 100 / 100 across all 4 categories in Lighthouse, "fireworks" display on the Lighthouse results (that is what those strange coloured dots are on the image above!), that is something new!
Speed
That scoring is for mobile, not desktop like most people who claim to get 100 out of 100 (it obviously gets 100 / 100 for desktop) for speed.
It was my first time building a site designed for speed so I spent waaay too long optimising it, but always fun to get top marks.
Also, as I was less skilled back then, I focused purely on page size.
Without analytics the whole site is less than 100kb down the wire!
Getting such a small page size involved several interesting tricks. The main trick being processing the SVGs I created with SVG OMG. This wiped about 80kb off the original images sizes.
Tiny JS payload
The next "trick" was not using jQuery. Now that isn't much of a trick but I always liked jQuery syntax.
As such I discovered a beautiful tiny library called ki.js.
With a couple of tweaks to make it usable in production and a load of extensions to add things like .parent, .first etc. I had something that worked (and worked all the way back to IE9, another requirement I had!) that was tiny (about 1kb)
This let me get the whole JavaScript for the site down to 7.3kb minified and gzipped.
Inlining the CSS
This used to work so much better but I broke it.
Originally the site only inlined critical CSS and then had separate style sheets for anything not yet required. However I broke it a few months back so now it thinks everything is always above the fold and sends everything inline.
I will write a different post on that when I launch the new site as we did the same thing there, but figuring out a method to reliably find elements that are critical and inlining them was another fun exercise.
Security - it gets 125 / 100 in Mozilla Observatory
This was the other thing that took a lot of time to learn and adjust.
I wanted to learn about security headers to protect the site from XSS etc.
So learning about Strict-Transport-Security and the associated HSTS preloading list was interesting.
Even more interesting was creating a content security policy that scored top marks as I had to completely rewrite some parts of the pages.
For example no inline styles is a nightmare when working with SVGs as they define their styles within the SVG itself. I had to move all of the styles to a stylesheet and add classes to each and every path etc. That was horrendous!
The other issue was that I needed inline scripts on the page and inline CSS. So I had to learn about CSP nonces and then work out a way of adding those dynamically.
Accessibility
As a first attempt at building an accessible website I still don't think I did badly.
However there are loads of things wrong. I don't trap focus correctly, the contact form errors do not report correctly, screen magnifier users may struggle with a couple of elements on the page etc.
With that being said I think the site would be usable by most users and would still be better than about 90% of sites out there.
The main thing I wanted to learn about on this site was setting up for prefers-reduced-motion as I mentioned previously and on that side of things it works well, switching off the animations if you have indicated you do not want them.
Accessibility is the main reason this site wasn't revamped for the new company and is being retired, there were too many design decisions that were not conducive to accessibility that would need completely rethinking.
What would I do differently?
Oh a lot of things!
The CSS relies way too heavily on vw and vh to position things for a start.
Secondly the JavaScript is messy and not very well thought out for extensibility. That is the reason things break on the site when I try to "fix" it, everything is too closely intertwined so changing one thing breaks another.
I wouldn't use Google Analytics, I have my own analytics package now which is far smaller and provides all the details I need.
I would put a lot more thought into accessibility before I started building the site. I made loads of mistakes that would be easy to remedy if I built the site again today but trying to reverse engineer it would be quite a large task. This is why I always say put accessibility on your roadmap from day one as one poor decision can lead to a lot of remedial work in the future. With that being said I know a lot more today then I did back then so I have to take that into account.
Above all I think I would spend a lot more time at the planning stage. I followed the "just do it" principle and it led to a lot of mess and mistakes. I would plan out the interactions on the page, how the page would behave with larger font sizes etc.
If you take one thing away from this article it is that you should spend more time planning how the site will actually work and not just what it looks like and make sure that if you implement feature "X" it still allows you to meet your targets for accessibility, performance etc. rather than designing it and then trying to implement those things.
Rounding Up
Anyway that is a brief overview of a site that I have yet see be beaten from a technical scoring perspective.
Looking back I can't believe how far I have improved in 2 years.
I regret never giving this site the "final polish" and publishing articles on it, even 2 years later I still like the site (which is unusual for me) as it is still pretty unique.
Let me know what you think (you can be critical and harsh, I learn better from criticism and it may give me ideas for future articles at the same time!)
Finally, I am throwing down the gauntlet. Do you have a site that can beat this one on speed, accessibility etc? Please share it in the comments I would love to see it!
Top comments (3)
Ironically on the day I wrote this one of the people I follow here on dev.to updated their website (or maybe they read my post and decided to do a similar one 😋)
Check out Mads Stoumann and his latest post about his website that rivals this one for performance etc.
Got to say, I love the circular design and the fact you can fiddle with the colours!
Great post! Will you write about the new company, you're starting? It is a coincidence, we'll have to coordinate our posts in the future 😆
That is just unreal 😂.
Yeah I will be writing about it loads over the next few weeks, in fact you will probably get sick of hearing about 😂😂