You are here:Home1/Tech Talk2/Measuring PWA performance: What scores to pay attention to and what you...
Measuring PWA performance
What scores to pay attention to and what you can ignore
Performance is one of the most important things when creating a website. Not only does it improve your SEO but more importantly, it improves your user experience. But when measuring the performance of Progressive Web Applications (PWAs), there are many different factors to take into account. On first glance, the stats you get back don’t always appear to be the best.
We’ll look in more detail at some key performance tools, what they actually measure and why they’re not always the best indicator of what your customers are actually experiencing.
The most famous metric right now is the Lighthouse Score. This is for 2 reasons: it’s one of the around 200 factors which influences the ranking of website in the Google index, and it’s very easy for anybody to view (just check out Developer Tools → Audit on a Chrome browser).
The Lighthouse Score simulates the first request of a user without any cached assets on a slow network connection (3G) with a slow device. This means that it’s optimized for static sites and totally ignores the benefits of a PWA (which has faster transitions between sites and has more interactivity). To make matters worse for a PWA, the most important metric at the moment is Time to Interactive. This means that the full client side application has to be fully loaded and initialized. For an average PWA, this is roughly 12 seconds even though in less than two seconds (usually) a user already sees a website. In fact, as soon as the server side HTML has been delivered and styled, they can use the site. But the Lighthouse Score doesn’t factor this usability into the results so a PWA will always receive a worse score a ‘traditional’ website. The score also doesn’t simulate real user behavior or their perceived performance so even though users are getting the best experience, your score doesn’t reflect it.
Most Search Engine Optimization (SEO) agencies focus on the Lighthouse Score or implement something very similar themselves and report these values when analyzing customer sites. But like all analysis, context is everything and it shouldn’t be taken at face value, especially in terms of a PWA.
The good thing about the Lighthouse Score is that the reports are excellent debugging tools. You can easily find and understand where you can optimize the performance of your site during development as you can already test it locally and on staging systems.
It’s a really simple and quick way to know where you need to optimize your site, just don’t take the score at face value and make sure you analyze what it really means for your customers rather than just SEO.
Tideways (or similar tools like New Relic, App Dynamics) measures how long a backend takes to generate the response. This rendering time is also called Time To First Byte and looks at the Server Side Performance. It includes:
Loading the page information
Fetching all the data
Server Side Rendering (only on the first response)
Tideways is another great tool to debug performance issues, especially with data integrations like APIs, and it’s a great tool for Developers. The server side performance also influences all the other metrics – from Performance to SEO – since basically everything that happens in the client depends on data from the server. The problem though is that the Time To First Byte metric doesn’t have a major influence on the other metrics.
Lighthouse also measures Time to First Byte but they include the data transfer size which isn’t measured by Tideways. So in some cases where raw data (stream data, page metadata, …) is transferred next to the HTML, slow connections will affect this score and it can vary a lot between Tideways and Lighthouse.
Pay attention or ignore?
It’s great tool for Developers and to improve performance but it won’t give you the full picture.
Chrome User Experience Report
The Chrome User Experience Report (CrUX) provides by far the most holistic metric and also is part of the search engine ranking score. It’s often neglected (especially compared to the Lighthouse Score) because it isn’t so easily visible. The performance data from real users using the Chrome browser is aggregated for live websites and this data is analyzed and available for download here.
It’s the most realistic report for providing a sensible overview of site performance including Time to First Byte, First Paint, Cumulative Layout Shift, and much more. However, it’s not easily digestible, and it needs to be processed and visualized. The other issue is that it only collects data for live sites and there’s no way of evaluating your site before launch.
Pay attention or ignore?
If you can get this data transferred into an easy to read report, it’s well worth it and should be the go-to report for any live site.
So which one should I use?
As with most things, there’s no perfect way to measure performance when it comes to PWAs. The most important thing is to understand how your website works and make sure that your business does too, that way you can better understand the performance scores your site is getting.
Use your site yourself so you experience exactly what your users experience. Use different devices on different networks so you can see first hand where you need to make improvements. Then when you know what you want to measure, find the best tool to measure exactly that. It’s better to use a set of tools to get the full picture and optimize your site, rather than just relying on one measurement.
PWAs in general
After all this, wouldn’t it be easier to just avoid using a PWA? If your only goal is to have a good Lighthouse Score, then yes. But if your business KPIs include having the best user experience across all devices, increasing your sales, creating brand advocacy, etc. having a PWA does all these things and much more.
With Frontastic, a PWA comes as standard so you can develop for Mobile devices first and create amazing digital moments for your users. We want to help you to optimize your PWA and like we said earlier, the best way to do this is to understand what’s happening when a user visits your site.
When a user makes a first ever request to a Frontastic website, they’ll receive the HTML of the website (done by our Server Side Rendering). Besides this, they need a few other things to be able to use the website:
The styling information (CSS)
The data to initialize the PWA
The images (videos, and so on) which are used on the website
After that, we’ll only load the data for every subsequent page (not of the assets anymore, except for chunked Tastic or images used on those pages) if the user clicks on a link inside the PWA.
For more information on how you can improve your performance as well as optimizing your SEO with Frontastic, see our help articles at https://docs.frontastic.cloud/.
Henning is a Software Expert with strong enterprise skills. He’s worked in many management positions like Product Management, Marketing, Business Development and Digitalization. He’s one of the Co-Founders of Frontastic and works as Integrator and COO.
Stay In The Loop
Subscribe to our newsletter to keep up to date on all the latest Frontastic news.
As competitive pressures drive the need for digital transformation, enterprises have a mind-boggling number of factors to weigh when growing their digital experience. This decision-making process is especially tough for established brands with legacy infrastructure that represents years of investment in capital and human expertise. Frontastic partner Contentstack gives useful insights and a great overview of the decision-making process.
https://www.frontastic.cloud/wp-content/uploads/2021/03/Contentstack.jpg6301200Mira Polathttps://www.frontastic.cloud/wp-content/uploads/svg/Frontastic-Logo-Gradient.svgMira Polat2021-04-08 08:30:252021-03-31 14:15:12Is Your Enterprise Ready for MACH?
A composable architecture is a DIY approach to building a robust architecture using best-of-breed APIs. Frontastic partner GraphCMS gives useful insights and a great overview of composable architecture in this guest article.