DEV Community: Alexandre CANTIN

Accélérer vos pages Web : quelques réflexes ⚡️ (partie 3)

Alexandre CANTIN — Tue, 04 Aug 2020 10:19:43 +0000

Cet article sera le troisième et dernier d'une série de trois :

Images et polices personnalisées (https://dev.to/alexandrecantin/optimiser-vos-pages-web-quelques-reflexes-indispensables-g79)
JavaScript et pré-chargement de ressources (https://dev.to/alexandrecantin/accelerer-vos-pages-web-quelques-reflexes-partie-2-2oh3)
Contenus animés et LightHouse (cet article)

🎬 5 - Contenus animées : .mp4 et GIF

5.1 - Privilégier les vidéos .mp4 sur les GIF

Cette recommandation peut sembler contre-intuitive mais, dans le cas des GIFs, il est nécessaire de les convertir en .mp4 pour diminuer leur poids.

En effet, bien que le format GIF soit un format d'image, il s'agit d'une succession d'images et peut donc être assimilé à une vidéo. Toutefois, contrairement au format .mp4, le format GIF est moins bien optimisé.

Prenons par exemple, le GIF ci-dessous dont le poids est de 5.1 Mo :

Après une conversion en .mp4 (via https://video.online-convert.com/fr/convertir/gif-en-mp4 par exemple), son poids se retrouve divisé par 5 pour atteindre 1.1 Mo.

Pour ensuite obtenir un rendu et comportement similaires à ceux d'une image GIF, il est nécessaire d'ajouter les attributs autoplay loop muted playsinline à la balise video :

<video autoplay loop muted playsinline>
   <source src="video.mp4" type="video/mp4" />
</video>
```



Si vous souhaitez aller plus loin, il est aussi possible d'adapter le rendu en fonction de la qualité de la connexion Internet de l'utilisateur avec `navigator.connection.effectiveType` pour, par exemple, renvoyer une image (optimisée bien entendu) à la place d'une vidéo :



```javascript
if(navigator.connection.effectiveType === "4g")
  return <Video src="animate-background.mp4" />

return <img src="background.png" alt="" />
```



Malheureusement, cette fonctionnalité est pour le moment très mal supportée par les différents navigateurs :

![La support n'est pas top !](https://dev-to-uploads.s3.amazonaws.com/i/53lw03topkh1xzbs89hj.png)

### 5.2 - Attention au player Youtube 
Youtube fournit un moyen simple d'héberger mais aussi d'intégrer des vidéos dans vos pages via une _iframe_. Toutefois, cette dernière va télécharger tous un ensemble de fichiers pour un total de 584 Ko !

![Total des téléchargement de Youtube pour 584 Kilos](https://dev-to-uploads.s3.amazonaws.com/i/44t0snl0mzw9kx68m9lr.png)

Bien sûr, à ce temps de téléchargement s'additionne le temps de _parsing_, compilation et d'exécution du navigateur. Qui plus est, l'utilisateur paiera ce prix qu'il **visionne ou non** cette vidéo !
Comment éviter cela ? Deux solutions sont envisageables.

#### 5.2.1 - Le _lazy loading_
La première solution renvoie au chapitre relatif au _lazy loading_ des images : l'iframe la plus optimale reste celle qu'on ne télécharge pas. De même, les deux solutions évoquées sont aussi d'actualités, à savoir :

1 - Utiliser _lazysizes_ en remplaçant l'attribut `src` par `data-src`:



```html
<iframe frameborder="0" allowfullscreen=""
data-src="//www.youtube.com/embed/ZfV-aYdU4uE">
</iframe>
```



2 - Utiliser l'attribut `loading="lazy"` (dont le support - ou son manque de support - reste identique aux images) :



```html
<iframe frameborder="0" allowfullscreen="" src="//www.youtube.com/embed/ZfV-aYdU4uE" loading="lazy"></iframe>
```



Toutefois, le problème n'est résolu qu'à moitié : dès que la vidéo apparaît à l'écran de l'utilisateur, nous récupérons l'ensemble des 584 Ko de JavaScript.


#### 5.2.2 - Un _faux_ lecteur vidéo

L'idée, au premier abord, peut sembler saugrenue mais permet d'obtenir le résultat escompté : remplacer le _player_ Youtube par un bouton contenant une image de pré-visualisation associée à une icône de lecture. En cas de clic, nous basculons ensuite sur l'iframe de Youtube en lecture automatique (via `autoplay=1`).

Note : pour réaliser ce composant, nous utiliserons React mais une transposition vers des équivalents Svelte, Vue ou Angular est facilement envisageable.

Ce composant accueillera deux paramètres que seront :
- l'identifiant de la vidéo Youtube
- le titre de vidéo (pour l'accessibilité - notamment ceux avec un lecteur d'écran)

Pour utiliser ce composant, nous procéderons de la sorte :


```javascript
<YoutubeVideo id="dQw4w9WgXcQ" title="Never gonna give you up" />
```



Tout d'abord, nous commencerons par créer le bouton en question :



```javascript
import React from "react";

function YoutubeVideo({ id, title }) {
  return (
    <button
      type="button"
      title={`Vidéo Youtube : ${title}`}
      style={buttonStyle}
      onClick={startVideo}
    >
      <img style={imgStyle} src={`https://img.youtube.com/vi/${id}/hqdefault.jpg`} alt="" />
      <img style={youtubeIconStyle} src="youtube-icon.svg" alt="" />
    </button>
  );
}

export default YoutubeVideo;
```



En ajoutant un peu de style à notre bouton, nous allons :
- indiquer les dimensions de la vidéo, dimensions qui seront identiques pour la vidéo et le bouton
- centrer l'icône de lecture verticalement et horizontalement
- ajuster l'image de pré-visualisation pour qu'elle occupe la totalité de l'espace disponible. D'ailleurs, concernant cette image, vous pouvez remarquer qu'elle provient directement de Youtube; l'image d'une vidéo pouvant être récupérée à l'adresse suivante : `https://img.youtube.com/vi/[IDENTIFIANT_VIDEO]/hqdefault.jpg`.




```css
/* Dimensions de la vidéo et du bouton */
const style = {
  width: "100%",
  height: "350px"
};

/* Centrer l'icône Youtube (entre autres...) */
const buttonStyle = {
  ...style,
  position: "relative",
  overflow: "hidden",
  cursor: "pointer",
  display: "flex",
  justifyContent: "center",
  alignItems: "center",
  border: "none"
};

/* Image de pré-visualisation pour occuper tout l'espace */
const imgStyle = {
  width: "100%",
  height: "100%",
  position: "absolute",
  zIndex: 1
};

/* Placer l'icône au-dessus de celle de pré-visualisation */
const youtubeIconStyle = {
  zIndex: 2
};
```



Pour le moment, nous obtenons un bouton qui ne fait simplement rien... mais qui ressemble fortement à la _preview_ d'une vidéo Youtube :

![On a l'impression d'avoir un lecture Youtube mais c'est juste un bouton](https://dev-to-uploads.s3.amazonaws.com/i/6cd7igy43cgwfzs8lbx7.png)


La suite consistera à ajouter une variable au sein de notre composant, nommée `showVideo`, gérant l'affichage de l'_iframe_. Elle sera à `false` par défaut et signifiera que l'on affichera le bouton de pré-visualisation. Au clic sur le bouton, `showVideo` deviendra `true` et occasionnera le démarrage de la vidéo.



```javascript
...
function YoutubeVideo({ id, imgSrc, title }) {
  // On utilise les hooks React
  const [showVideo, setShowVideo] = useState(false);

  function startVideo() {
    setShowVideo(true);
  }

  ...

  return (
    <button
      onClick={startVideo} // <=== Action au clic
      type="button"
      title={`Vidéo Youtube : ${title}`}
      style={buttonStyle}
    >
      <img style={imgStyle} src={`https://img.youtube.com/vi/${id}/hqdefault.jpg`} alt="" />
      <img style={youtubeIconStyle} src="youtube-icon.svg" alt="" />
    </button>
  );
}
```



La dernière étape consistera à renvoyer l'iframe Youtube si `showVideo` a une valeur égale à `true`. Noter l'ajout de `autoplay=1` après l'URL de la vidéo Youtube, c'est ce paramètre qui permet de démarrer la vidéo sans nécessiter de second clic par l'utilisateur :



```javascript
  if (showVideo) {
    return (
      <div>
        <iframe
          sandbox="allow-scripts allow-same-origin allow-presentation"
          title={`Vidéo Youtube : ${title}`}
          src={`https://www.youtube.com/embed/${id}?autoplay=1&rel=0`}
          frameBorder="0"
          allow="autoplay; encrypted-media"
          allowFullScreen
          style={style}
        />
      </div>
    );
  }
```



Et c'est aussi simple que cela, nous venons de créer un composant n'affichant (et téléchargeant) le lecteur Youtube uniquement si cela est nécessaire.

![GIF présentation le rendu](https://dev-to-uploads.s3.amazonaws.com/i/jz58n4aslrp66jm08ms8.gif)

_J'aurai bien voulu convertir ce GIF en mp4 mais dev.to n'accepte pas les vidéos 😔_

Au final, voici le code de notre composant au complet :



```javascript
import React, { useState } from "react";

const style = {
  width: "100%",
  height: "350px"
};

const buttonStyle = {
  ...style,
  position: "relative",
  overflow: "hidden",
  cursor: "pointer",
  display: "flex",
  justifyContent: "center",
  alignItems: "center",
  border: "none"
};

const imgStyle = {
  width: "100%",
  height: "100%",
  position: "absolute",
  zIndex: 1
};

const youtubeIconStyle = {
  zIndex: 2
};

function YoutubeVideo({ id, title }) {
  const [showVideo, setShowVideo] = useState(false);

  function startVideo() {
    setShowVideo(true);
  }

  if (showVideo) {
    return (
      <div>
        <iframe
          sandbox="allow-scripts allow-same-origin allow-presentation"
          title={`Vidéo Youtube : ${title}`}
          src={`https://www.youtube.com/embed/${id}?autoplay=1&rel=0`}
          frameBorder="0"
          allow="autoplay; encrypted-media"
          allowFullScreen
          style={style}
        />
      </div>
    );
  }

  return (
    <button
      type="button"
      title={`Vidéo Youtube : ${title}`}
      style={buttonStyle}
      onClick={startVideo}
    >
      <img style={imgStyle} src={`https://img.youtube.com/vi/${id}/hqdefault.jpg`} alt="" />
      <img style={youtubeIconStyle} src="youtube-icon.svg" alt="" />
    </button>
  );
}
export default YoutubeVideo;

```



Cette optimisation peut sembler s'apparenter à du bricolage mais le résultat est bien là : une diminution de plus de 500 Ko du poids de votre page et un téléchargement uniquement si l'utilisateur souhaite consulter la vidéo.


## 🧜🏻‍♀️ 6 - Lighthouse
Et s'il existait un outil testant l'ensemble de ces critères, voire plus ? Bonne nouvelle, cet outil existe et il se nomme Lighthouse !

Directement embarqué dans le navigateur Google Chrome ou disponible en ligne à l'adresse [https://developers.google.com/web/tools/lighthouse#psi](https://developers.google.com/web/tools/lighthouse), Lighthouse regroupe tout un panel de tests mesurant la vitesse - entre autres - de votre page.

![Page d'accueil de l'extension Lighthouse](https://dev-to-uploads.s3.amazonaws.com/i/uup90l9w1ys1um3zm1jh.png)

L'outil vous attribue ensuite un score sur 100 et des points d'améliorations.

![Exemple d'un score Lighthouse](https://dev-to-uploads.s3.amazonaws.com/i/c6hlkkj1lnoqy8u0uqgr.png)

Auditer et surveiller ces métriques régulièrement (une fois par mois par exemple) est un réflexe important pour vous assurer que votre site continue d'être performant au fur et à mesure de son évolution.


Je vous invite à tester votre site dès maintenant et, si vous ne l'avez jamais fait, des surprises vous attendent sûrement 😉 !

---

## 🚀 Conclusion

Nous voici arrivés à la fin de cette série d'articles consacrée à l'amélioration du chargement des pages Web. J'en profite pour vous remercier d'avoir pris le temps de la lire et j'espère qu'elle vous aura plu 🙂

Toutefois, ce billet n'a pas la prétention d'être exhaustif et d'autres optimisations aurait pu être abordées comme http2, les CDN... Je vous invite d'ailleurs à l'indiquer en commentaires 🙂.

Je vous remercie d'avoir pris le temps de lire cette série et j'espère que dorénavant, vous contribuerez à créer un web plus léger 😉.

---

## 🔰 Aller plus loin

### Vidéos et articles
Voici un ensemble de ressources pour explorer l'univers de l'optimisation des chargements :

- Fast load times : https://web.dev/fast/

- Lazy-loading d'images et _iframe_ : https://web.dev/native-lazy-loading/

- Code-splitting in React : https://reactjs.org/docs/code-splitting.html#route-based-code-splitting

- Web performance made easy (Google I/O '18) :
 https://www.youtube.com/watch?v=Mv-l3-tJgGk

- Speed at Scale: Web Performance Tips and Tricks from the Trenches (Google I/O ’19) : https://www.youtube.com/watch?v=YJGCZCaIZkQ

### Sur Twitter
- Houssein Djirdeh : https://twitter.com/hdjirdeh
- Addy Osmani : https://twitter.com/addyosmani
- Katie Hempenius : https://twitter.com/katiehempenius
- Paul Irish : https://twitter.com/paul_irish
- Lighthouse : https://twitter.com/____lighthouse

Accélérer vos pages Web : quelques réflexes ⚡️ (partie 2)

Alexandre CANTIN — Wed, 22 Jul 2020 06:42:56 +0000

Cet article sera le deuxième d'une série de trois :

Images et polices personnalisées (lire l'article)
JavaScript et pré-chargement de ressources (cet article)
Contenus animés et LightHouse (à venir)

🃏 3 - JavaScript

L'utilisation du JavaScript a littéralement explosé ses dernières années avec l'avènement de Node.js et ses nombreuses librairies disponibles via NPM, auxquelles s'ajoutent les Single Page Application : Angular, Vue et React.

3.1 - Code splitting

Le terme SPA (Single Page Application) résume à lui tout seul son principe sous-jacent : l'ensemble de notre application est contenu dans une unique page - et par conséquent dans un seul fichier JavaScript, dont la taille est forcément corrélée au nombre de fonctionnalités proposées par votre site.

Bien entendu, au niveau visuel, l'utilisateur a l'impression d'avoir face à lui plusieurs pages grâce à un découpage entre différents composants et notamment à l'aide d'un router. Dans l'univers de React, le router le plus utilisé et connu est le https://github.com/ReactTraining/react-router/ :

import React from 'react';
import { BrowserRouter as Router, Route, Switch } from 'react-router-dom';

import Home from './routes/Home';
import About from './routes/About';

const App = () => (
  <Router>
    <Switch>
      <Route exact path="/" component={Home}/>
      <Route path="/a-propos" component={About}/>
    </Switch>
  </Router>
);

Note : des équivalents existent pour Svelte / Vue / Angular mais nous nous focaliserons sur React ici 🙂

Dans cet exemple, notre bundle final contiendra le code de la page d'accueil et de la page "À propos"; mais aussi toutes les autres pages qui seront présentes dans ce router, pouvant se compter par dizaines.
Toutefois, vos utilisateurs parcourent rarement l'ensemble de vos pages mais récupère pourtant tout le JavaScript pour le faire : une optimisation en perspective donc !

Pour pallier ce problème, le code splitting a vu le jour. Ce dernier permet de subdiviser notre bundle en différentes sous-divisions pour n'envoyer aux utilisateurs que le strict nécessaire pour la page courante.

Dans l'écosystème React, cette possibilité nous est offerte par la combinaison de deux fonctions internes :

lazy : prenant en paramètre un import dynamique, qui sera ici notre composant : const About = lazy(() => import('./routes/About'));
Suspense : composant React dont l'objectif est d'attendre la résolution d'une promesse, l'import dynamique de lazy dans notre cas. Suspense accepte aussi un paramètre fallback pour indiquer un texte ou un composant à exécuter en attendant la résolution de notre promesse :

<Suspense fallback={<div>Chargement...</div>}>
  ...
</Suspense>

Au final, afin d'obtenir un code-splitting fonctionnel, nous devons adapter l'exemple précédent comme suit :

import React, { Suspense, lazy } from 'react';
import { BrowserRouter as Router, Route, Switch } from 'react-router-dom';
const Home = lazy(() => import('./routes/Home'));
const About = lazy(() => import('./routes/About'));

const App = () => (
  <Router>
    <Suspense fallback={<div>Chargement...</div>}>
      <Switch>
        <Route exact path="/" component={Home}/>
        <Route path="/a-propos" component={About}/>
      </Switch>
    </Suspense>
  </Router>
);

Bien sûr, cela peut sembler inutile de réaliser du code-splitting sur un site contenant deux pages 🙂 mais rassurez-vous, l'effet est démultiplié au fur à mesure que le nombre de pages augmente.

3.2 - Poids des librairies externes

3.2.1 - Bundle Phobia

NPM a permis l'introduction de bon nombre de librairies que nous pouvons inclure et utiliser dans notre JavaScript côté front. Toutefois, leur accumulation alourdit petit à petit le poids de nos fichiers et par conséquent ralentit le chargement de notre page. Surveiller le poids des librairies tierces est donc un réflexe nécessaire.

Pour cela, je ne peux que vous conseiller le site BundlePhobia dont le nom est éloquent : le site est à destination des développeurs craignant d'alourdir le poids de leur bundle.

BundlePhobia vous met à disposition un formulaire de recherche vous permettant d'indiquer la librairie à analyser. Il vous renvoie ensuite son poids et une estimation de son temps de chargement :

N'oubliez pas de vérifier si la librairie en question est aussi tree-shakable. Une librairie tree-shakable est une librairie dont les parties non utilisées seront retirées du bundle final, occasionnant donc une réduction du poids de nos fichiers JavaScript. Par chance, BundlePhobia nous l'indique 🥳

Pour finir, nous avons aussi une liste de librairies alternatives offrant des fonctionnalités similaires :

3.2.2 - Import Cost

Afin de surveiller le poids de votre librairie d'une manière plus régulière, une extension Visual Studio Code nommée Import Cost vous indique le poids des librairies que vous incorporez dans votre code :

Vous trouverez cette extension facilement dans le MarketPlace de Visual Studio Code :

💠 4 - Préchargement de ressources secondaires avec `<link rel="preload" />`

4.1 - Fonctionnement de `preload`

Les premiers fichiers téléchargés dans nos pages sont souvent la porte d'entrée pour le téléchargement d'autres fichiers (polices, scripts complémentaires, images...), ceci est d'autant plus vrai depuis l'arrivée de librairies/frameworks comme React, Vue, Angular ou encore Svelte.

Ce fonctionnement ralentit considérablement notre page car plusieurs vagues de téléchargement sont alors nécessaires pour générer le rendu final.

Toutefois, vu que nous connaissons les fichiers qui seront récupérés en deuxième ou troisième vague de téléchargement, ne pourrait-on pas indiquer au navigateur de le pré-télécharger afin de les avoir directement à disposition quand nous en aurons besoin ? C'est tout à fait possible avec <link rel="preload" /> :

<link rel="preload" href="/fonts/custom-font.woff2" as="font">

Dans cet exemple, nous indiquons à notre navigateur de pré-télécharger le fichier /fonts/custom-font.woff2 car nous en aurons besoin pour le premier affichage de notre page.
J'insiste lourdement sur le terme pour le premier affichage de notre page. En effet, si vous indiquez des ressources dont vous ne faites aucun usage direct, vous obtenez alors l'effet inverse : vous consommez des ressources réseaux au détriment de fichiers plus prioritaires ! À utiliser avec intelligence et précision donc 🙂.

D'ailleurs, Google Chrome nous indique si nous avons pré-téléchargé un fichier dont nous ne faisons pas usage dans trois secondes suivant la fin du chargement de la page (événement onload) :

4.2 - Spécifications

Au niveau de sa composition, cette balise autorise les attributs :

rel : contenant "preload" pour indiquer qu'on souhaite un pré-chargement d'une ressource (d'autres valeurs sont possibles mais on reviendra dessus plus tard)
href : indiquant le lien de la ressource à récupérer, qui peut être un lien interne ou externe (Google Font par exemple).
as : pour indiquer le type de ressource : "font", "script", "style", "video", "image"... (liste complète disponible à cette adresse). L'ajout et la complétion de cet attribut a une très grande importance : elle permet au navigateur d'appliquer la bonne Content Security Policy, d'utiliser les bons header HTTP mais aussi de mieux identifier la ressource pour éviter sa double récupération.
crossorigin (optionnel) : permettant de gérer les Cross-origin resource sharing (CORS) et devant contenir obligatoirement "origin" pour les polices afin d'éviter un double téléchargement (même depuis une origine équivalente).
type (optionnel) : pour indiquer le format du fichier téléchargé et permettre au navigateur d'empêcher le téléchargement si ce type n'est pas géré (ex: .webp et Safari)
media : pour ne déclencher le téléchargement que sous certaines conditions :

<link rel="preload" as="image" href="small-background.jpg" media="(max-width: 800px)">
<link rel="preload" as="image" href="large-background.jpg" media="(min-width: 801px)">

4.3 - Support navigateur

Au niveau de son support, et aussi bizarre que cela puisse paraître, seul Firefox ne supporte pas nativement l'attribut rel="preload" qui est actuellement au statut expérimental et doit être activé dans la configuration du navigateur. Espérons que cette situation sera rapidement corrigée 🙂.

Fin de la deuxième partie

Nous voici arrivés à la fin de cette deuxième partie consacrée aux optimisations liées JavaScript et le pré-chargement de ressources.
Dans le prochain et dernier épisode, nous finirons en beauté les contenus animées (vidéos/GIF) et Lighthouse.

Restez connecté 🙂.

🔰 Aller plus loin

Vidéos et articles

Voici un ensemble de ressources pour explorer l'univers de l'optimisation des chargements :

Fast load times : https://web.dev/fast/
Preload, Prefetch And Priorities in Chrome : https://medium.com/reloading/preload-prefetch-and-priorities-in-chrome-776165961bbf
Preload: What Is It Good For? : https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/
Code-splitting in React : https://reactjs.org/docs/code-splitting.html#route-based-code-splitting
Web performance made easy (Google I/O '18) :
https://www.youtube.com/watch?v=Mv-l3-tJgGk
Speed at Scale: Web Performance Tips and Tricks from the Trenches (Google I/O ’19) : https://www.youtube.com/watch?v=YJGCZCaIZkQ

Accélérer vos pages Web : quelques réflexes ⚡️ (partie 1)

Alexandre CANTIN — Mon, 08 Jun 2020 19:46:16 +0000

Cet article sera le premier d'une série de trois :

Images et polices personnalisées (cet article)
JavaScript et pré-chargement de ressources (à venir)
Contenus animés et LightHouse (à venir)

Depuis sa naissance en 1989, le Web n'a cessé d'offrir plus de possibilités aux développeurs afin de créer la meilleure expérience possible pour nos utilisateurs : images, vidéos, interfaces dynamiques avec JavaScript, polices personnalisées etc.
Toutefois, cela n'est pas sans conséquence : le poids de nos pages a augmenté et il n'est pas rare qu'une page Web dépasse désormais un voire plusieurs mégaoctets.

D'ailleurs, selon Httparchive.org, en dix ans, malgré l'augmentation constante des débits Internet, la vitesse de chargement des pages est restée... la même. De plus, Google considère désormais les performances comme un facteur influençant son algorithme de ranking.

Dans cet article, nous présenterons ainsi différentes méthodes pour alléger vos pages. Cette liste sera non exhaustive et nous nous concentrerons sur les principaux leviers parmi la centaine (voire les milliers!) envisageables.

Note : les éléments présentés ci-dessous visent les utilisateurs arrivant pour la première fois sur votre site. Par conséquent, les services workers ne seront pas abordés.
De même, je n'aborderai pas des techniques que je considère comme déjà acquises comme la minification du CSS et du JavaScript

🏞 1 - Les images

Omniprésentes, les images sont les principaux responsables de l'alourdissement du Web. Leur bonne gestion doit donc être l'une de vos priorités et j'oserai même dire un réflexe indispensable en tant que développeur.

1.1 - Réduction du poids : PNG et JPG

Peut-être l'ignorez-vous (ou n'y pensez simplement pas) mais il est possible d'optimiser les images pour en réduire -drastiquement- le poids.
Pour ma part, je ne peux que vous conseillez d'utiliser https://tinypng.com/ qui fonctionne via un simple drag and drop.

Nous allons maintenant tester son efficacité avec l'image de ce chat au format JPEG et pesant 357 Ko sans optimisation :

Si nous l'optimisons, TinyPng nous indique que le poids du fichier a été réduit de 49%, de 357 Ko à 181 Ko :

Un poids divisé de moitié pour un rendu équivalent :

Sachant que ce gain se répète pour chacune image de votre page, on comprend vite l'intérêt crucial de bien optimiser l'ensemble de ses images.

1.2 - Quand choisir JPEG et PNG ?

Un autre point important est de choisir le bon format en fonction de vos besoins. En effet, ils répondent tous les deux à des exigences différentes et votre choix dépendra de plusieurs facteurs :

la taille de l'image : pour les "grandes" images (photos notamment), il faudra privilégier le format JPEG. Pour les "petites" images (émoticônes, icônes...), il faudra opter pour les PNG. Et si votre image est de taille "moyenne" ? Il faudra mener votre propre enquête pour déterminer le meilleur choix (en fonction du poids mais aussi des autres critères).
précision du dessin : le format JPEG, étant un format compressé, les contours perdent en netteté et cela n'est pas forcément souhaitable (graphiques, logo etc.). Il faudra opter pour le format PNG dans ce cas.
transparence : dans ce cas-là, le PNG est la seule solution 🙂

1.3 - Réduction du poids : SVG

Les images SVG peuvent aussi être optimisées. Pour ma part, j'utilise SVGOMG qui fonctionne lui aussi via drag and drop.

Dans l'exemple ci-dessus, on constate que le poids de notre SVG a réduit de 60%, passant de 1.5 Ko à 643 bytes et, même si le résultat reste moins spectaculaire comparé aux PNG et JPG, cela reste toutefois appréciable 🙂

1.4 - Allez plus loin avec Webp

Créé par Google en 2010, le Webp est un format d'image qui se veut - en moyenne - 30% plus léger comparé au JPEG et 25% par rapport au PNG; tout en conservant gardant les effets de transparence pour ce dernier format.

Le Webp est donc un remplaçant de choix pour tous vos fichiers JPG et au niveau des PNG, Webp étant un format compressé, cela dépendra principalement de la précision du contour que vous souhaitez obtenir.

Un des soucis majeur de ce format est son support dans les principaux navigateurs. En effet, bien que Chrome, Firefox et Edge (uniquement dans sa dernière version) acceptent ce format, Safari le supportera dans sa prochaine version :

Cela ne doit pas pour autant vous décourager d'utiliser le format Webp et nous verrons plus tard comme gérer les navigateurs non compatibles.

Pour convertir vos images en Webp, je peux vous conseiller d'utiliser XnConvert qui fonctionne directement sur votre ordinateur (disponible pour Windows/Linux/MacOs). Comme solutions en ligne, https://ezgif.com/png-to-webp et https://ezgif.com/jpg-to-webp fonctionnent très bien 🙂.

La conversion se réalise en 3 étapes (nous partirons de l'image du chat optimisée précédemment) :

1- Ajouter les images :

2- Cliquer sur l'onglet "Sortie" puis :

Indiquer "{Filename}.png" ou "{Filename}.jpeg" dans le champ "Nom du fichier". Le choix de ce formatage sera important pour la suite 😉
Choisir "WEBP-Webp" dans le bloc format
Décocher la case "Préserver les métadonnées" et cocher "Préserver l'extension"

3- Pour finir, cliquer sur "Convertir" en bas à droite de la fenêtre :

Nous obtenons ainsi une image avec le nom : [nom-image].jpeg.webp (ou [nom-image].png.webp). Dans notre exemple, le poids est passé de 181 Ko à 149 Ko.

1.4.1 - Cohabitation entre Webp et PNG/JPEG avec `<figure>`

Introduite en 2015, la balise <picture> permet de spécifier plusieurs règles afin que le navigateur puisse déterminer l'image la plus pertinente à télécharger. Plusieurs conditions sont possibles : densité de pixels, dimensions du navigateur... et le format d'image 🙂.

Pour utiliser <picture>, il suffit de lui associer plusieurs <source> :

<picture>
  <source srcset="chat-mignon.webp" type="image/webp">
  <source srcset="chat-mignon.jpeg" type="image/jpeg">
  <img src="chat-mignon.jpeg" alt="" />
</picture>

Dans cet exemple, le navigateur optera pour le format Webp s'il le gère et JPEG dans le cas contraire. L'usage de <picture> est donc d'une grande simplicité 🙂.

Malheureusement, il nous reste le cas d'une image importée via CSS et malheureusement, il n'existe pas d'équivalents à <picture> pour le CSS.

La solution est alors d'utiliser JavaScript pour déterminer ce support et notamment via ce snippet (proposé par Jake Archibald) :

async function supportsWebp() {
  if (!self.createImageBitmap) return false;

  const webpData = 'data:image/webp;base64,UklGRh4AAABXRUJQVlA4TBEAAAAvAAAAAAfQ//73v/+BiOh/AAA=';
  const blob = await fetch(webpData).then(r => r.blob());
  return createImageBitmap(blob).then(() => true, () => false);
}

En fonction de la réponse, vous pourrez ajouter une classe webp ou no-webp à la balise <body> pour, ensuite, au niveau du CSS, utiliser cette classe pour appeler la bonne image :

.no-webp .cat-background {
  background-image: url("chat-mignon.jpg");
}

.webp .cat-background {
  background-image: url("chat-mignon.webp");
}

1.4.2 - Cohabitation entre Webp et PNG/JPEG avec nginx

Si vous ne souhaitez pas convertir l'ensemble de vos balises <img /> de votre projet ou d'utiliser une classe à la balise <body>, il est possible de délivrer le bon format d'image en fonction du support du navigateur et cela grâce à Nginx.

Pour obtenir ce comportement, la premier prérequis sera de faire cohabiter l'image JPEG/PNG à côté de son équivalent Webp. Nous obtenons ainsi :

images/
  - chat.jpeg
  - chat.jpeg.webp

Dans un second temps, nous utiliserons l'instruction map de Nginx pour créer une variable $webp_suffix. Cette dernière contiendra .webp ou sera vide en fonction du support de Webp par le navigateur. Ce support sera déterminé suivant le contenu du header HTTP Accept de la requête :

    # Detect if browser accepts .webp images ?
    map $http_accept $webp_suffix {
      default"";
      "~*webp" ".webp";
    }

Pour finir, nous utiliserons la commande try_files de Nginx, permettant de tester la présence de plusieurs fichiers successivement et renvoyer le premier trouvé.

    # Handle .webp

    location ~* ^/assets/.+\.(jpe?g|png)$ {
        root /home/deploy/build/;
        try_files $uri$webp_suffix $uri =404;
    }

Ainsi, nous testerons dans l'ordre :
1 - l'URL de la ressource concaténée avec la valeur $webp_suffix pouvant donc être <nom-image>.jpeg.webp ou <nom-image>.jpeg
2 - l'URL demandée en solution de secours (en cas d'absence du fichier Webp notamment)
3 - Erreur 404

Nous obtenons un système faisant cohabiter à la fois les images au format JPEG/PNG et Webp, basée sur la prise en charge du format par le navigateur de l'utilisateur.

D'ailleurs, on constate sur la console de Google Chrome que le fichier reçu est bien une image Webp :

1.5 - Lazy-loading

Les images les plus légères restent celles qu'on ne télécharge pas. Pour cela, le lazy-loading est la solution toute nommée et consiste à télécharger une ressource seulement si cela s'avère nécessaire. Dans le cas d'une image, l'élément déclenchant son téléchargement sera ainsi son apparition - ou sa proche apparition - dans la zone d'affichage de la page Web.

1.5.1 - Avec Lazysizes

Lazysizes est une librairie JavaScript nous facilitant la mise en place du lazy loading d'images. D'une taille compressée de 3.2Ko, son utilisation se veut assez simple en renommant notre attribut src en data-src:

    <img data-src="static/logo.jpg" class="lazyload" alt="" />

De plus, Lazysize nous permet aussi d'adapter les images en fonction de l'appareil de l'utilisateur (mobile, tablette ou PC).

    <img
      alt=""
      class="lazyload"
      data-srcset="small.jpg 500w, medium.jpg 640w, big.jpg 1024w"
      data-src="medium.jpg" />

Simple mais terriblement efficace 🙂

1.5.2 - Avec l'attribut `loading` de `img`

La balise img accueille depuis peu un nouvel attribut loading qui, couplé avec la valeur lazy, permet d'implémenter nativement un système de lazy loading :

<img src="chat-mignon.png" loading="lazy" alt="" />

Sa prise en compte est donc loin d'être garantie... Toutefois, vous ne perdez rien à implémenter ce nouvel attribut qui sera tout simplement ignoré par les navigateurs non compatibles 🙂 (qui téléchargeront donc directement l'image).

🚨 2 - Les polices personnalisées

Relativement récent dans l'histoire du Web, l'ajout des polices personnalisées apporte une touche de personnalisation supplémentaire au design de nos pages. Et même s'elles sont minimes, des optimisations restent possibles.

2.1 - Fonctionnement des polices personnalisées

Avant de nous attarder sur les améliorations de performances possibles, il est nécessaire de présenter le fonctionnement des polices personnalisées.

Tout d'abord, l'inclusion d'une police peut se réaliser de plusieurs manières mais les deux méthodes les plus courantes sont :

1- L'import direct de la police depuis notre serveur

@font-face {
    font-family: "Open Sans";
    src: url("/fonts/OpenSans-Regular-webfont.woff2") format("woff2"),
        url("/fonts/OpenSans-Regular-webfont.woff") format("woff");
}

2- Via une ressource externe (ici, Google Fonts) :

<link href="https://fonts.googleapis.com/css2?family=Open+Sans:wght@300" rel="stylesheet">

Dans tous les cas, l'utilisation dans nos styles CSS est identique :

body {
    font-family: "Open Sans", serif;
}

Bien entendu, la police n'est pas directement présente sur le navigateur et doit donc être téléchargée. Mais que se passe-t-il pendant ce temps au niveau de l'affichage ? Figurez-vous que le navigateur n'affiche tout simplement...rien ! Plus exactement, il compense l'absence de la police en la remplaçant par une police invisible dont la taille se veut proche du résultat final (via font-size et font-weight principalement).

Par défaut, cette situation va durer 3 secondes (sur Firefox et Chrome tout du moins) avant que le navigateur bascule sur la seconde police (serif dans notre exemple). Trois secondes pendant lesquelles l'utilisateur ne pourra lire le contenu de votre site...

Bien sûr, dès que la police sera téléchargée, l'affichage de votre page sera mis à jour (que ce soit avant ou après les 3 secondes de délai).

2.2 - Utilisation de display: swap

La règle CSS font-display permet de modifier la politique d'import des polices personnalisées, sa valeur par défaut est auto et correspond au scénario décrit précédemment.

En remplaçant auto par swap, le délai de basculement vers la police de remplacement passe alors de 3 secondes à 100 ms ! Un gain de temps appréciable et réduisant ainsi le Time to first meaningful paint, métrique définie par Google correspondant au temps d'apparition du premier contenu pertinent.

Son utilisation est extrêmement simple.

Dans notre premier cas d'import, nous ajoutons simplement font-display: swap; dans le bloc @font-face :

  @font-face {
     font-family: "Open Sans";
     src: url("/fonts/OpenSans-Regular-webfont.woff2") format("woff2"),
            url("/fonts/OpenSans-Regular-webfont.woff") format("woff");
     font-display: swap;
    }

Pour Google Fonts, depuis mai 2019, il suffit d'ajouter '&display=swap' dans l'URL d'import pour obtenir, par exemple :

<link href="https://fonts.googleapis.com/css2?family=Open+Sans:wght@300&display=swap" rel="stylesheet">

Si vous souhaitez gérer plus finement votre police d'import de polices, font-display autorise d'autres valeurs :

font-display: block
Cette option est semblable au fonctionnement par défaut : 3 secondes de police invisible avant de basculer sur la police de remplacement. Son seul intérêt est de s'assurer que nous ayons bien ces 3 secondes de délai, étant donné que tous les navigateurs peuvent avoir une politique auto différente comparée à celle de Firefox et Chrome.
font-display: fallback
L'option fallback réduit aussi le délai de basculement vers la police de remplacement à 100 ms mais limite aussi la durée de récupération de la police personnalisée à 3 secondes (là où swap n'impose pas de durée de temps). Elle permet donc d'indiquer au navigateur d'arrêter la récupération de la police si son téléchargement s'avère trop long.
font-display: optional
Plus radicale que fallback, elle réduit le délai de basculement à 100 ms mais arrête la récupération de la police par la même occasion. Traduction pour le navigateur: "Si tu as la police sous la main (donc en cache) tu l'utilises, sinon inutile de la récupérer".

Fin de la première partie

Nous voici arrivés à la fin de cette première partie consacrée aux images et aux polices personnalisées.
Dans le prochain épisode, nous aborderons les optimisations liées JavaScript et le pré-chargement de ressources.

Restez connecté 🙂.

🔰 Aller plus loin

Vidéos et articles

Voici un ensemble de ressources pour explorer l'univers de l'optimisation des chargements :

Fast load times : https://web.dev/fast/
Lazy-loading d'images et iframe : https://web.dev/native-lazy-loading/
Web performance made easy (Google I/O '18) :
https://www.youtube.com/watch?v=Mv-l3-tJgGk
Speed at Scale: Web Performance Tips and Tricks from the Trenches (Google I/O ’19) : https://www.youtube.com/watch?v=YJGCZCaIZkQ
Polices personnalisées :
https://developers.google.com/web/updates/2016/02/font-display

Sur Twitter

Houssein Djirdeh : https://twitter.com/hdjirdeh
Addy Osmani : https://twitter.com/addyosmani
Katie Hempenius : https://twitter.com/katiehempenius
Paul Irish : https://twitter.com/paul_irish
Lighthouse : https://twitter.com/____lighthouse

Parcours d'arbre : Depth First & Breadth First 🌳

Alexandre CANTIN — Thu, 30 Apr 2020 11:11:25 +0000

Le parcours d'arbre est un grand classique lors d'entretiens algorithmiques et bien que cet exercice peut sembler intimidant aux premiers abords, nous allons découvrir qu'il y a, en réalité, plus de peur que de mal !

Ainsi, dans cet article, nous nous intéressons aux deux méthodes les plus courantes afin de parcourir un arbre que sont :

le parcours en profondeur (Depth First), où le choix du prochain noeud se porte sur le premier enfant du noeud courant :

le parcours en largeur (Breadth First), où le prochain noeud est celui adjacent au noeud courant, c'est-à-dire celui situé au même niveau de profondeur :

Parcours en profondeur - Depth first

Au niveau algorithmique, l'utilisation de la récursivité reste le choix le plus pertinent. Ainsi, nous utiliserons la récursivité pour notre parcours mais nous y ajouterons toutefois une étape supplémentaire, pour les besoins de l'article, en stockant les noeuds dans une structure de données.
En effet, dès l'entrée dans un noeud et après le traitement de sa valeur, nous stockerons ses enfants dans une structure de données (contenant une méthode saveNode), récupérerons ensuite le prochain noeud (méthode getNextNode) et passerons à la prochaine étape de notre parcours. En pseudo-code, nous obtenons ainsi :

// Structure de données encore inconnue
class Structure {
  saveNode(node) {}
  getNextNode() {}
}

// Fonction de traitement d'un noeud
var nodeStructure = new Structure()
function computeNode(node) {
  if(!node) return;

  computeNodeValue(node.value)

  if(node.left) nodeStructure.saveNode(node.left)
  if(node.right) nodeStructure.saveNode(node.right)

  computeNode(nodeStructure.getNextNode())
}

// Création de l'arbre et début du parcours
var tree = new Tree(...)
computeNode(tree.root)

Maintenant, si nous déroulons un exemple plus concret avec l'arbre présenté en début d'article et le pseudo-code ci-dessus :

1ère étape :

Nous traitons la valeur du noeud : 1, nous sommes à la racine
Nous ajoutons ses deux enfants dans la structure de données : [2,5]
Nous récupérons le prochain élément : [2,5] => 2, [5]

2ème étape :

Nous traitons la valeur du noeud : 2
Nous ajoutons ses deux enfants dans la structure de données : [3, 4, 5]
Nous récupérons le prochain élément : [3, 4, 5] => 3, [4,5]

3ème étape :

Nous traitons la valeur du noeud : 3
Pas d'enfant, la structure est inchangée : [4, 5]
Nous récupérons le prochain élément : [4, 5] => 4, [5]

4ème étape :

Nous traitons la valeur du noeud : 4
Pas d'enfant, la structure est inchangée : [5]
Nous récupérons le prochain élément : [5] => 5, []

5ème étape :

Nous traitons la valeur du noeud : 5
Nous ajoutons ses deux enfants dans la structure de données : [6,7]
Nous récupérons le prochain élément : [6,7] => 6, [7]

6ème étape :

Nous traitons la valeur du noeud : 6
Pas d'enfant, la structure est inchangée : [7]
Nous récupérons le prochain élément : [7] => 7, []

7ème étape :

Nous traitons la valeur du noeud : 7
Pas d'enfant, la structure est inchangée : []
Nous récupérons le prochain élément : [] => x, []

8ème étape :

Pas de valeur et la structure est vide : le parcours est terminée

Après ce long déroulé, nous constatons que l'ordre d'ajout dans la liste à son importance : nous ne prenons que le noeud inséré le plus récemment. En algorithmique, ce concept est appelé Last In First Out, abrégé LIFO, et notre structure de données se doit de respecter cette règle pour devenir compatible avec le parcours en profondeur; comme par exemple une stack.
Un ajustement est juste nécessaire vis-à-vis du pseudo algorithme précédent : le noeud gauche y est inséré avant le noeud de droite. On parcourt ainsi l'arbre par la droite (1 - 5 - 7 - 6 - 2 - 4 - 3) et on doit ainsi permuter les deux lignes saveNode :

// Noeud droite avant le gauche
if(node.right) nodeStructure.saveNode(node.right)
if(node.left) nodeStructure.saveNode(node.left)

Nous en avons ainsi fini avec le parcours en profondeur. L'ajout d'une structure de donnée peut sembler au premier abord superflu mais, rassurez-vous, ce socle nous sera très utile pour le parcours en largeur.

Parcours en largeur - Breadth First

Pour le parcours en largeur, nous utiliserons une base identique à celle du parcours en profondeur, à savoir le pseudo-algorithme associé à une structure de données (encore inconnue à ce stade).
Si, comme précédent, nous effectuons un déroulé des différentes étapes du parcours, nous obtenons :

1ère étape :

Nous traitons la valeur du noeud : 1, nous sommes à la racine
Nous ajoutons ses deux enfants dans la structure de données : [2,5]
Nous récupérons le prochain élément : [2,5] => 2, [5]

2ème étape :

Nous traitons la valeur du noeud : 2
Nous ajoutons ses deux enfants dans la structure de données : [3, 4, 5]
Nous récupérons le prochain élément : [3, 4, 5] => 5, [3, 4]

3ème étape :

Nous traitons la valeur du noeud : 5
Nous ajoutons ses deux enfants dans la structure de données : [3, 4, 6, 7]
Nous récupérons le prochain élément : [3, 4, 6, 7] => 3, [4, 6, 7]

4ème étape :

Nous traitons la valeur du noeud : 3
Pas d'enfant, la structure est inchangée : [4, 6, 7]
Nous récupérons le prochain élément : [4, 6, 7] => 4, [6, 7]

5ème étape :

Nous traitons la valeur du noeud : 4
Pas d'enfant, la structure est inchangée : [6,7]
Nous récupérons le prochain élément : [6,7] => 6, [7]

6ème étape :

Nous traitons la valeur du noeud : 6
Pas d'enfant, la structure est inchangée : [7]
Nous récupérons le prochain élément : [7] => 7, []

7ème étape :

Nous traitons la valeur du noeud : 7
Pas d'enfant, la structure est inchangée : []
Nous récupérons le prochain élément : [] => x, []

8ème étape :

Pas de valeur et la structure est vide : le parcours est terminée

Ici, et contrairement au parcours en profondeur, ce n'est pas le dernier noeud inséré qui nous intéresse mais le plus ancien. Ce concept algorithmique, appelé First In First Out et abrégé FIFO, se doit donc d'être respecté par notre structure de données et comme exemple, nous pouvons citer une queue, cette dernière étant similaire à une file d'attente.

Conclusion

Plusieurs domaines de l’informatique exploitent la puissance des arbres : index de base de données, arbres de décision, analyse de code source (Abstract syntax tree)... et cela explique ainsi leur présence en entretien technique.

Toutefois comme nous venons de le voir, le parcours d'arbre en profondeur ou en largeur n’est pas si complexe et peut se résumer à une simple association avec une structure de données :

une structure respectant la logique LIFO pour un parcours en profondeur
et une structure respectant la logique FIFO pour un parcours en largeur

Deux concepts finalement faciles et rapides à retenir et qui, j'espère, ne vous fera plus craindre de futurs entretiens avec des parcours d'arbres !

DEV Community: Alexandre CANTIN

Accélérer vos pages Web : quelques réflexes ⚡️ (partie 3)

🎬 5 - Contenus animées : .mp4 et GIF

5.1 - Privilégier les vidéos .mp4 sur les GIF

Accélérer vos pages Web : quelques réflexes ⚡️ (partie 2)

🃏 3 - JavaScript

3.1 - Code splitting

3.2 - Poids des librairies externes

3.2.1 - Bundle Phobia

3.2.2 - Import Cost

💠 4 - Préchargement de ressources secondaires avec <link rel="preload" />

4.1 - Fonctionnement de preload

4.2 - Spécifications

4.3 - Support navigateur

Fin de la deuxième partie

🔰 Aller plus loin

Vidéos et articles

Accélérer vos pages Web : quelques réflexes ⚡️ (partie 1)

🏞 1 - Les images

1.1 - Réduction du poids : PNG et JPG

1.2 - Quand choisir JPEG et PNG ?

1.3 - Réduction du poids : SVG

1.4 - Allez plus loin avec Webp

1.4.1 - Cohabitation entre Webp et PNG/JPEG avec <figure>

1.4.2 - Cohabitation entre Webp et PNG/JPEG avec nginx

1.5 - Lazy-loading

1.5.1 - Avec Lazysizes

1.5.2 - Avec l'attribut loading de img

🚨 2 - Les polices personnalisées

2.1 - Fonctionnement des polices personnalisées

2.2 - Utilisation de display: swap

Fin de la première partie

🔰 Aller plus loin

Vidéos et articles

Sur Twitter

Parcours d'arbre : Depth First & Breadth First 🌳

Parcours en profondeur - Depth first

Parcours en largeur - Breadth First

Conclusion

💠 4 - Préchargement de ressources secondaires avec `<link rel="preload" />`

4.1 - Fonctionnement de `preload`

1.4.1 - Cohabitation entre Webp et PNG/JPEG avec `<figure>`

1.5.2 - Avec l'attribut `loading` de `img`