How I Redesigned My Site
My website was a sore spot for me. The last time I updated it was in 2011, and it was written with the technology of that time. It was heavy and clumsy, the fonts were small, the CMS imposed restrictions on page layout and backup creation, and the CMS itself was long outdated and insecure. I wanted to get away from it all.
But just to redesign the main page is not enough. I had to move all the projects and articles from the old database to somewhere else, so I’ve been putting off redesigning for a long time. And the longer I was putting it off, the more the site was bugging me: “Hey! You’re a frontend developer, and your site is 7 years old”.
In the end, I decided to draw up the requirements for a new site and see how much time and effort it could take.
Get away from CMS. A CMS may be convenient for those who don’t know technology, but I do. A CMS is an extra layer between me and the publication of an article or project. For me, in principle, a static HTML site is enough.
Store notes and projects in Markdown. HTML itself isn’t convenient enough: tags by themselves are extra characters that slow down the publication, I wanted something simpler. I chose Markdown.
Make the fonts bigger. The old fonts made my eyes hurt. I don’t mean I didn’t like the font, Helvetica was fine, but the fonts size was too small. Now I type in the main text in an 18 pixel font.
Make the site semantic and accessible. The more users who can access my content, the better.
Optimize the loading speed. The old site took a long time to load. Tired of it, I wanted it to be fast.
When I made a list of requirements and problems that the redesign might cause, it turned out that the work for a few weekends. But the image of the new site was so strong in my mind, that I was itching to sit down and start redesigning at once.
I started by choosing a font. I wanted a serif font for the main text, a grotesque font for the titles, and a monospaced font for the code. I chose the PT family: they are free and good-looking. And the Mac has them on the system, so many users won’t have to download them from the server.
I got rid of the CMS, but the template problems remained. I realized that I needed some kind of build system that would take my notes, templates, meta-information about the page and glue them together with HTML pages.
Made a builder based on Gulp. It takes JSON with the site structure, and builds site tree by it. The output is static HTML site.
But I wanted to keep all the old links working, and I did not want to bother with redirects to the new pages. This is why I took old links and built a tree with them. So the link /blog/ turned into file /blog/index.html, and /blog/page/ —into /blog/page/index.html.
I used only HTML, CSS, JS. It’s a relief to write working code right away, instead of setting up environment, transpiling, compiling, and whatever else.
I used progressive enhancement for the code. For example, I have styles split up into different files, and I plug them into the main file with standard CSS import. The advantage is that the styles work without building the project. After building it is one file with all the styles, before—the file with the imports. As a result, I can quickly see and correct something without having to rebuild the site.
In order to make pages load faster, I decided to use optimized graphics formats. I chose webp, which I connected using the
picture tag. This helped reduce traffic for Chrome by 10 times, for Safari by about 2 times. Besides different formats I use different images for retina and non-retina, which also reduces traffic for non-retina screens by 30-40%.
But graphics optimization alone was not enough for me. I wanted that users in general would have to download as little data as possible from the Internet. That’s why I moved to HTTPS and set up the service-worker. Styles, scripts, some images are all stored on the user’s device. For those who already have the service worker installed, this greatly reduces download time and saves traffic.
Semantics and Accessibility
nav but that’s where it ended. The heading structure suffered, there was no micro-layout, lists were not always lists.
In the new site, I initially thought about page structure. Checked with lighthouse, axe, third-party audits. Then walked around the site with the keyboard, and then turned on the screen reader altogether and listened to how it worked on it. Works well, no shame now.
While I was developing the new site, I released a few notes and one project on the old site. Updating notes and projects on the new one was much easier. No passwords or admin panels: push to GitHub, it flew away, updated. For me as a developer, it’s perfect.
A big bulky task takes a lot of mental energy: you’re constantly thinking about it. It helped me to break this cumbersome task into chunks. For that, I used current initiative to spend an hour a day, sometimes a more.
Finding a method to solve the problem is easier than the motivation. Problem setting is an important part of the solution. You need such a formulation that your hands itch to solve the problem—then it’s much easier to get things done.