Recommendations for performance improvements in Cloudinary React SDK

Ouverte
  • Quelque chose ne va pas ?
#240 1 commentaire 1 réaction 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
30/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
react, typescript
Domaine
documentation, frontend, performance

Piste de recherche

Commencez par examiner PR #239 et la documentation sur la transformation d’images de React, en particulier les sections Plugins et Lazy Loading. Vérifiez comment AdvancedImage gère les avertissements de développement proposés, puis vérifiez que la documentation recommande le chargement natif et que les deux avertissements peuvent être ignorés comme décrit.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

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!

Langage dominant
TypeScript
Étoiles
49
Forks
17
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cloudinary/frontend-frameworks

Toutes les issues de cloudinary/frontend-frameworks

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.