1. Building performant & user-centric
applications on the web.
Caleb Olojo, Fulltime Mechanic
@kaf-lamed-beyt @calebolojo
2. Outline
● From a Product Engineering perspective
● The state of the internet: JavaScript is the culprit
● Decluttering the web
● Prioritizing the request of important resources
● Optimizing Images😓
● Where do I go from here?
11. When you think you’ve done all –
assigning fetch priorities,
“preconnect”-ing to an external
domain, etc – that is needed to
boost performance…
Images
16. Have multiple layers of compression
Layer one
Total size of image assets =
20.5MB
With a Lossy image compression
algorithm.
Total size became 337.19KB
Layer two
With a Lossless image
compression algorithm, and
JPEG image file format…
Total size became 7.5MB
Layer three
Compression of result in
Layer two to a WebP image
format, resulted in a good
shrink ratio
Total size became 1.7MB
17. Where to go from here.
Core Web vitals
Establish network connections early to improve perceived page speed
Preload critical assets to improve loading speed
Preload critical assets to improve loading speed
The performance implication of rehydration in React
Use Lighthouse for performance budgets
Using Modern Image Formats: AVIF And WebP
Talk about the paradigm of software engineering. In the development lifecycle of a product/tool/software, whatever it may be. You can either make something Good, or something Fast, or you can make something Cheap.
But, it is only possible to build in line with two options alone. So which of the options will you choose? Do you settle for something Good and fast, that is not cheap? OR
Do you pick something that is cheap to make and fast, but isn’t very good? OR You’d settle for something that is freaking Good and Cheap, but it isn't fast (takes a very long time to make) This principle can be applied to software engineering. To get more context, we can appliy it to UI or Frontend Engineering. They are all contradicting each other.
An average web page on the internet has so many crap in that it does entirely depend on, to function properly. These things amongst others makes the web heavier and heavier every year.
Talk about the expense of JavaScript.
- code splitting: routes, components.
- minification
- continue in the next slide with practical examples (with code snippets)
Code splitting ensures that the code needed for a particular functionality is available upon request.
The lazy component should then be rendered inside a Suspense component, which allows us to show some fallback content (such as a loading indicator) while we’re waiting for the lazy component to load.
Native fetch
LCP images and blah blah blah
priority =”high” good for LCP images
The time it takes for your webpage to be fully interactive matters a lot. IT has a great effect on the user experience of people that use your app/website, and sometimes your conversion rate.
In the next slide we’ll take a look at how we can prevent some of these effects: an example is the cumulative layout shift that happens when we’re loading fonts.
Improving page speed by establishing connections to external domains with rel=”preload” rel=”preconnect”
Images are the most popular type of resource on a webpage, and most of the time they are always the largest.
Your end users prefer high quality images. YES, they don’t care about you. But, you as a developer needs to care about the sizes of images that you’ll be shipping on your website. If you’re considering an approach towards optimizing for the core Web vitals. You have to take into account that images fall into the culprit zone of web performance and they account for the Largest Contentful Paint elements
WebP and AVIF image formats provides an improvement for compression and still retain the quality that it becomes barely impossible for the human eye to notice the difference in quality.
You can add AVIF image type to your browser. However browsers that do not support this format will not be able to render these type of images. But, you can tap into the “Progresive enhancement pattern” by making sure that a supported image format – webp or AVIF – is delivered to the browser. Let’s see how it is done in the next slide.
Although the progressive enhancement might be a little bit similar to this pattern, it is completely different.
Manually compress or optimizes your images with tools like squoosh or tinyJPG (convert to webp first to retain quality) before uploading them to image services like Cloudinary.
Although, this was accomplished with a tool (squoosh) created by a team at Google – layer three
