As part of the journey of rebuilding my website from scratch, I thought it might be useful to some people if I recorded notes about the process.
I added back in some basic CSS to adjust the typography because I wasn't happy with the default browser styling. I'm a big fan of the typography styles in Safari's "reader mode" so the adjustments I've made are inspired by that look.
The local Lighthouse audit using Chrome's devtools showed a slight hit on mobile but I'll deal with that later. I'm not doing anything that severely impacts the site's performance right now so the performance tradeoff for the design enhancement is worth it.
Running the Lighthouse audit through Google Pagespeed Insights on the live production site still gives the site full marks so there wasn't any performance impact by adding the CSS.
I'm still not getting good numbers on the ttfb on webpagetest.org that might be related to the 404 on the favicon.ico. I'll need to create one of those and see if things improve.
Removed the CSS from my site so that I could run some performance tests on it without any blocking resources. The design was thrown together so I'm not tied to it in any way so I figured it was just easier to start again.
I also update the height/width attributes on my SVG logo to make it a lot smaller. Without any CSS, it was 360x360 and way too big on mobile. It's a branding element. It doesn't need to take up a lot of space (especially without any sort of design on the site).
I ran my site through the Lighthouse performance testing tool in Chrome and checked out the scores. One part where the score could use some work was accessibility.
After running my pages through the axe accessibility testing tool plugin, I was able to fix a few errors such as:
H1tag on the homepage.
- Duplicate unlabeled
navlandmarks on my article pages.
- Ensure that multiple links on the same page share the same purpose.
While I was in here, I've been playing around with some basic styling as well.
Today I configured Eleventy to use Handlebars as my template engine. It's been awhile since I used Handlebars so it took some time to remember the basics. I also used Eleventy's Front Matter Data for the first time.
After refamiliarizing myself with Handlebars, I refactored the HTML templates on the site so that I'm using layouts and partials for the common code. This is going to make maintenance so much easier!
I refactored my code to use Eleventy, a static site generator. While I haven't made any changes in how I build pages yet, this will enable me to start using a templating engine to structure my files in a more maintainable way.
After running WebpageTest on the last post I wrote, I noticed that the images weren't scoring very well. At first, I thought it was because I wasn't doing responsive images right but it turns out that Mac Preview isn't very good at optimizing images. I took the images I created and ran it through TinyJPG and benefited from better compression/optimization.
Wrote a new post that includes some screenshots and used
sizes for responsive images. It's not working quite as I expected. I'll have to compare with a different post where WordPress had converted the images for me. I'm not sure yet if it's a problem with the images or the code I wrote
More Screen Reader Testing
At the recommendation of a former co-worker, I downloaded the NVDA screen reader for Windows and used it to read my website. It read my website coherently and the previous issue I mentioned about the "b" tag splitting up a word didn't happen. I retried this on VoiceOver and the word "development" was read correctly even with the "b" tag.
I'm not sure why it was reading differently before so I'm going to assume I wasn't testing properly.
Fixing the Viewport Meta Tag
I spent some time playing around with some basic typography styles and happened to be testing them out in Chrome. When I opened up the inspector, I noticed an error in the console with regards to the viewport meta tag.
Apparently, I used
device=device-width instead of
width=device-width in the tag, which caused an error to show up. Oddly enough, the mobile browsers still rendered the page as I was expecting. The resiliency of HTML is quite remarkable.
Adding the Dev Log
I created this new page on my site to ramble on about the process of building out the site. While doing so, I spent a little time fumbling around with Apple Voiceover to hear what the site would sound like through a screen reader. It was an educational experience. Not only was I able to pick up on a grammar error, it was very useful in identifying issues I wouldn't have thought about.
Issues Identified During Voiceover Test
- The SVG was read as multiple images. I need to determine what kind of meta tagging I need to incorporate so that the image is read properly.
The "b" tag that I added in the level one heading for future styling purposes of the word "development" breaks the word into multiple pieces. Even though I thought this made sense in terms of semantic HTML, it actually doesn't translate well for the reader.
Updating the Viewport Meta Tag
I made a simple update today to add the viewport meta tag to the pages so that they render better on various devices/screen widths. Without the tag, the site looked really small on mobile devices because they would take the rendered page and scale it down to the screen size of the device.
Visit the MDN page to learn more about the viewport meta tag.
Redirecting my Domain
I didn't do anything code-related today. I updated my DNS records so that my domain now points to the Netlify version of my website.
I finally decided to get started on rebuilding my website as I wrote about in my post: Moving to Netlify and Bare bones HTML.
The first step in the process was building out a set of very basic HTML pages with some of the content from my Wordpress site and a homepage that linked to each of the new pages. In creating the individual HTML pages and folder structure by hand, I can already see how this will be a maintenance nightmare. However, I have committed to starting at a very basic level and I knew that there would be a cost to that.
Uploading to Netlify
Once I got my Netlify account set up and figured out the basic concepts, I dragged my local site folder into the deployment interface and I was up and running.