The Perfect Lighthouse Score

When did you last visit a website without being bombarded by cookie notifications, email capture pop-ups, corner video ads, and shifting layout from hero-sized banner ads above the fold?

Why does anyone bother chasing Lighthouse or other performance benchmarks when webpages will be littered with tens-of-megabytes of additional junk? Is the perfect Lighthouse score even possible anymore? Why yes, yes it is.

So what does a perfect Lighthouse score look like? How about this:

Yes, that's the Lighthouse scores for this blog. And no, that's not a fluke. Here's the Lighthouse scores for another (interior) page:

So how is this achieved? One word: simplicity.

Seriously: stop over-complicating the internet.

Deliver Hypertext Markup Language, Not Megabytes

Have you ever heard of an HTML document? Key word: document. At its core, HTML is simply a language for marking up documents to provide structure and semantic meaning. As they are entirely text-based, HTML documents are usually pretty small. Think tens-of-kilobytes). So why are so many webpages measuring tens-of-megabytes in size? It's definitely all the extra stuff: images, video, stylesheets, and JavaScript.

Web browsers are really, really good at displaying an HTML document. They even come with default formatting such that an HTML document displays with heading, subsections, blockquotes, etc. all laid out well-enough. While no one is going to build a plain HTML website nowadays, the core of a webpage is still just HTML.

All websites should - at a minimum - strive to deliver a complete, ready to parse, easy to display, simple HTML document. There's a lot of reasons why this is a good idea (SEO being a big one), but in all honesty, let's just use HTML as it was intended. Then enhance it from that starting points.

Use Your Tools as They Were Designed

I generally build websites with Microsoft technologies, but I don't always use the best tool for the job of building a complete web experience. I always ask myself this question instead: what's the simplest and most obvious tool for the job? That typically means I stick with well-tested and proven technologies that provide a specific single solution and do it well.

My web stack usually looks like this:

• Backend: SQLite for storing data (super-simple) and ASP.NET Core for building web pages from that data (MVC is a reliable and proven architecture).
• HTML: Ensure that content has proper structure, navigation, and semantics.
• CSS: Straight-up CSS for simple designs and ocassionally SASS to provide a dash of styling to ensure content is accessible and presented with a fairly clean look.
• JavaScript: Plain ol' JS for progressive enhancement. I add functionality to HTML pages as needed, but don't go overboard. JavaScript should never required for a website to work properly. Minimal use of third-party libraries.

Don't Scale For a Google-Sized Application

"Architecture" is a big word in software. There are many patterns, processes, recommendations, and opinions on how to build The Forever Software™. Should every application be built with scalability in mind? Yes. Does said application need to handle billions of users on day one? Absolutely not.

For most applications it's enough to design and implement a simple and clean architecture and let hardware handle the rest. Modern cloud architectures are cheap and scale instances really well. Also consider your potential growth. How will your software be used in 1 year? In 3 years? Build for the here-and-now, but build software that can be expanded upon rather than chasing a theoretical target five years in the future.

To be realistic about my needs, I now run several blogs that generate up to 10,000 views per month. That modest number has kept my applications simple and my hosting cheap. This blog is build on the stack mentioned above (ASP.NET Core MVC, SQLite, etc.) and will scale to 50,000 views per month without a fuss.

Could I handle 1,000,000 or more views per month? With my simple, clean application architecture: absolutely. I may need to throw some more hardware at the issue, but that's something I can do with a few clicks in the Azure Portal - not by overcomplicating my software design now with unnecessary design.