cloudinary / frontend-frameworks

Cloudinary javascript frontend frameworks SDKs, including Shared HTML layer, Angular, React and Vue SDKs
https://www.cloudinary.com
MIT License
44 stars 15 forks source link

Recommendations for performance improvements in Cloudinary React SDK #240

Open atcastle opened 1 week ago

atcastle commented 1 week ago

Hello!

As part of my work with the Chrome Aurora team, I’ve been working with image-focused React libraries to help improve application performance (measured in Core Web Vitals) for the apps that use those libraries. I spoke with @colbyfayock, and he told me that Cloudinary would be willing to take a look at my recommendations.

Please see the accompanying PR(#239) for code related to these recommendations.

Recommendations:

1. Change the official documentation to recommend the use of native loading instead of the loading plugin.

The current intersectionObserver-based lazy loading plugin relies on JavaScript and does not work for server-side rendered images. [Native lazy loading] (https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/loading) is well-supported across modern browsers, and works in a SSR context.

Additionally, the native lazy loading syntax is very simple, and works cross-framework.

Rather than modify the existing plugin, I would recommend a change to the plugin documentation visible on the transformation pages such as https://cloudinary.com/documentation/react_image_transformations#plugins. I suggest removing the initial link to the lazy loading plugin, and then modifying the section under the “Lazy Loading” subheading to describe lazy-loading as a technique that can be implemented just by adding loading=“lazy” as an attribute on the AdvancedImage element. You could mention that the lazy loading plugin is still available for legacy purposes, and (optionally) to support the cases where users need to customize their root margin and threshold.

2. Implement a warning for lazy-loading the LCP image.

In other image components I’ve worked with, one performance issue I’ve seen come up repeatedly is users applying loading=“lazy” to all their images, including the one which ends up being the largest contentful paint element. Doing so negates much of the LCP benefits that come from server-side rendering, and often I’ve found that (from a Core Web Vitals) perspective, apps that make this mistake would have been better off not doing any lazy loading at all.

As such, I recommend implementing a simple dev-environment-only warning message that logs a warning when it detects an LCP image with the loading=“lazy” attribute. See the accompanying PR(#239) for an implementation of this warning.

3. Implement a warning for oversized images.

Another common cause of bad image-related LCP scores is applications including oversized images. That is, images which are downloaded with an intrinsic size substantially larger than their rendered size. Especially given that applications using the Cloudinary have access to dynamic image resizing, we should make sure to alert users when this is happening.

To do so, I’ve included another warning in the accompanying PR(#239), which logs a warning in development environments when oversized images are detected. Both this and the above warning are dismissible with a attribute on the AdvancedImage element

Please let me know if you have any questions about these recommendations. Thank you!

tamaracloudinary commented 1 week ago

Thanks @atcastle, we will review your suggestions in the next couple of days.