Five tips for surpassing google page speed score
Google calculations for page speed was always a painful mystery for developers since they had to improve the score, and there was no explicit clue what was going on; but now with this incredible given insights you can boost the score if you play around with the hints. In this article I'm going to write about my personal experience and approach towards this interesting topic.
Font preloading and swipe font face
One of the most frequent hints you might face during improvement is avoiding FOIT which stands for flash of invisible text (FOIT).
Most browsers will hide texts until the font is loaded completely. To avoid this we can ask browsers to use the system font while the custom font is being loaded and once the custome font is loaded, it will be replaced with the one initially used.
Practically we should use font-display: swap in the defined @font-face style.
If you're usign google fonts, don't forget to add the &display=swap parameter at the end of your Google Fonts URL:
<link href="https://fonts.googleapis.com/css?family=Roboto:400,700&display=swap" rel="stylesheet">
Be careful about render-blocking resources
Google Analytics, Cookie Conset Manager and GTM are the most used render-blocking resources.
In my case what suprised me was the improvemnet I got after replacing hardcoded google analytics script tag with a tag defined in GTM.
So basically hardcoded tags in <head> slowes down the page more in comparison to adding the same tags via GTM.
Here are some highlights to keep in mind:
- Configure cookie consent manager scripts via GTM
- Try to delay tags that are less important
- Keep in mind that every tag has its own impact based on the content and loading them asynchronously doesn't increase the score necessarily
- Add script tags to your pages when it's neccessary
Get ride of reduce unused JavaScript via code-spliting and loadable-components
My application was suffering from unused Js a lot, so I started applying stricter code split principles like using loadable-components and React.lazy.
Use nextjs image for loading the correct image size
Having the explicit dimentions lets browser calculate the aspect ratio for the image. In my case, while using next/image component with the defined width and height I noticed the width and height are not explicitly added to the image tag but it turned out this is a bug from the lighthouse API and wont affect the calculation
Don’t lazy load in-viewport images
We've heard a lot about lazyloading images, but don't forget that this really depends on the product.
Imaging a seller product which has a bunch of images at the very visible viewport. In this case if we try to follow js based image lazyloading for the above-the-fold ( first thing a visitor sees ) images it increases LCP and Speed Index value.
To prevent this one possible workaround can be using <img> HTML tag for all the above-the-fold ( first thing a visitor sees ) images and use the generic lazy-loading image component for the below-the-fold ( the rest invisible parts ) images.