Fournir un travail de site rapide dans le cadre du pipeline de développement

Les performances d'un site Web ne consistent pas uniquement à accélérer le chargement des pages Web. Il est également nécessaire de transmettre l'importance des ressources Web efficaces aux développeurs et aux autres participants au projet. La performance est la même partie de la fonctionnalité que tout le reste, donc sa mise en œuvre ne peut pas être différée «un jour».



Le sujet de la performance m'intéresse depuis longtemps. Je me souviens que tout a commencé avec la connaissance des algorithmes «gourmands» et «diviser pour mieux régner». Il y avait quelque chose de particulièrement agréable à prendre le code qui prenait plusieurs minutes, à le refaire et à le faire terminer la tâche en quelques secondes.

Si nous parlons de réseaux, les problèmes de performances sont différents: il ne s'agit généralement pas de complexité de calcul, mais d'effectuer au mieux les actions nécessaires au bon moment. À première vue, cette tâche peut sembler élémentaire, mais en fait elle est beaucoup plus compliquée.

Traduit en Alconost

Steve Suders a été l' un des premiers à s'intéresser à l'analyse de la façon dont les navigateurs demandent des ressources Web et attendent une réponse: quelles ressources bloquent le travail, lesquelles peuvent être différées, que se passe-t-il avec les en-têtes de réponse? Sur la base des résultats de ses recherches, il a dressé une liste de 14 règles pour charger rapidement un site Web . Par exemple, voici les règles de performance qui s'appliquent dans l'outil YSlow (vous le connaissez peut-être déjà) .


14 Règles de Steve Suders ( source )

Aujourd'hui, il existe de plus en plus de nouveaux outils pour contrôler la productivité: certains doivent être lancés séparément, tandis que d'autres sont intégrés au pipeline de développement et de déploiement. L'un d'eux est le phare de Google: il affiche des données sur les indicateurs PWA (applications Web progressives), le référencement, etc.


Capture d'écran de Lighthouse 3.0 présentée lors de la conférence Google I / O 2018 ( source )

Ces outils aident à déterminer à quoi prêter une attention particulière lors de la finalisation du site, et en même temps, ils ont mis en œuvre de nombreux concepts, parmi lesquels il n'est pas si facile à comprendre: PRPL, RAIL, Paint Timing API, TTI, HTTP / 2, Indice de vitesse, indices de priorité et plus ...

Pourquoi la performance est dans les coulisses

La question de la réactivité des sites Web est un problème grave dans diverses entreprises. Nous avons d'excellents outils et des guides clairs, mais peu de gens consacrent du temps à l'amélioration de la productivité. Autrement dit, le fait n'est pas que nous ne savons pas pourquoi les sites se chargent depuis si longtemps.

Par conséquent, je n'essaie pas d'expliquer pourquoi les performances du site Web sont importantes.

D'autres ressources en parlent beaucoup mieux, avec des chiffres réels pour de vrais projets. Je veux parler de la culture du développement et de la façon dont elle définit les priorités . Ne percevant la productivité que comme une autre «fonction» du projet, nous apprenons à y prêter attention.

Si vous lisez ceci, alors vous êtes probablement un développeur, vous essayez de vous tenir au courant des nouvelles technologies Internet et vous n'êtes pas indifférent à la productivité. Si vous demandez où vous travaillez et ce que vous faites, il se peut que vous apparteniez au service de développement d'une entreprise et l'une de vos tâches consiste à assurer la productivité. Mais très probablement, on ne peut pas en dire autant du reste des employés du département et de l'entreprise dans son ensemble - à moins, bien sûr, que vous travailliez de manière indépendante. Et c'est normal: il est impossible de tout savoir sur tout.

Lors de la résolution de tâches quotidiennes, vous devez travailler dans de nombreux domaines techniques: développer de nouvelles fonctions, interagir avec d'autres services (ajouter des scripts pour l'analyse, la publicité, le remarketing, les tests A / B), organiser l'intégration et la livraison continues (CI / CD), assurer la sécurité, créer une interface agréable et facile à utiliser. Mais vous devez toujours couvrir l'arrière avec des tests!

Il est souvent presque impossible de prêter attention à autre chose: le temps est limité et le volume de travail exceptionnel a tendance à augmenter. Par conséquent, vous devez établir des priorités.



La priorisation doit être objectivement basée sur une hypothèse mesurable. Par exemple: «Nous pensons qu'avec l'implémentation de la fonction X, la rétention des utilisateurs augmentera de Y%», cependant, en pratique, cela semble beaucoup plus compliqué. Jetez un œil aux tâches que nous devons gérer et faites attention à qui les définit:

• Implémentation de fonctions . En règle générale, les nouvelles tâches sont définies par le propriétaire ou le chef de produit, en fonction de sa vision et de l'objectif de l'équipe. Une demande de fonction peut provenir de ceux qui dépendent de notre travail (par exemple, ajouter un script tiers pour le suivi ou les tests A / B ).
  
• Organisation CI / CD . Les développeurs peuvent créer leurs propres pipelines pour l'assemblage et le déploiement, mais ils utiliseront très probablement l'infrastructure préparée par d'autres (par exemple, le service des infrastructures).
  
• La sécurité . C'est formidable si le projet dispose d'un département (ou au moins une personne) spécialisé en sécurité, qui aide à vérifier la structure du système, la mise en œuvre des fonctions, nous envoie des rapports de sécurité et informe des corrections.
  
• Interface utilisateur En règle générale, un projet a un concepteur et / ou un spécialiste de l'interaction avec l'utilisateur qui est responsable de l'apparence, de la convivialité et de l'architecture de l'information.
  
• Test . Où en sommes-nous sans tests, non?
  

Si quelqu'un est responsable d'une tâche, celle-ci se trouvera très probablement sur le tableau des tâches. La plupart des tâches sont en corrélation avec certains rôles du flux de travail, mais il y a aussi ceux qui sont tacitement assignés aux développeurs - par exemple, les tests: le département de développement dans son ensemble en est responsable, et donc certains composants sont finalement testés mieux que d'autres.

Personne ne dira peut-être que les tests automatiques sont utiles. Habituellement, le département de développement décide lui-même de l'étendue du code couvert par les tests - il est important que tous les développeurs de l'équipe puissent écrire des tests. Une situation similaire concerne les problèmes de performances: il est généralement supposé que les développeurs devraient y faire face. J'ai remarqué qu'il est plus facile d'écrire des tests pour le code et de comprendre les conséquences qui conduiront au mauvais fonctionnement d'un fragment que de prendre en compte tous les éléments qui peuvent ralentir la ressource Web .

Six étapes pour mettre en œuvre l'importance des performances des ressources Web

Nous avons des outils pour analyser les performances, mais leur utilisation dépend des développeurs eux-mêmes. Comment introduire dans l'entreprise l'idée que la productivité doit être perçue comme l'une des fonctions?

J'ai compilé une liste en six points qui devrait aider à cet égard.

1. Environnement de développement environment environnement utilisateur

Travail facile , tourné par Emil Perron

Pour le développement de sites Web, j'utilise un MacBook Pro. J'ai un iPhone X comme téléphone et j'ai un appareil de test séparé. De plus, j'ai une connexion Internet très rapide et je suis assis près des centres de données de Stockholm et de Londres. Après le travail, je vais dans le métro, où il y a la 4G (et pas de lacunes). D'une manière générale, c'est à Stockholm que la 4G est apparue pour la première fois - en 2009 .

Les utilisateurs auront à peine des conditions aussi élégantes (à de rares exceptions près).

Si nous n'avons nous-mêmes aucun problème de performances - comment hiérarchiser la tâche d'optimisation? C'est comme essayer d'implémenter une interface pour les personnes handicapées sans utiliser les commandes du clavier, les lecteurs d'écran et vérifier les couleurs contrastées - c'est-à-dire un mauvais travail.

Et vous n'avez pas à attendre les changements ici: les développeurs Web occidentaux aiment choisir la dernière version parmi les ordinateurs portables et autres appareils. La même chose peut être dite de presque tous ceux qui sont chargés de fixer les objectifs du projet et de l'entreprise. De plus, dans certains cas, nous nous concentrons sur le segment supérieur des appareils, car ils sont utilisés par ceux qui sont plus susceptibles d'être prêts à payer pour notre produit. Bruce Lawson a déclaré à ce sujet que nous devrions construire un "réseau mondial, pas un réseau pour les riches occidentaux".

Pensez à quoi de mieux: attirer plus d'utilisateurs, même s'ils sont moins solvants , ou moins, mais plus solvants?

Fait intéressant, ne prenant pas en compte le travail des utilisateurs sur des appareils réels, nous finissons par faire de fausses hypothèses . Supposons que nous décidions de faciliter le développement et d'abandonner les plates-formes sur lesquelles statistiquement moins d'utilisateurs ou une utilisation plus faible (par exemple, moins de pages vues par session). Cela n'a aucun sens de prendre en charge un ancien navigateur qui n'est presque jamais utilisé par quiconque . Et on pourrait dire que cette décision est basée sur des données solides.

Mais ne nous précipitons pas. Mais que se passe-t-il si les faibles performances sur une plate-forme sont la conséquence du fait que notre produit est gênant ou inefficace? Cette hypothèse est difficile à prouver, car les développeurs diront que tout va bien avec eux - sur leurs ordinateurs et dans un navigateur spécifique (supposons que ce soit Google Chrome). Nous accordons involontairement plus d'attention au navigateur que nous utilisons et, par conséquent, nous faisons souvent des compromis en faveur d'un environnement de travail plus moderne. Oh, j'entends un cri de douleur de l'autre côté du moniteur: «Vous utilisez toujours ce navigateur? Qu'ils soient mis à jour! "

Je suis récemment tombé sur une citation qui m'a beaucoup plu:

«Lorsque j'ai travaillé chez Google, quelqu'un m'a raconté comment il avait réalisé une excellente optimisation, et il s'est avéré que le temps de chargement des pages ne faisait qu'augmenter. Après avoir fouillé dans les données, nous avons découvert une raison: après l'optimisation, beaucoup plus de trafic a commencé à venir d'Afrique. Auparavant, il était impossible d'utiliser le produit avec un Internet lent, et après l'optimisation, cela est devenu possible, et un grand nombre d'utilisateurs avec une connexion faible est apparu, ce qui a augmenté le temps de téléchargement moyen. »
- Dan Lu, "Internet gonflé"

Je le répète: simuler la croissance de la productivité en excluant les utilisateurs qui donnent de mauvaises performances et gâchent les statistiques est facile. Mais ce n'est pas de l'optimisation, mais juste un jeu avec des chiffres .

Prenez-le vous-même et distribuez à vos collègues travaillant sur le projet, les anciens appareils. Simulez les mauvaises conditions de connexion, les processeurs lents - et adaptez votre produit à cela. Découvrez quels appareils les utilisateurs ont, et en donnant la priorité aux appareils qui accèdent réellement à votre site, soyez particulièrement vigilant.

2. Il vaut mieux apprendre les bases de la technologie plutôt que des bibliothèques spécifiques

Jusqu'à présent, de nombreuses exigences d'emploi et questions d'entrevue d'emploi se sont concentrées sur les bibliothèques plutôt que sur les technologies sous-jacentes. Bien qu'il serait plus correct de demander: «Que se passe-t-il lorsqu'un navigateur essaie de charger un site Web? Pour quelles raisons un site peut-il se charger trop longtemps? Comment organiseriez-vous l'architecture d'un projet web de taille non triviale (client, serveur, bases de données, mise en cache)? »

Un développeur qui connaît les réponses à ces questions choisira judicieusement les bibliothèques npm pour le projet. Discutant de la fonctionnalité avec les designers et le client, il sera en mesure d'exprimer un regard particulier sur le développement. Un tel développeur prendra en compte les API des navigateurs nouveaux et anciens et tentera de profiter de la plate-forme "peu pratique", plutôt que de l'isoler.

Par conséquent, le ministère devra peut-être embaucher un spécialiste qui connaît React ou Vue, et l'inclure immédiatement dans le travail et faire avancer le projet. Et en même temps, il serait bon que les nouveaux employés restent plus longtemps dans l'entreprise, remettent en question les solutions techniques existantes et offrent de meilleures options.

Il y a deux constantes qui ne changent pas, où que j'applique mes compétences en tant que développeur:

1. Il est nécessaire de remettre en question les décisions de sa propre entreprise, sinon un concurrent le fera - et se manifestera. Stimulez les commentaires des participants au projet et donnez-leur le temps de développer des prototypes innovants et des versions pilotes.
   
2. Les solutions techniques adoptées aujourd'hui ne dureront pas longtemps. S'appuyer sur la modularité, une possibilité de retrait des composants et une livraison rapide.
   

Si vous êtes d'accord avec ce qui précède, vous êtes ouvert aux idées de personnes qui ne sont pas engagées dans une technologie particulière et pouvez justifier les avantages et les inconvénients de diverses solutions techniques.

Participez aux entretiens. Proposez de réserver du temps pendant lequel les employés peuvent apprendre quelque chose (par exemple, vous pouvez régulièrement faire de petites présentations pendant le déjeuner) et explorer des idées qui peuvent bénéficier aux projets.

3. Trouvez du temps pour l'expérimentation et les tests.

Auparavant, j'avais envoyé à mes collègues des liens vers des discours lors de conférences comme Google I / O et des articles racontant toutes sortes de nouvelles choses. Il me semblait être au courant des derniers événements pour moi et pour eux.

Partageant sans réfléchir des liens intéressants vers vous, vous ne chargez souvent plus vos collègues: ils doivent non seulement faire leur travail, mais aussi lire ce que vous avez envoyé. Il est supposé que l'apprentissage est meilleur dans la pratique, de sorte qu'ils semblent devoir essayer d'appliquer cette nouvelle bibliothèque, technique, idée, etc.

Rendez-leur service - appliquez vous-même la nouveauté du projet. «La nouvelle API du navigateur a l'air cool» - la mauvaise approche de l'évaluation. Il vaut mieux argumenter comme ceci: "Si vous utilisez X comme ça, notre projet deviendra meilleur ." La seconde, bien sûr, est plus difficile, mais le retour dans ce cas est plus élevé - et il sera beaucoup plus facile de convaincre le patron.

Il existe de nombreuses études de cas sur le réseau sur la façon dont l'optimisation des performances améliore les mesures clés. Une bonne source d'articles à ce sujet - par exemple, comme WPO Stats .


De nombreuses études de cas dans lesquelles l'augmentation de la productivité a conduit à l'amélioration des principaux indicateurs de performance.

Parfois, pour inciter une entreprise à accorder plus d’attention à la vitesse d’un projet Web, la simple recherche pratique d’une personne ne suffit pas comme preuve.

Besoin d'un prototype. Mais il peut sembler qu'il n'y a pas de temps et qu'il n'y en aura jamais pour sa création: tout est dépensé pour corriger les erreurs et ajouter de nouvelles fonctions.

À mon avis, chaque fonction doit passer par trois étapes:



L'idée peut venir du propriétaire ou du gestionnaire du produit, mais elle peut aussi venir du développeur . Il est nécessaire de le tester et de montrer qu'il fonctionne - pour cela, nous avons besoin d'un prototype. Ce n'est qu'après que la fonction sera réalisée. En outre, cela signifie qu'avant la mise en œuvre de l'idée doit être testée sous une forme ou une autre. Il sera nécessaire de prouver que l'amélioration des performances du site améliore les performances - mais il en va de même pour les autres fonctions.

Lorsque vous recherchez ce qui peut être accéléré, choisissez ce que les utilisateurs peuvent ressentir. Afin que les utilisateurs puissent remarquer la différence dans un délai acceptable, la vitesse du site devrait augmenter d'au moins 20% , et mieux - de 30% .

4. Former des collègues

Vous est-il déjà arrivé de devoir supprimer ou remplacer un morceau de code parce que personne ne comprenait comment cela fonctionnait? Peut-être que ce bol n'a dépassé personne. Si le code n'est compris et soutenu que par son auteur, que se passera-t-il si cette personne part en vacances, tombe malade, quitte l'entreprise? ..


Nous profitons de l'absence de John - nous nous débarrassons de la complexité inutile.

La plupart d'entre nous travaillent en équipe, donc lors du choix des solutions, vous devez vous concentrer sur celles qui seront comprises par la plupart des collègues. Définissez le «plus petit multiple commun» dans l'équipe et essayez de ne pas utiliser de solutions trop compliquées simplement parce que c'est amusant de jouer avec . Dans l'optimisation des performances, un petit gain est parfois obtenu par une augmentation excessive de la complexité.

Il y a quelques mois, j'ai écrit sur l'optimisation d'image et comment améliorer la vitesse de téléchargement apparente . J'ai commencé par l'évidence: moins de requêtes, choisissez le bon format, optimisez les images. Cependant, la plupart se souviennent uniquement de l'utilisation d'images d'espace réservé, qui vous permettent de faire une transition en douceur vers l'image souhaitée.


Options pour ce que vous pouvez afficher avant de télécharger une image.

C'est la partie la plus intéressante et innovante! Vraiment? Essayez maintenant de dire à vos collègues que vous allez créer un service backend qui traitera les images en file d'attente et stockera une petite esquisse qui sera incorporée dans la page lors du rendu. Quand va-t-il se déclencher? Combien de temps cela prendra-t-il? Où stocker les croquis? Comment faire évoluer ce service sur différents serveurs?

Il est plus efficace d'éviter la livraison d'images et d'optimiser celles qui doivent encore être livrées - c'est ce que vous devez viser.

En plus de choisir des solutions «suffisamment bonnes» qui sont compréhensibles par la plupart des collègues, vous devriez penser à élever le niveau de connaissances dans le département . Êtes-vous considéré comme un quai dans une zone spécifique? Faites une présentation à vos collègues et inspirez-leur d'une nouvelle idée.

Après tout, si seulement vous faites la promotion d'une certaine idée, elle ne durera pas longtemps.

5. Partagez les réussites (et les échecs)

Pour changer la façon de penser dans l'entreprise, vous devrez d'abord convaincre vos propres collègues de la nouvelle approche. Mais vous devez partager les résultats de vos expériences en dehors de votre département.

À l'échelle de l'entreprise, cela contribuera à inspirer d'autres employés et à ouvrir la voie à des entreprises plus ambitieuses . Et il sera plus facile d'obtenir une assistance pour les bons services et infrastructures si plusieurs départements le jugent nécessaire.

- , .

-, Etsy. :

« « », , : , , , ».
— , « »

.

, , , .


Etsy

, , . Vox Media — , The Verge . 2015 . Vox Media , .

« . — . ».
— Vox Media, « » ( )

SpeedCurve , The Verge Vox Media ( )

Vox Media ( , ) , .


Vox Media .

: ( ), . , , .

6.

— ́ , -.

, : WebPagetest , Pagespeed Insights , Audits Chrome . .


WebPagetest — .

, , , .

, , . — .

— . . , ( , , . .).

RUM-, . , , , - , .

, , — Google Analytics , — : , Calibre , SpeedCurve SiteSpeed .

, .

— . (, SiteSpeed) , . , .

- Caliber . « », - . :

• . , ( , ) .
  
• . , , , , . , , , , .
  
• . , , : « - », « Caliber», «», «» « ». , , — : .
  

? , .

1. , .
   
2. . — .
   
3. — , , .
   
4. , , , .
   
5. L'outil a pu visualiser les indicateurs de performance et montrer leur évolution, ce qui s'est avéré utile lorsque nous avons décidé de partager notre expérience avec d'autres développeurs Web de l'entreprise. De tels outils nécessitent de fixer des restrictions sur les indicateurs de performance, dépassant ce qui entraînera le rejet des demandes de modifications du code (ou simplement des notifications viendront).
   
6. L'outil proposé était inclus dans le flux de travail et pouvait fonctionner sans effort de notre part - il n'était pas nécessaire de prélever des ressources sur d'autres tâches.
   

Conclusion

J'ai essayé de donner quelques conseils sur la façon de créer des sites plus réactifs - j'espère avoir réussi. Merci de votre attention!

À propos du traducteur

L'article a été traduit par Alconost.

Alconost localise des jeux , des applications et des sites en 68 langues. Traducteurs en langue maternelle, tests linguistiques, plateforme cloud avec API, localisation continue, chefs de projet 24/7, tout format de ressources de chaîne.

Nous réalisons également des vidéos de publicité et de formation - pour les sites qui vendent, présentent des images, de la publicité, des formations, des teasers, des explicateurs, des bandes-annonces pour Google Play et l'App Store.

Plus de détails