How to rank on Google and maximise your lighthouse score

Take a quick look at the header image for this post. I'm pretty pleased with that result. The site you're currently browsing is one performant cookie. But that doesn't come naturally.

When you build a website (or have one built for you), you tend to find yourself in the 70-80 area for these scores. And these scores do matter. Google will use tests and rankings very similar to these to help determine search rankings. Anything less that 100 is a red mark against your site, and it could well be that another site will rank higher than yours as a result.

So, how do you turn your autumn orange (or worse still red!) page scores into summer green ones? I believe this can be split into two sections: what you can do as you build your website, and what you should do after its "finished".

How to maintain performance as you build

Building a website is hard. You have so many little things to think about: markup, styles, JavaScript, caching, image sizes, responsive design and accessiblity, to name just a few.

There is so much involved, in fact, that we as developers can fall into the trap of building without thought to the structure of our design. HTML becomes littered with comments, JS modules begin to add up, even if they're not actually being used, CSS styles become outdated and messy. Unwittingly, over a period of days, weeks and months, a once clean site can turn into a performance disaster.

A little illustration

Imagine a team of builders constructing a house. The plans for the house are beautiful. The foundation is laid, and all looks perfect. Then the main structure goes up. Because of a tight schedule, the builders begin throwing down bricks to get the walls up as fast as possible. To make matters worse, each builder has a favourite type of brick to work with. They start cutting corners with the ratio of the cement mix and give up using tools to measure as they race on with the build.

3 months later, the house is "complete". The sueveyor comes to check everything out, and his jaw drops to the floor. What a terrible job! He cannot give the house a good score.

What has happened? The once beautiful foundation, the promise of what could be, was ruined due to a number things:

1. Bad communication - the builders should have stuck to the plans and all have been on the same page.
2. Racing to a schedule - the builders decided that a badly calculated timeline should take precedence over a good job.
3. Cutting corners - the builders started taking shortcuts and did not go back to clean up after themselves.

Well, did that illustration have a purpose? I think so. A website can often be saved by 3 things:

1. Good communication.
2. Placing quality over speed, and presenting accurate timescales.
3. Doing things properly, and cleaning up when changes are made.

Good communication

Communication is essential. The client should have open communcation with the developers (even if that goes through a middle-man). Expectations should be laid out from the get-go. The dev team should decide on the best way to build, which tools they will use, what methodology they will follow, and then each member of the team must follow that to the letter.

If a dependency is no longer required, that should be communicated to the team. If a library is required, or a polyfill is needed, or an accessibility issue is discovered, that should be communicated to the team. Everybody must be on the same page. That includes the client, although maybe at a higher level.

Quality over speed

Speed kills. Its true of cars, and its true of web development when it comes to performance. Racing through a build will result in a slow site with a poor user experience. Each page on the site should be tested, checked and fed back on.

A non-technical person should use the website and provide opinion on what was liked and not liked. That information is vital. It is more important than any technical opinion, because it is real world experience. Nobody in the real world cares that you're not using jQuery, or opted for Tailwind over Bootstrap, or have an automated build system. All of those things are important, no doubt. They're just not important to the people that matter: the customers.

Take time over each decision. Challenge so-called "best practice". What follows is an example of a decision I made for this site.

JavaScript is more or less an auto-include on modern sites. If you don't use JavaScript, your site sucks. But does it? Does it really? Where does that notion come from? I think it comes from a number of places, but primarily: developers like exciting tools, of which there are plenty in JavaScript land, and designers often include fancy animations, or complex items that need to toggle, or load in after the fact. Of course, analytics is also a factor that often plays into the need for JavaScript.

So, I included JavaScript on this site, right? Well, I certainly thought about it. But then I asked myself: Why? What would I use JavaScript for on the site?

Perhaps for a menu that toggles between being shown and hidden? Well, for one, there are significant reasons to avoid that behaviour althogether (Check out this article on the subject), and for another, I don't need lots of menu items. I can design around that with CSS.

Or how about analytics? Do I really need analytics on a blog? The answer, of course, is no. And so, I decided to remove JS altogether. That decision brings a lot of benefits. People who disable JS can have the same experience as everybody else. My site loads a lot faster. I don't have to worry about dependencies building up, about polyfills for older browsers, or file size.

Now, I'm not saying you shouldn't use JavaScript. It is often an integral part of functionality on the web. What I'm saying is that even the most "basic" of decisions should be thought about very carefully.

Don't cut corners

Cutting corners never did anybody any good. Just think about it: when you see somebody cut a corner whilst driving, you often give them an unpleasant nickname. So why should we do it in web development? We shouldn't.

Take the time to do things properly. If you don't understand something, research it (the internet is literally the world's largest library) until you do. If you no longer need a node module, make sure to remove it completely so that your compiled JavaScript is as small as possible. Ensure that your CSS is purged in your build process so that you only include the minimum necessary amount. Ensure that your files are cached, and that your're using versioning to allow your users to always stay up to date.

Bottom line: take the scenic route, not the shortcut. Its always more beautiful.

How to increase performance after the fact

So, your website is finished. The content is in, everything loads properly, winner winner chicken dinner and all that jazz.

I have news for you: you're not finished. Just because a page looks like the design, it doesn't mean its ready for primetime (I'm a poet and I didn't even realise that I was).

Go back through the page and check for immediate flaws. Are there any console errors? Get rid of them. Do you have a large amount of render blocking CSS? Defer it. Do the images take an age to load? Optimise them, or lazy-load them in. This is the stage where I'll run Google Lighthouse against the page and work through all of the reccommendations.

It takes time. It takes patience. Who cares? Your job is to produce the best possible website for the client and their customers. So take time, be patient, and do a good job.

One of the often overlooked aspects is accessibility. When I built this site, I used some light grays here and there. When I ran Lighthouse, I got some warnings about contrast issues. I decided to go and darken those grays, even if that meant the site not quite matching the original design.

Another area is descriptive links. I had a button placed above the 'latest blog posts' section named 'see more'. Not very descriptive for screen readers. So I updated it. Don't let a design get in the way of good user experience.

If you paid attention to the first part of this article, the second part won't actually take you too long. In fact, it should be pretty simple. But it is still vital. Take pride in your work, and clean up after yourself. Put your tech pots in the dishwasher, and wipe the side when you've finished.

Conclusion

Wow, what a ride! If you've stuck around this long, thank you. I hope you've been able to learn something. No two sites are the same, and the fact of the matter is that this can be a simple site, so it is a simple site. Your site may not have that luxury.

That is no excuse for poor performance. Plan carefully, build beautifully and come back to check and test each and every page. If you do, you'll have one sweet website to show for it, and Google, along with all the other search engines, will be all like "Whoa, nice site. Imma put this right up top".