cloudinary / cloudinary/frontend-frameworks

Recommendations for performance improvements in Cloudinary React SDK

Open
#240 1 comment 1 reaction 0 assignees View on GitHub
Dominant language
TypeScript
Stars
50
Forks
17
PR merge metrics
No merged PRs in 30d

Description

Hello!

As part of my work with the [Chrome Aurora](https://developer.chrome.com/docs/aurora) team, I’ve been working with image-focused React libraries to help improve application performance (measured in [Core Web Vitals](https://web.dev/explore/learn-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](https://caniuse.com/loading-lazy-attr), 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”](https://cloudinary.com/documentation/react_image_transformations#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](https://web.dev/articles/lcp) 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!

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.