Nouvelle pensée sur mobile d'abord

Avec l'avènement du Web responsive et de l'approche mobile first, sept années merveilleuses se sont écoulées depuis que de nouveaux concepts nous ont obligés à adapter la manière dont nous écrivons CSS à la base. niveau. Eh bien, je n’ai rien de trop révolutionnaire à vous offrir, mais j’ai une petite surprise. Voici: Premier CSS générique.

Je pense qu’il est prudent de dire que le Responsive Web Design d’Ethan Marcotte a été une révélation bienvenue pour les développeurs Web du monde entier. Cela a déclenché une nouvelle vague de réflexions sur le design et de merveilleuses nouvelles techniques frontales. Le règne des sites Web souvent méprisés était également terminé. À la même époque et presque aussi influent que la méthode Mobile First de Luke Wroblewski – une amélioration solide qui s'appuie sur les bases impressionnantes de Marcotte.

Ces techniques sont à la base de la plupart des développeurs Web, et ils ont su nous a bien servi, mais hélas, les temps changent et les développeurs répètent constamment. À mesure que nous augmentons l'efficacité de nos méthodes et que les exigences du projet deviennent plus complexes, de nouvelles frustrations se font jour.

The Journey To Generic First

Je ne parviens pas à identifier avec précision ce qui m'a amené à changer la façon dont j'écris mon CSS, vraiment une progression naturelle pour moi qui s'est passé presque inconsciemment. En y repensant, je pense que c’était plutôt un sous-produit de l’environnement de développement dans lequel je travaillais. L’équipe avec laquelle j’ai travaillé a eu un bon flux de travail SCSS avec un petit mix astucieux permettant d’ajouter facilement des points de rupture dans nos déclarations CSS. Vous utilisez probablement une technique similaire.

Ce merveilleux petit mix SCSS a soudainement facilité l'écriture de requêtes sur des supports extrêmement granulaires. Prenons un bloc de biographie hypothétique qui ressemble un peu à ceci:

 .bio {
  bloc de visualisation;
  largeur: 100%;
  couleur de fond: # ece9e9;
  rembourrage: 20px;
  marge: 20px 0;

  @include media ('> = small') {
    largeur maximale: 400px;
    couleur de fond: blanc;
    marge: auto 20px;
  }

  @include media ('> = medium') {
    largeur maximale: 600px;
    rembourrage: 30px;
    marge: auto 30px;
  }

  @include media ('> = large') {
    largeur maximale: 800px;
    rembourrage: 40px;
    marge: auto 40px;
  }

  @include media ('> énorme') {
    largeur maximale: 1000px;
    rembourrage: 50px;
    marge: auto 50px;
  }
}

Fig.1. Une première mobile typique avec des requêtes de médias en cascade

Cela fonctionne très bien – j’ai beaucoup de CSS comme cela dans le passé. Cependant, un jour, il m’a semblé que réécrire les déclarations CSS lorsque la largeur du périphérique augmentait n’avait aucun sens. Pourquoi déclarer une propriété CSS uniquement pour qu'elle soit écrasée dans la déclaration suivante?

C'est ce qui m'a amené à commencer à écrire des requêtes multimédias compartimentées contrairement à l'approche plus courante des requêtes de média qui cascadent vers le haut (ou vers le bas) comme dans l'exemple de la figure 1.

Au lieu d'écrire des requêtes de média qui cascadent avec une augmentation de la taille de l'écran, j'ai commencé à créer des requêtes de média ciblées qui Encapsulez les styles à la largeur d'écran souhaitée. Le média interrogation mixin prendrait tout son sens ici. Mes requêtes de support SCSS commencent à ressembler à ceci:

 .bio {
  bloc de visualisation;
  largeur: 100%;
  rembourrage: 20px;
  marge: 20px 0;

  @include media ('> = petit', ' moyen') {
    largeur maximale: 400px;
    marge: auto 20px;
  }

  @include media ('> = medium', ' large') {
    largeur maximale: 600px;
    rembourrage: 30px;
    marge: auto 30px;
  }

  @include media ('> = large', ' énorme') {
    largeur maximale: 800px;
    rembourrage: 40px;
    marge: auto 40px;
  }

  @include media ('> énorme') {
    largeur maximale: 1000px;
    rembourrage: 50px;
    marge: auto 50px;
  }
}
   

Fig.2. Un exemple d'interrogation de média compartimenté

Cette nouvelle approche me paraissait plus intuitive, elle évitait de devoir réinitialiser les styles le point d'arrêt précédent, et cela rendait le CSS plus facile à lire. Plus important encore, cela rendait les requêtes des médias auto-documentées de manière plus significative.

Je n'étais toujours pas satisfait à 100% de ce qui précède, mais il me semblait qu'il restait encore un problème majeur à surmonter.

Problème avec Mobile First

Le problème avec mobile first est que, par définition, vous devrez probablement remplacer les styles Mobile First dans les requêtes multimédia suivantes.

Donc, pour moi, la réponse était évidente: prenons l'idée du compartimentage des requêtes dans les médias jusqu'à sa conclusion logique: nous allons également compartimenter les styles spécifiques aux mobiles dans leurs propres médias. requêtes. Je sais, je sais, cela va à l’encontre de la convention commune que nous avons apprise au fil des ans. «Mobile First» est si omniprésent que c’est l’une des questions de «compétences» que posera un responsable du recrutement. Donc, toute alternative doit être fausse, n'est-ce pas? C’est généralement la partie où les gens me secouent la tête en prononçant encore et encore mobile .

Très bien, nous allons donc briser le dogme du premier mobile et compartimenter tous nos styles dans le questions médiatiques pertinentes. Il ne nous reste maintenant que des styles génériques purs déclarés sur un sélecteur CSS, tous les autres styles spécifiques à un périphérique étant encapsulés dans des requêtes multimédias ne s’appliquant qu’aux dimensions de l’écran correspondantes. Nous avons maintenant Generic First CSS :

 .bio {
  bloc de visualisation;
  largeur: 100%;

  @include media ('> = 0', ' small') {
    rembourrage: 20px;
    marge: 20px 0;
  }

  @include media ('> = petit', ' moyen') {
    largeur maximale: 400px;
    marge: auto 20px;
  }

  @include media ('> = medium', ' large') {
    largeur maximale: 600px;
    rembourrage: 30px;
    marge: auto 30px;
  }

  @include media ('> = large', ' énorme') {
    largeur maximale: 800px;
    rembourrage: 40px;
    marge: auto 40px;
  }

  @include media ('> énorme') {
    largeur maximale: 1000px;
    rembourrage: 50px;
    marge: auto 50px;
  }
}
    

Fig.3. Un exemple du premier CSS générique

Oui, il y a un peu plus de requêtes de médias, mais je le vois comme un Tout développeur peut désormais consulter ce code CSS et voir exactement quels styles sont appliqués à chaque taille d'écran sans la surcharge cognitive de devoir distinguer la spécificité de la requête multimédia.

Cela peut être très utile pour les personnes qui ne connaissent pas le code.

Quand ne pas compartimenter

Il arrive encore que le compartimentage des requêtes multimédias soit un fardeau et que, dans certains cas, une bonne requête> =, tout va bien. N'oubliez pas que tout ce que nous essayons de faire est d'éviter les écrasements de propriété.

Dev Tool Bliss

L'une des conséquences non voulues majeures de l'écriture générique compartimentée First CSS est l'expérience que vous obtiendrez de votre panneau de style des outils de développement. Sans la cascade de requêtes multimédias, vous obtiendrez une vue d'ensemble plus claire des styles appliqués. Vous ne disposerez pas d'un panneau de styles plein de déclarations rayées de règles de requête multimédia écrasées – Le bruit a disparu! Ceci – pour moi – est l’un des plus grands avantages de la technique générique First CSS. Cela apporte un peu plus de sécurité à l'expérience de débogage CSS, et cela vaut son pesant d'or. Merci plus tard.

Répercussions sur les performances

Ainsi, tous ces avantages de Generic First CSS commencent à sembler plutôt bons, mais je pense qu’il ya une dernière question clé qui, à mon avis, doit être abordée. C’est le sujet de l’optimisation des performances. À présent, je ne le sais pas encore avec certitude, mais j’ai bien l’impression que les requêtes multimédia entièrement compartimentées peuvent présenter un léger avantage en termes de performances.

Les navigateurs effectuent une tâche de rendu appelée calcul de style calculé . C’est la façon dont les navigateurs calculent les styles qui doivent être appliqués à un élément à un moment donné. Cette tâche est toujours effectuée lors du chargement initial de la page, mais elle peut également l'être si le contenu de la page est modifié ou si d'autres actions du navigateur sont effectuées. Toute accélération que vous pouvez donner à la vitesse du processus va être géniale pour le chargement initial de page, et cela pourrait avoir un effet composé sur le cycle de vie des pages de vos sites Web.

Donc, revenons au premier générique CSS: Existe-t-il des Des problèmes de performances liés à la nécessité pour le navigateur de déterminer la spécificité CSS d'une multitude de requêtes multimédia en cascade?

Pour répondre à cette question, j'ai conçu un scénario de test qui peut être utilisé pour mesurer les avantages en termes de vitesse, voire les inconvénients. ] Le scénario de test

Le scénario de test comprend une page HTML de base contenant un bloc "bio" 5000 fois, le balisage est identique pour chaque bloc, mais les classes sont légèrement différentes (différenciateur numérique), le CSS pour ce bloc est également émis 5000 fois, les noms de classe étant la seule chose à différer. Le fichier CSS généré est acheminé via un outil appelé CSS MQPacker ce qui permet de réduire considérablement la taille de fichier des fichiers CSS utilisant de nombreuses requêtes multimédia en ligne en combinant toutes les instances séparées d'une requête multimédia spécifique en une seule. excellent outil qui profitera probablement aux bases de code CSS les plus modernes – je l'ai utilisé comme outil cli autonome via une tâche npm dans le package de projets test.json, vous pouvez également l'utiliser comme plug-in postcss, ce qui est agréable et pratique! [19659005] Le premier cas de test est un exemple de requête de média en cascade pour les premiers mobiles, le deuxième cas de test est une première variante générique compartimentée de la CSS. La CSS pour ces cas est un peu verbeuse et pourrait probablement être écrite en termes beaucoup plus concis, mais elle ne sert en réalité qu’à titre d’exemple approximatif pour tester l’argument.

Le test a été exécuté 20 fois pour chaque variante de CSS dans le bureau Google. Chrome v70, pas un ensemble volumineux de données, mais assez pour me donner une idée approximative d'un gain / perte de performance.

Les métriques de test que j'ai choisi d'utiliser sont les suivantes:

• Temps de chargement global de la page
  mesure permettant de vérifier le temps de chargement d'une page à l'aide des marqueurs de l'API de performance au début et à la fin de
• Le style de recalculer
  Temps écoulé depuis le volet de performance des outils de développement.
• Le rendu de page global
• . 19659047] Temps dans le volet de performance des outils de développement.




Tableau des résultats (toutes les heures en millisecondes)

	Mobile First				Generic First
	Durée de chargement	Calculez les styles	Durée totale du rendu		Durée de charge	Calculez les styles	Durée totale du rendu
	1135	565.7	1953		1196	536.9	2012
	1176	563.5	1936		1116	506.9	1929
	1118	563.1	1863		1148	514.4	1853
	1174	568.3	1929		1124	507.1	1868	. 19659063] 1204	577.2	1924		1115	518.4	1854	1155	554.7	1991		1177	540.8	de 1905	1112	554.5	1912		1111	504.3	1886
	1110	557.9	1854		1104	505.3	1954
	1106	19659058] 544.5	1895		1148	525.4	1881
	1162	559.8	1920		1095	508.9	1941
	1146	545.9	1897		1115	504.4	] 1968
	1168	566.3	1882		1112	519.8	1861
	1105	542.7	1978		1121	515.7	1905
	1123	566.6	1970		1090	510.7	1820
	1106	514.5	1956		1127	515.2	de 1986 à 1965
	] 1135	575.7	1869		1130	504.2	1882
	1164	545.6	2450		1169	525.6	1934
	1134	565	1894		1092	516	1822
	1115	554.5	1955		1091	508.9	1986	1133	] 554.8	2572		1001	504.5	1812
AVG	1 139.55	557.04	1980									1903.15

Mobile First
Temps de chargement	Calculez les styles	Durée totale du rendu
1135	565.7	1953
1118	563.1	1863
.	568.3	1929
1112	554.5	1912
1105	542.7	1978
1106	514.5	1956
] 545.6	2450
1115	554.5	1955

Generic First
Durée de chargement	Calculez les styles	Temps de rendu total
1196	536.9	2012
1148	514.4	1853
1124	507.1	1868
1111	504.3	1886
1121	515.7	. 19659222] 1127	515.2	1986
1169	525.6	1934
1091	508.9	1986

Fig.6. 20 cycles de mesure mesurant la métrique charge / rendu des clés du premier sous-mobile par rapport au premier CSS générique.

D'après mon petit ensemble de données, il me semble que mes premiers soupçons pourraient être fondés. En moyenne, la tâche de recalcul de style prend 42 ms moins de temps, ce qui représente une augmentation de 7,6% de la vitesse. Par conséquent, le temps de rendu global diminue également. La différence n’est pas stupéfiante, mais c’est une amélioration. Je ne pense pas que l'ensemble de données soit suffisamment volumineux pour être concluant à 100% et le scénario de test est un peu irréaliste, mais je suis très heureux de ne pas voir une dégradation des performances.

Je serais très intéressé de voir le générique. première méthodologie appliquée à une base de code existante du monde réel qui a été écrite de la façon suivante: les métriques avant après seraient beaucoup plus réalistes pour la pratique quotidienne.

Et si quelqu'un a des suggestions sur la manière d'automatiser ce test sur un ensemble plus large d'itérations, s'il vous plaît laissez-moi savoir dans les commentaires! J'imagine qu'il doit exister un outil capable de le faire.

Conclusion

Pour récapituler les avantages de cette nouvelle méthode de développement …

• CSS qui fonctionne exactement comme prévu, sans hésitation; [19659254] Requêtes médiatiques auto-documentées;
• Une meilleure expérience des outils de développement;
• Pages dont le rendu est plus rapide.

Je voudrais bien penser que je ne suis pas le seul à épouser l’écriture de CSS dans ce style. Si vous avez déjà adopté le premier état d'esprit générique, bravo! Mais sinon, je pense que vous allez vraiment aimer les avantages que cela apporte. Personnellement, j’ai beaucoup profité de l’expérience des outils de développement sans encombre, ce qui, en soi, sera très bénéfique pour de nombreux développeurs. la nature auto-documentée de cette façon d’écrire vos questions concernant les médias aura également des avantages pour vous-même et pour l’ensemble de l’équipe (si vous en avez une). Enfin, ces avantages ne vous coûteront rien en termes de performances, et il a en fait été démontré que les gains de vitesse étaient marginaux!

Final Word

Comme toutes les méthodologies de développement, ce n'est peut-être pas pour tout le monde, mais je ' Bien que je sois tombé dans le premier CSS générique tout naturellement, je le considère maintenant comme une méthode de travail intéressante qui me donne tous les avantages du mobile d’abord avec de nouveaux ajouts positifs qui facilitent grandement le travail difficile du développement frontal. [19659006] Ressources

Rapport de test

Si vous souhaitez lancer le test et le tenter vous-même, vous pouvez le le trouver sur GitHub j'aimerais voir des rapports d’autres

Outils

(dm, ra, yk, il)
Le meilleur outil 2023 pour ta croissance Instagram !




Source link