"Do fewer things"
This will be dependent on the application, but there are certain upper limits on what you should send.
These performance changes are hard to demo, but on the course they were demo'd by simulating the compression and CDN locations.
We can chooce View original trace
in a lighthouse report to see the trace waterfall that went into the calculated score.
In the metrics that we are looking at, we can see how the web vitals are calculated on a timeline and compare this to our specific pages to get a better insight into what might the cause.
Maybe things like the JS and images are not shown on the screen or are optional?
We can defer using a few options (not all will be explored):
async
attribute (prevent blocking loads but still executes)<script async ... />
defer
attribute (don't execute until we are done)<script defer ... />
<body> <img /> <img /> <script /> <script /> </body>
loading="lazy"
for images - no longer a factor of LCP. The compatibility table of this shows a problem (Safari).<img loading="lazy" />
Even though you can delay images, they may still be quite big.
The example given related to the srcset
and sizes
attribute for the <img />
tag.
The other alternative is to use tools to crunch images (like TinyPNG, Squoosh, Sharp etc).
<link rel="preconnect" />
or <link rel="preload" />
.The aim of the game here is to prevent things from moving around.
Everything that we've worked on with "deferring" image load can be the enemy of CLS.
This is a little bit more abstract. This is the timed delay between the first click and execution of app code.
This has an interaction wil LCP. If users can click before the deferred LCP assets are parsed and executed, the event callback of the app code for the click could be delayed significantly.
Really, what we want is to answer if the users will wait for the content that is loading:
Did we improve performance? There were many changes that we made to improve the different metrics.
Other charts that can help: