This should act as a demo of how we would tackle performance analysis of a web page/app. It is obvious that axo.dev is a VERY simple site and would not need this kind of deep analysis in a real situation (yet).
Perform a Lighthouse audit to create a report and to get a general feel for the performance of the site. We can do that in Chromes dev tools. Make sure to run it in Incognito mode or disable all extensions that would interfere with the page.
The report looks pretty good already with no glaring performance or accessibility problems. It would be nice to get a solid 100 on performance though, especially on a simple site like that.
The report shows us that there is a "Cumlulative Layout Shift" (CLS) while loading the page. This can degrade user experience and can be very annoying for users. For example when trying to click the "Ok" button, while an unexpected layout shift happens and you now clicked the "Cancel" button that was next to it. In our case the shift is pretty minimal but we would still want to find the root cause of it and fix it. To get more insights on the inner workings of the site we can use the Performance Insights panel in the Chrome dev tools.
Enable "Slow 3g" and "4x CPU Slowdown" to emulate a real world experience - a lot of users are still on slower devices and slow internet connections! And perform a Page Load measurement.
The page load report shows how ressources are being loaded, what kind of work the browser is doing and also shows the different performance metrics. We can click on the CLS button in the side bar to get more details of the shift.
The .info element apparently shifted to the left. Looking at the load graph we can also see that the shift happens at the same time as the custom Google font comfortaa had finished loading. We have found the root cause of the layout shift.
The fix for something like that is not always an obvious thing. We have to consider product requirements, priorities and actual feasibility of the fix.
In this case we can probably look into 3 main possible fixes:
This one is probably the easiest but the site might not look as pretty and our designers might not like the idea. We could use something like a system font stack instead which would load usable defaults on every machine -> https://systemfontstack.com/
At the moment the font gets loaded with font-display: swap which means the browser draws a fallback font while the custom font is being loaded. Once the custom font is loaded we swap fonts - no loading time limits.
We could change to font-display: fallback. In that case the font face is rendered with a fallback at first if it’s not loaded, but the font is swapped if its loaded. Important difference: if the custom font takes too much time to load it wont be swapped in and the page will use the fallback font for the rest of the pages lifetime.
We could try to somehow use CSS to add a fixed size/width to the .info elements. So that even if the font dimensions change it wont lead to shifting.