General note: This site’s appearance, configuration, hosting, and other basic considerations will change over time. As a result, certain content on this page could be at variance with what you’re currently seeing on the site, but the two were consistent when this post originally appeared.
If you have your own website, chances are you like to make it work better for your visitors and, yes, show up higher in search engine ratings. Let’s talk about how you can do that.
Of course, the Holy Grail looks like this:
That’s an authentic screen capture from my home page’s Lighthouse profile as delivered from the Lighthouse CLI tool: perfect “100” scores for Performance, Accessibility, Best Practices, and Search Engine Optimization (SEO).
It took a lot of work to get there.
This article is about how you can move your site in that direction. By no means is this post complete in that regard. For the totality of what Lighthouse checks, you’ll need to check the Lighthouse documentation and its many links.
Instead, this covers some of the items which seem to be low-hanging fruit or, to borrow a term from the Eleventy site’s documentation, “common pitfalls.”
Performance
All other things being equal, search engines give poorer scores to pages with lagging performance, which is probably the reason why Lighthouse puts that score at the front of what it counts. Let’s discuss a few ways you can raise that score and shorten your site’s page-load speeds.
Put your site behind a CDN
There was a time when a website owner would put content on just one server in just one location and call it a day. On today’s web, it’s insufficient to have your content on one solitary server sitting behind one solitary network interface.
If you reply, “I don’t anticipate attracting visitors from all that far away,” consider that even this humble site you’re reading now has visitors from dozens of different countries, scattered around the globe.1 If your content grabs attention on search engines (we’ll get to SEO later), the same will happen to your site.
The best scenario is that, regardless of where a visitor may be, he/she doesn’t have to wait long for your content to load — especially considering that a disproportionate percentage of visitors from certain nations will be coming in on slower mobile devices and less advanced networks. For those scenarios, you want your content on a content delivery network (CDN).
The good thing is that, if you’re hosting your site on Netlify, Vercel, Render, or Firebase, a fast CDN is part of the deal. However, if you’re operating off a VPS or a shared-hosting account (see the next item for more on that), try to put your site behind a free account on Cloudflare.
Sharing is bad
As children, we all were taught to share, but forget that noble sentiment when it comes to your website. The word on putting your site on a shared-server account is pretty simple: “Don’t.” There are reasons for the low price of a shared-server account.
When your site is one of hundreds, even thousands, of accounts sharing space on one box, that’s never going to be good for your site’s performance. You start with having only a tiny fraction of the server’s “horsepower” (computing cores, drive space, and RAM) on which to rely. The situation becomes dramatically worse if one of those accounts suddenly experiences upward spikes in traffic: all the accounts on that server (even the one with the spikes) will suffer.
Web fonts: Pretty, but . . .
Diets aren’t fun, and they suck even more when you’re hungry. Because of my love of the distinctiveness that well-chosen web fonts can give a site, the question of whether to have them or stick with the system fonts stack is a hard one for me to debate.
But I don’t argue with the data, and one test after another has shown me web fonts slow down my site — not a lot, to be sure, but enough to matter.
That’s also turned out to be the case when I provide them “locally,” as opposed to pulling them directly off (e.g.) Google Fonts, even after trying a variety of excellent advice from very smart folks. Consequently, I go with system fonts, however much I’d like to use certain typefaces I admire.
Update, 2020-08-08: I’ve stricken through the remainder of this section, below, for reasons I explain in another post about the privacy violations involved with using Google Fonts typefaces if they’re served from Google.
If your response is “Damn the performance hit, full speed ahead with Google Fonts”:
Don’t load them locally. When you load them off Google Fonts, they come with “secret sauce” to optimize them for each visitor’s individual browser and device. Also, the code behind that “secret sauce” changes without much warning; do you really want to monitor it yourself all the time and keep updating your local installation of the Google Fonts content? It’s easier to get it straight from the horse’s ultra-fast CDN.Go with variable fonts where possible. I say “where possible” because there remain only a limited (but growing) number of variable typefaces in Google Fonts, which means your typeface choice may not be available at the moment. Where variable fonts shine is when you want to use numerous weights and styles of a typeface. With older non-variable fonts, that means one additional download per weight or style; but a variable typeface does all that good stuff with just one download. By the same token, you probably don’t need a variable font if you’re using only one style or one weight, much as you don’t need a Ferrari to go to the grocery store.
Accessibility
Making your site available to as many people as possible, regardless of their individual circumstances, is every site owner’s responsibility — and most especially if your site’s content puts it under the stricture of laws like the U.S. Americans With Disabilities Act (ADA). Even if you don’t want to be nice, why risk being sued? Make your site accessible.
You can’t go wrong by following the Web Content Accessibility Guidelines (WCAG), and most notably avoiding WCAG “A”- and “AA”-level offenses. I won’t — can’t — try to cover all the WCAG content here. Instead, here is a small sampling of some of the most obvious things you should do to avoid running afoul of WCAG.
Give alt tags to all applicable images. WCAG cuts you slack if an image is considered exclusively “decorative” — for example, a logo — but otherwise specifies that an image should be accompanied by an alt tag that tells a screen reader what the image shows.
Specify sufficient contrast for text. A web page is no place to be showing light gray text on a white background, or dark gray text on a black background. When you’re choosing your site’s text and background colors, run everything through one of the great online contrast-checking sites (WebAIM’s is my personal favorite). That goes also — or should I say, especially — for your link colors!
Have underlined links. Speaking of links, yours should have underlining, making them easier to see. I don’t use the text-decoration method on my site, because I hate text descenders (as in the lower-case letters g and q) punching through the underlines; instead, I use CSS to put borders underneath linked text. Regardless of the method you choose, be sure you do provide underlining.
Provide keyboard equivalents for navigation. Not everybody has the dexterity to use a pointer device like a mouse or trackpad for navigating around a web page. Make sure all your links, including your nav links, are accessible through the use of tab keys or other keyboard-specific methods.
Use aria- attributes where necessary. ARIA means Accessible Rich Internet Applications, and refers to roles you can assign to elements so that screen readers will handle them correctly. In some cases, normal (and correctly used2) HTML, such as h1 to designate the page’s top-level headline, will be enough for a screen reader; but sometimes the process takes a little more specialization. For example, if you have a button on a page, it needs an aria role="button" assignment. This page on the Google Developers site is a great place to get started on making sure your site is OK ARIA-wise.3
Best Practices
There’s a long list of items Lighthouse checks for conformance with “Best Practices.” Try to adhere to them all if you can, but comply with the following out of plain ol’ common sense.
Use HTTPS. When nearly every host makes having https:// at the head of your URL a freebie through services like LetsEncrypt, and browsers flag an HTTP-only site as bad news, not having HTTPS is dumb. Increasingly, it marks a site as being in a state of neglect.
Use HTTP/2. If you’re not using HTTP/2 to begin with, especially since HTTP/3 is on the horizon, you’re already behind the curve. HTTP/2 allows more things to download at the same time, helping your performance. Browser support for HTTP/2 is almost unanimous at this point.
Have the right HTML doctype. If the HTML on your pages begins with an inaccurate doctype declaration (or, worse, none), browsers have to “guess” how to show your pages, and that “guessing” process takes extra time. The doctype declaration for HTML 5 is simple: <!DOCTYPE html>. For the older XHTML and HTML 4.x, the doctype declarations are somewhat more tedious.
Don’t use WordPress if you can avoid it. While there are countless reasons why that’s always good advice, the Lighthouse “Best Practices” test adds another: WordPress includes an ancient version of jQuery that has known security vulnerabilities. Automattic, the entity behind WordPress, sticks with this hoary jQuery version to avoid breaking changes with the depressingly high number of extant WordPress sites — many of which are run by people who, to be kind about it, don’t manage their sites’ technical components wisely. (As they say on social media, “SMH.”)
SEO
The higher you score on all these things, the better chance your site content has of doing well in search engines’ results. Of course, the SEO segment of what Lighthouse checks has especially high relevance to that. A quick search, coincidentally enough, for “SEO” will reveal mountains of (mostly) marketing-oriented advice on the subject, and you may want to bathe in alcohol after reading some of it. That said, here are just a few SEO-related quickies which surprisingly can escape notice.
Have a valid robots.txt file. There’s no over-arching authority that can make Google and the other search engines obey robots.txt, but it’s better to have it than not to do so. So make sure it’s there, that it’s in your site’s root directory (e.g., https://mysite.com/robots.txt), and that it allows search engines to “spider” through all the content you want them to “see.” If you don’t have a problem with their “seeing” everything, it doesn’t get simpler than this two-liner:
user-agent: *
allow: /Make sure every page has a unique title and description. Don’t make the mistake of giving every page the same title and/or description. Search engines will skin your site alive on that lazy practice. It’s even better for SEO if you add your site’s title at the end of each page title, which is easy to do with the templating you’ll usually find in a static site generator (SSG).
Make your links meaningful. This is good for both SEO and accessibility. Work hard to avoid using link text like “Click Here” or “Learn More” without including in the link (between the <a and the </a>4) why the person should click here or what more the person will learn.
Specify your page language. In another case where wise SEO also is pro-accessibility, you should specify in each page’s opening html tag the language of the page. In my case, it’s html lang="en". It does get trickier if the page itself is multilingual.
No guarantees, but these will help
By no means can I, or will I, guarantee that following the advice herein will make right everything that may be keeping your site from doing well in Lighthouse. I said it before, and repeat it now: getting “100” scores across the board on Lighthouse takes work, a lot of it, and it might take a good while to achieve — even if your site is light enough on content that it would be a quick download via the most ragged of connections. But it is worth it.
If you’re starting from scores well below “100,” don’t get discouraged. Start small, with the items I’ve noted in this article, and see what you can achieve; then move on to the other qualifiers identified in the drop-down items in a Lighthouse audit from the Inspector of a Chromium-based browser. Keep your eyes on the prize: making your site the best you can. It’s good for your visitors, and good for you.
I know this thanks to the privacy-respecting smarts of Fathom Analytics (affiliate link). ↩︎
Avoid the bad (but sadly common) habit of using
h1,h2,h3, and the like for styling rather than semantic purposes; i.e., use such tags to indicate what content is, not how it should look. ↩︎Pages with webmentions pulled in from Bridgy, as of now, will have minor
aria-related accessibility dings because of an issue with that site’s code which, I hope, will be resolved soon. ↩︎Or
<Linkand</Link>for you Gatsby and Next.js folks. You know who you are. ↩︎
Latest commit (2f3b5ea3) for page file:
2023-07-23 at 8:26:30 AM CDT.
Page history