Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie De-cluttering_the_web.pptx
Ähnlich wie De-cluttering_the_web.pptx (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
De-cluttering_the_web.pptx
- 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?
- 4. JavaScript is the enemy!
- 5. Code splitting …In Next.js
- 8. Request priority …with images …in native fetch calls
- 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
- 12. Using modern image formats ● WebP ● AVIF ● Progressive enhancement
- 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
- 18. Tools Webpack bundle analyzer Performance budget calculator Squoosh (highly recommend this image compressor) TinyJPG Responsive image breakpoints generator WebUtils compressor
- 19. Thank you for listening to my talk!
Hinweis der Redaktion
- 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