Recommendations for performance improvements in Cloudinary React SDK
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 30/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- react, typescript
- Domain
- documentation, frontend, performance
Research direction
Start by reviewing PR #239 and the React image transformation documentation, especially the Plugins and Lazy Loading sections. Check how AdvancedImage handles the proposed development warnings, then verify that the documentation recommends native loading and that both warnings are dismissible as described.
Written by the indexing model from the issue text.
Description
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!
- Dominant language
- TypeScript
- Stars
- 49
- Forks
- 17
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from cloudinary/frontend-frameworks
-
AdvancedImage/AdvancedVideo crash: "Cannot read properties of undefined (reading 'htmlPluginState')" when unmounted before onMountedPossibly taken @strausr claimed this 138 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
cloudinary/frontend-frameworks#265 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 42/100
cloudinary/frontend-frameworks#253 · 5 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 38/100
cloudinary/frontend-frameworks#234 · 20 comments · 1 reaction ·
All issues in cloudinary/frontend-frameworks
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
devswha/herdr-web-ui#3875 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
area: runtime chore cli consistency dependencies developer-experience difficulty: easy discovery documentation enhancement good first issue help wanted hygiene json-output packaging priority: P3 tests version
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
discovery:other factory-active task-identify-harness-labels-done task-identify-issue-type-done
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
vercel/ai#25068 · 4 comments ·
Maintainers usually reply within 1 day
-
create-strapi-app doesn't await writing license.txt, so a failed write skips its error handlingOpenflag: invalid template issue: bug severity: low source: cli status: pending reproduction version: 5
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
strapi/strapi#28637 · 1 comment ·
Maintainers usually reply within 2 days