Lighthouse (by Google) is a fun and easy tool used to test web app performance. It’s so easy in fact that all you do is click a button, and within seconds a magic number between 0 and 100 is generated for you. This magic number basically tells you how fast people perceive your app to be.  

But a Lighthouse report is actually much more than just a number. It’s a comprehensive rundown on everything that is affecting your app’s performance. They even tell you exactly what you need to do to make your app faster. And being fast is important because, well, I’m sure you’ve heard the saying “time is money”. This is so true when it comes to selling anything online. If your app doesn’t load fast enough, the person behind the screen is just going to “X” it out and move on. So yes, if you’re trying to make money online, time is definitely money.

So where does this little number come from and what does it all mean? In this article, we’re going to explore some of the most important elements that are used to calculate your performance score. This will give you a better understanding of where you stand on the web, and more importantly, how to beat the competition.  

What the numbers mean

As I mentioned earlier, when you run an audit, Lighthouse assigns you a Performance score between 0 and 100. 100 is the best possible score (also really hard to get) and 0 usually means an error occurred. Somewhere in between is where you’ll probably fall.

0-49: This is a poor performance score. It’s ok to be embarrassed if you landed here... Good news is, there are many opportunities and steps you can take to speed up your app.

50-89: This is average. Not terrible, not amazing, just ok. And there’s nothing wrong with that! But just know that there is still a lot you can do to get to the top.

90-100: This is good, stay here. A performance score of 90+ means you're within the top 5% best performing apps on the internet. You’re doing just about everything right, go you!

Alright, now that we know what the numbers mean, let’s take a look at what goes into generating them, shall we?

Metrics that determine your score

Lighthouse has a major focus on performance metrics. And when you run a Lighthouse report, you’re most likely looking for the answer to this question: how fast is my app? But what does fast even mean? Fast for who? You might think "fast” means how many seconds it takes for your app to load. In reality, load time is different for every single user depending on their device, network connection and more. Consequently, your app's overall performance is actually a collection of every individual user’s load time.  

The point is, the fastness of your app cannot be measured by any single moment in time. It's a full experience that no one metric can fully capture. The “experience” I'm talking about is the user scrolling through content, clicking on buttons, entering information, etc... In this regard, Lighthouse is effective because it measures the timing of every major moment throughout the experience that can have an affect on the user's “load perception”.

As a result, metrics that determine your performance score are looking to answer questions such as these: Did the navigation start successfully? Has the server responded? Has enough content rendered that users can engage with it? Can users interact with the page, or is it still busy loading?

The following metrics were created to give us answers to these questions:

First Contentful Paint: This metric marks the time at which the very first piece of text or image is painted on the page. It’s the point when the browser renders the first bit of content from the DOM. Ideally this number should be less than 2 seconds. This answers the questions - did the navigation start successfully? and has the server responded?

First Meaningful Paint: This metric is the point at which the most useful content renders on the page. Your most useful content is typically defined as the above-the-fold stuff - the stuff that people are coming to your site to see/do. This should ideally happen less than 2 seconds after first contentful paint. This metric answers the question - has enough content rendered that users can engage with it?

Time to Interactive: This represents the amount of time it takes before the user can start fully interacting with your page. This will mean your app is both completely visually rendered and capable of reliably responding to any user input. This metric heavily depends on JavaScript and how long it takes for your scripts to fully load and execute. It should ideally be less than 5 seconds for static apps and less than 10 seconds for dynamic ones. This metric answers the question - can users interact with my page yet, or is it still busy loading?

Your overall performance score is a weighted average of all these numbers (plus a couple more less significant ones). Each metric is not equal, as some have a larger impact on your score than others. But if you’re concerned with your app performance, these are the most important metrics to focus on.

Opportunities to improve

The “opportunities” section of a Lighthouse report does not directly contribute to your Performance score. Rather, this section details what you can do to improve your score. Fly has created several simple to implement methods that solve the most common and critical recommendations from a Google Lighthouse report.

Fly helps make the internet fast, because we believe speed = money, and so should you! With Fly, you simply build your app with JavaScript and deploy it to the Edge. A Lighthouse performance score of 90+ means you're within the top 5% best performing apps on the internet. Here’s how to get to 90+ with Fly:

  • Serve images in next-gen formats: Turn on WebP for any browser that will detect it. Fly has a built-in WebP conversion tool that makes images 40-60% smaller, while making image quality even richer. Click here to see exactly how to integrate this method into your own Edge App.
  • Defer offscreen images: Load only the images you need, when you need them. Fly makes it easy to accomplish this by using the Intersection Observer API and data-image-src attributes. Click here to learn how to do it.
  • Properly size images: Give the browser the image size it actually wants. Ideally, your page should never serve images that are larger than the version that's rendered on the user's screen. Anything larger than that just results in wasted bytes and slows down page load time. Fly has a built-in method for easily resizing images.
  • Eliminate render-blocking resources: Load scripts/CSS intelligently. Optimize the critical rendering path by deferring what you don’t need right away. Only load what you need, when you need it.
  • Third party JavaScript: Finally, get rid of or defer third-party JavaScript if you can. Third-party libraries are notorious for blocking page rendering.

Just Google it

Unfortunately, web performance is so often overlooked. And for good reason maybe. For most, the thought of trying to fix a slow site is daunting, confusing and overwhelming. But what better way to start tackling it than getting advice from the world’s largest search engine? With metrics ranging from when the first element is painted to when the page becomes fully interactive, Google Lighthouse helps us all understand what makes a site “fast”. I hope this article was able to shed some light on this surprisingly not-so-daunting situation. And if you still have questions, feel free to ask us (support@fly.io)!