octobre 15, 2018

Comment servir le code hérité aux navigateurs hérités

À propos de l'auteur

Shubham est un développeur front-end basé à Bangalore. Il glisse confortablement dans le continuum de la conception. Récemment, il a été…
Pour en savoir plus sur Shubham …

Alors que le regroupement efficace de ressources sur le Web a fait couler beaucoup d'encre ces dernières années, la manière dont nous envoyons des ressources frontales à nos utilisateurs est restée à peu près la même. même. Le poids moyen des ressources JavaScript et de style associées à un site Web augmente – même si la création d'outils pour l'optimisation du site Web n'a jamais été meilleure. Alors que la part de marché des navigateurs à feuillage persistant augmente rapidement et que les navigateurs commencent à prendre en charge de nouvelles fonctionnalités, il est temps de repenser la fourniture d'actifs pour le Web moderne?

Un site Web reçoit aujourd'hui une part importante de son trafic de la part de navigateurs permanents, dont la plupart prennent en charge ES6 +, les nouvelles normes JavaScript, les nouvelles API de la plate-forme Web et les attributs CSS. Cependant, les navigateurs existants doivent encore être pris en charge dans un avenir proche – leur part d'utilisation est suffisamment importante pour ne pas être ignorée, en fonction du nombre d'utilisateurs.

Aperçu rapide de L'utilisation de caniuse.com Le tableau révèle que les navigateurs à feuilles persistantes occupent une part du lion du marché des navigateurs – plus de 75%. Malgré cela, la norme consiste à préfixer CSS, à transpiler tout notre code JavaScript vers ES5 et à inclure des polyfills pour prendre en charge tous les utilisateurs qui nous intéressent.

Bien que cela soit compréhensible dans un contexte historique, le Web a toujours été progressif. amélioration – la question demeure: ralentissons-nous Internet pour la majorité de nos utilisateurs afin de prendre en charge un nombre décroissant de navigateurs hérités?

Transpilation to ES5, polyfills de plates-formes Web, ES6 + polyfills, préfixage CSS — Les différents couches de compatibilité d'une application Web. ( Agrandir la version )

Le coût de la prise en charge des anciens navigateurs

Essayons de comprendre en quoi différentes étapes d'un pipeline de construction typique peuvent ajouter du poids à nos ressources frontales:

Transpiling To ES5

Pour estimer le poids que le transfert peut générer ajouter à un paquet JavaScript, j'ai pris quelques bibliothèques JavaScript populaires connues à l'origine écrites en ES6 + et comparé leurs tailles de paquet avant et après transpilation:

Bibliothèque	Taille (minifiée ES6)	Taille ( ES5)	Différence
TodoMVC	8,4 KB	11 KB	24,5%
Draggable	77,9 KB	11,5 KB	31.3%
Luxon [19659018] 75.4 KB	100.3 KB	24.8%
Vidéo.js	237.2 KB	335.8 KB	29.4%
PixiJS	370.8 KB	452 KB	19659019] 18%

En moyenne, les liasses non transpilées sont environ 25% plus petites que celles transposées dans ES5. Cela n’est pas surprenant étant donné que ES6 + fournit une manière plus compacte et plus expressive de représenter la logique équivalente et que transpiler certaines de ces fonctionnalités vers ES5 peut nécessiter beaucoup de code.

ES6 + Polyfills

Babel réussit bien. tâche d'appliquer des transformations syntaxiques à notre code ES6 +, fonctionnalités intégrées introduites dans ES6 + – telles que Promise Map et Set ainsi que de nouvelles méthodes de tableau et de chaîne – encore besoin d'être rempli. Si vous déposez un babel-polyfill tel quel, votre paquet minifié peut atteindre près de 90 Ko.

Préfixation CSS

Enfin, examinons l'impact du préfixage CSS. Bien que les préfixes n’ajouteront pas autant de poids mort aux paquets que les autres transformations de build – surtout parce qu’ils compressent bien lorsque Gzip'd -, il reste encore des économies à réaliser ici.

Bibliothèque	Taille ] (minifié, préfixé pour les 5 dernières versions du navigateur)	Taille (minifié, préfixé pour la dernière version du navigateur)	Différence
Bootstrap	159 KB	132 KB	17%
Bulma	184 KB	164 KB	10,9%
Fondation	139 KB	118 KB	15,1%
UI sémantique	622 KB	] 569 KB	8.5%

Un guide pratique pour expédier un code efficace

Cela va sans dire. Si nous exploitons les pipelines de construction existants pour envoyer ces couches de compatibilité uniquement aux navigateurs qui en ont besoin, nous pouvons offrir une expérience plus légère au reste de nos utilisateurs – ceux qui forment une majorité croissante – tout en maintenant la compatibilité avec les anciens navigateurs.

( Voir une version agrandie )

Cette idée n’est pas entièrement nouvelle. Des services tels que Polyfill.io tentent de polyfiller de manière dynamique les environnements de navigateur au moment de l'exécution. Mais les approches telles que celle-ci présentent quelques inconvénients:

Le choix des polyfills est limité à ceux répertoriés par le service – à moins que vous hébergiez et mainteniez le service vous-même.
Parce que le polyfilling a lieu au moment de l'exécution et constitue une opération bloquante. , le temps de chargement des pages peut être considérablement plus long pour les utilisateurs d’anciens navigateurs.
Servir un fichier polyfill personnalisé à chaque utilisateur introduit l’entropie dans le système, ce qui rend le dépannage plus difficile en cas de problème.

ne résolvez pas le problème de poids ajouté par transpilation du code de l'application, qui peut parfois être plus grand que les polyfills eux-mêmes.

Voyons comment nous pouvons résoudre toutes les sources de ballonnement que nous avons identifiées jusqu'à présent. 19659076] Outils dont nous aurons besoin

Webpack
Ce sera notre outil de construction, même si le processus restera similaire à celui d’autres outils de construction, comme Parcel and Rollup.
Browserslist
Avec ça, nous allons mana Définissez les navigateurs que nous souhaitons prendre en charge.
Et nous allons utiliser certains plugins de support Browserslist .

1. Définition des navigateurs modernes et hérités

En premier lieu, nous voudrons préciser ce que nous entendons par navigateurs «modernes» et «hérités». Pour faciliter la maintenance et les tests, il est utile de diviser les navigateurs en deux groupes distincts: en ajoutant des navigateurs ne nécessitant que peu ou pas de polyfilage ou de transpilation dans notre liste moderne, et en plaçant le reste dans notre liste héritée.

Navigateurs prenant en charge ES6 +, nouveaux attributs CSS et API de navigateur telles que Promises et Fetch. ( Agrandir la version )

Une configuration de liste de navigateurs située à la racine de votre projet peut stocker ces informations. Les sous-sections «Environnement» peuvent être utilisées pour documenter les deux groupes de navigateurs, comme suit:

[modern]
 Firefox> = 53
Edge> = 15
Chrome> = 58
iOS> = 10.1

[legacy]
> 1%

La liste donnée ici est seulement un exemple et peut être personnalisée et mise à jour en fonction des exigences de votre site Web et du temps disponible. Cette configuration servira de source de vérité pour les deux ensembles d'ensembles frontaux que nous créerons ensuite: un pour les navigateurs modernes et un pour tous les autres utilisateurs.

2. ES6 + Transpiling et Polyfilling

Pour transpiler notre code JavaScript en respectant l'environnement, nous allons utiliser babel-preset-env .

Initialisons un .babelrc déposer à la racine de notre projet avec ceci:

 {
  "presets": [
    ["env", { "useBuiltIns": "entry"}]
  ]
}

L'activation du drapeau useBuiltIns permet à Babel de polyfiler de manière sélective les fonctions intégrées introduites dans ES6 +. Comme il filtre les polyfills pour n'inclure que ceux requis par l'environnement, nous limitons les coûts d'expédition avec babel-polyfill dans son intégralité.

Pour que ce drapeau fonctionne, nous devons aussi importer babel-polyfill dans notre point d'entrée.

 // In
importer "babel-polyfill";

Ceci remplacera l'importante babel-polyfill par des importations granulaires, filtrées par l'environnement de navigateur que nous ciblons.

 // Sortie transformée.
importer "core-js / modules / es7.string.pad-start";
importer "core-js / modules / es7.string.pad-end";
importer "core-js / modules / web.timers";
…

3. Fonctionnalités de la plate-forme Web Polyfilling

Pour pouvoir envoyer à nos utilisateurs des polyfill pour les fonctionnalités de la plate-forme Web, nous devons créer deux points d'entrée pour les deux environnements:

 require ('whatwg-fetch');
require ('es6-promise'). polyfill ();
//… autres polyfills

Et ceci:

 // polyfills pour les navigateurs modernes (le cas échéant)
require ('observateur d'intersection');

C’est la seule étape de notre processus qui nécessite un certain degré de maintenance manuelle. Nous pouvons rendre ce processus moins sujet aux erreurs en ajoutant eslint-plugin-compat au projet. Ce plugin nous avertit lorsque nous utilisons une fonctionnalité de navigateur qui n’a pas encore été remplie.

4. Préfixe CSS

Enfin, voyons comment on peut réduire les préfixes CSS pour les navigateurs qui n’en ont pas besoin. Puisque autoprefixer a été l'un des premiers outils de l'écosystème à prendre en charge la lecture d'un fichier de configuration de la liste de navigateurs nous n'avons pas grand chose à faire ici.

Création d'une configuration PostCSS simple le fichier à la racine du projet devrait suffire:

 module.exports = {
  plugins: [ require('autoprefixer') ],
}

Rassembler tous les éléments

Maintenant que nous avons défini toutes les configurations de plug-in requises, nous pouvons créer une configuration de WebPack qui les lit et génère deux versions distinctes dans dist / modern et dossiers dist / legacy .

 const MiniCssExtractPlugin = require ('mini-css-extract-plugin')
const isModern = process.env.BROWSERSLIST_ENV === 'moderne'
const buildRoot = path.resolve (__ dirname, "dist")

module.exports = {
  entrée: [
    isModern ? './polyfills.modern.js' : './polyfills.legacy.js',
    "./main.js"
  ],
  sortie: {
    path: path.join (buildRoot, isModern? 'modern': 'legacy'),
    nom de fichier: 'bundle. [hash] .js',
  },
  module: {
    règles: [
      { test: /.jsx?$/, use: "babel-loader" },
      {
        test: /.css$/,
        use: [MiniCssExtractPlugin.loader, 'css-loader', 'postcss-loader']
      }
    ]},
    plugins: {
      nouveau MiniCssExtractPlugin (),
      new HtmlWebpackPlugin ({
      modèle: 'index.hbs',
      nom de fichier: 'index.html',
    }),
  },
};

Pour terminer, nous allons créer quelques commandes de construction dans notre fichier package.json :

 "scripts": {
  "build": "construction du fil: héritage && construction du fil: moderne",
  "build: legacy": "BROWSERSLIST_ENV = hérité webpack -p --config webpack.config.js",
  "build: modern": "BROWSERSLIST_ENV = moderne webpack -p --config webpack.config.js"
}

C’est tout. L'exécution de construction de fil devrait maintenant nous donner deux versions ayant des fonctionnalités équivalentes.

Servir le bon paquet aux utilisateurs

La création de versions séparées nous aide à atteindre uniquement la première moitié de notre objectif. Nous devons toujours identifier et servir le bon ensemble aux utilisateurs.

Vous souvenez-vous de la configuration de la liste de navigation que nous avons définie précédemment? Ne serait-il pas intéressant de pouvoir utiliser la même configuration pour déterminer la catégorie dans laquelle l'utilisateur appartient?

Entrez Browserslist-useragent . Comme son nom l'indique, browserslist-useragent peut lire notre configuration de navigateurslist et faire ensuite correspondre un agent d'utilisateur à l'environnement approprié. L'exemple suivant montre cela avec un serveur Koa:

 const Koa = require ('koa')
const app = new Koa ()
const send = require ('koa-send')
const {matchesUA} = require ('browserslist-useragent')
routeur var = nouveau routeur ()

app.use (router.routes ())

router.get ('/', async (ctx, next) => {
  const useragent = ctx.get ('User-Agent')
  const isModernUser = matchesUA (useragent, {
      env: 'moderne',
      allowHigherVersions: vrai,
   })
   const index = isModernUser? 'dist / modern / index.html', 'dist / legacy / index.html'
   attendre l'envoi (ctx, index);
});

Ici, la définition de l'indicateur allowHigherVersions garantit que, si les versions les plus récentes d'un navigateur sont publiées – celles qui ne font pas encore partie de la base de données de Can I Use – elles seront toujours considérées comme véridiques pour les navigateurs modernes. 19659005] Une des fonctions de browserslist-useragent est de garantir que les caprices de la plate-forme sont pris en compte lors de la mise en correspondance des agents d'utilisateur. Par exemple, tous les navigateurs sur iOS (y compris Chrome) utilisent WebKit en tant que moteur sous-jacent et seront associés à la requête Browserslist spécifique à Safari.

Il n'est peut-être pas prudent de se fier uniquement à l'analyse correcte des agents utilisateur dans l'agent. production. En retombant dans le bundle existant pour les navigateurs qui ne sont pas définis dans la liste moderne ou qui ont des chaînes d’agent utilisateur inconnues ou imparables, nous nous assurons que notre site Web fonctionne toujours.

Conclusion: en vaut-il la peine?

Nous avons réussi à couvrir un flux de bout en bout pour expédier des offres groupées gratuites à nos clients. Mais il n’est que raisonnable de se demander si les frais de maintenance que cela ajoute à un projet en valent la peine. Examinons les avantages et les inconvénients de cette approche:

1. Maintenance et tests

Il est nécessaire de ne gérer qu'une seule configuration de liste de navigateurs permettant d'alimenter tous les outils de ce pipeline. La mise à jour des définitions des navigateurs modernes et hérités peut être effectuée à tout moment dans l'avenir sans avoir à refactoriser les configurations ou le code. Je dirais que cela rend les frais généraux de maintenance presque négligeables.

Il existe toutefois un petit risque théorique associé à la dépendance de Babel pour produire deux ensembles de codes différents, dont chacun doit fonctionner correctement dans son environnement respectif. 19659005] Bien que les erreurs dues aux différences entre les ensembles puissent être rares, la surveillance de ces variantes pour en détecter les erreurs devrait aider à identifier et à atténuer efficacement tous les problèmes.

2. Temps de construction et durée d'exécution

À la différence des techniques actuelles, toutes ces optimisations se produisent au moment de la construction et sont invisibles pour le client.

3. Vitesse progressivement améliorée

L'expérience des utilisateurs des navigateurs modernes devient considérablement plus rapide, tandis que les utilisateurs des navigateurs existants continuent à recevoir le même paquet qu'auparavant, sans aucune conséquence négative.

4. Utilisation simplifiée des fonctionnalités de navigateur modernes

Nous évitons souvent l’utilisation de nouvelles fonctionnalités de navigateur, en raison de la taille des polyfills nécessaires à leur utilisation. Parfois, nous choisissons même des polyfill plus petits non conformes aux spécifications pour économiser de la taille. Cette nouvelle approche nous permet d’utiliser des polyfills conformes aux spécifications sans trop nous inquiéter pour tous les utilisateurs.

Bundle différentiel mis en production

Compte tenu des avantages considérables que nous avons offerts, nous avons adopté ce pipeline de construction lors de la création d’une nouvelle expérience de paiement mobile pour les clients de Urban Ladder, l'un des plus importants détaillants de mobilier et de décoration en Inde.

Dans notre offre déjà optimisée, nous avons réussi à réaliser des économies d'environ 20% sur les ressources CSS et JavaScript de Gzip'd envoyées aux utilisateurs mobiles modernes. Étant donné que plus de 80% de nos visiteurs quotidiens se trouvaient sur ces navigateurs à feuillage persistant, les efforts déployés en valaient la peine.

Ressources supplémentaires

(dm, ra, yk, il, al) [19659140]

Source link

Blog ARC Optimizer