Well, first off, it's a matter of pride as a software engineer. We are telling people that we are going to charge them money for their website, and in doing so we must ensure that our own site is a model of perfection. Secondly, the lighthouse score affects things like search results, and user experience. Not directly... it isn't as if a great performance score guarantees search results, but it does indicate that our page would qualify strongly in search results in categories such as load time and performance.
To get the best of scores on the audit, we had to implement several forms of compression. The first line of compression being what is called minification. Minification is when you remove all of the unnecessary characters from a computer programming file. This makes the file size small, so that there is less data to be sent over the internet. The minifier we used was a combination of of two free compilers off the internet, combined with some edits we made ourselves.
The next kind of compression we implemented was Brotli compression. Brotli compression is a type of compression that you can apply to text files to make the size smaller for transfer. To implement it, we downloaded and compiled a free version of the google open-source Brotli Compressor and installed it on our system, and then used it to render brotli-compressed files along side of each of our section-html files.
The last form of compression we implemented was the webp image format. Webp is an image format that is considerably more efficient than png or jpg images. To do this, we downloaded and compiled a webp library from git hub, and then inserted calls to the executable into our publishing pipeline.
The brotli and the webp formats are not universally supported across all browsers, so we had to implement HTACCESS files that would detect support using the request headers, and route the requests accordingly.
One of the aspects of your file load that affects your score is TTFB (Time To First Byte). That's a measure of the time that your server takes to calculate the file it is going to respond with. By pre-rendering the html, instead of calculating it on the server, we have optimized our time to first byte. There is a downside to this: we end up with redundant information on the server. But that is ok in this application, because even with extra data storage the total size of our site is still relatively small.
Even after we got to end of all of that, we were still scoring between 81 and 90. That's a 'B'... but it's not an 'A'. We needed an A. Our results indicated that our issue we still had was with rendering time. There was a couple of factors that contributed to this. First was Layout thrashing. We redesigned the engine to remove the thrashing.
This was the final step in our journey to an 'A' score on the Google Lighthouse performance audit.
We believe that all this work was totally worth it. Our site loads lightning fast, even with a slow connection. This will help our ranking in search engines and improve our user experiences: and when it comes down to it, isn't that the goal of our website?
Do you need to improve your score? These step will help it, and I hope it helped. If you need to hire someone to do it for you, give Web Apps Actualized a call!
WebDev Suite (in house) - Microsoft Paint - Microsoft Paint 3d - Apache Open Office Draw - Microsoft Windows - Guitar Pro 6 - Stack Overflow - W3Schools - PHP.net - Web Browsers (Mostly Chrome) - Apache XAMPP - Git - Cmake - Brotli Compression - JShrink Minifier Combined with Rodrigo54 Minifier - cwebp