As someone who wants to become a professional Web Developer, I view my portfolio website as my pride and joy.

As a software engineer especially a front-end one, it is essential to have a clean and well preforming portfolio website. To evaluate how good a website is, I first use Chrome dev tool’s Lighthouse feature. It measures a bunch of different metrics under performance, accessibility, best practices and SEO. In this article I will document the process of making my single page application (SPA) website into a highly efficient, accessible and optimized website that will score 100/100 on every Lighthouse test. You can click on the following lines to scroll directly to the part you’re most interested in:

Performance

Accessibility

Best Practices

This was my website’s score before I wrote this article. Unacceptable!

Performance:

The first step towards perfecting my website (at least in Lighthouse’s eyes) is to convert some of the images I used to next-gen formats. This was as simple as opening the image with Gimp(or Photoshop if you like paying for things), going to File > Export As, then selecting ‘Select File Type’ and scrolling down to Web image. I choose the webp format because JPEG 2000 and JPEG XR aren’t available as default Gimp exports at this time. I was able to save an average of 100s of Kibs on images this way.

Lots of room for improvement

Next step was to fix some images further. I had adjusted the sizing and rotated some icons with CSS. Apparently that is not optimal for a website and its much better to save the image file so its ready-to-go as is. This was a fairly simple task to do in Gimp with the Scale tool. I took my arrow image that was a whopping 2000px in width to a humble 100px. This and converting the images to webp saved 37Kib each.

Finally for optimizing load speed I needed to eliminate render-blocking resources. This basically means for me at least, remove the unnecessary CSS and take out a font sheet I’m not using.

why you shouldn’t import an entire stylesheet

I used a React-based video player to display my project videos. I apparently didn’t need to import the entire stylesheet for the video player. Here I used chrome dev tools again to look at my code coverage. Read more about using the code coverage tool here. This is an easy way to see what styling elements I need and which ones I don’t. The styling that was actually used, I copied over to my video player elements. Using this tool also made me realize I pretty much had no reason to use React and I could’ve written my project using only HTML and CSS, cutting down on a massive amount of JavaScript that comes packaged with React.

After I transferred the new webp images and cut out unused stylesheets and CSS. I got a beautiful 100/100 score for performance.

Feels good

Accessibility:

Now onto the accessibility score. Keep in mind that Lighthouse states only a limited number of factors can be measured for accessibility. Manual testing is recommended. The two main identified issues with my website are <li> elements not contained within a <ul>, and header elements not in a sequentially descending order.

First I need to change my h3 headers to h2. Lighthouse states this is because: “Properly ordered headings that do not skip levels convey the semantic structure of the page, making it easier to navigate and understand when using assistive technologies.” Second I need to contain my <li> elements in a <ul> or <ol> (unordered list or ordered list). I choose <ul> as my list was in no particular order.

Best Practices:

Next for best practices. My site had an absolutely shameful score of 93/100. First step was to limit my <a> link elements. Although I only linked to GitHub and Linkedin on my page and they most likely won’t pull anything shady, I still need to limit their access to my site none the less. If you have an <a> element without a rel=”noopener” or rel=“noreferrer” attribute, that allows the site that you link to, to access your website document. This can apparently give the ability for the other page to redirect your page to a malicious URL. You can read more about safely linking websites here.

Both rel=“noopener” and rel=“noreferrer” make it so malicious javascript code running in the new window will not access your previous window via the window.opener attribute. But rel=noreferrer makes it so no referrer information gets passed to the destination link. I decided to use rel=“noopener” as I may want to add user analytics to my website at some point.

Next in the best practices category, is under the ‘user experience’ sub-category. I will handle these at the same time as they overlap. In order to correct the user experience score, I must: display images with correct aspect ratio and serving images with an optimal resolution. This basically boils down to making sure my images are at the correct ratio and not fiddling with the sizing in CSS using non responsive units in addition to having multiple image sizes. You can read more about serving responsive image sizes here.

After that, I had a perfect 100/100 on all the Lighthouse metrics. SEO was already 100/100 as I had fixed it last week, which I documented in this article. Something special happens on Lighthouse when you score 100/100 on everything. I wont spoil it for you. Stay tuned as next week I will document making my website into a Progressive Web App. The week after, I will rewrite my website using only HTML and CSS to shave it down to its smallest, most efficient size possible. Thanks for reading! If you care to take a look at my website heres the link: https://jacksonbey.github.io/JB-Website/. It still is and always will be a work in progress.

I write about programming and specifically CSS | HTML | JavaScript | Ruby | React.js | Redux.