Optimiser le code dans un monde qui ne veut pas optimiser

L'optimisation prématurée est la racine de tout Mal.

C'est un dicton courant chez les développeurs. Ca a du sens. Optimiser prématurément peut signifier refaire le travail sur toute la ligne, et le temps est la ressource la plus limitée du développeur. Cela peut signifier passer ce temps précieux à optimiser des scénarios qui n'existent pas encore pour les utilisateurs d'un produit. Cela peut signifier écrire du code plus difficile à comprendre avec des gains de performances peu clairs.

En participant à l'équipe de révision des thèmes WordPress il y a environ un an, je suis tombé à nouveau sur cette pépite de conseils. L'optimisation prématurée est la racine de tout Mal. La réponse était à un auteur de thème qui cherchait à réduire le nombre et le poids des scripts que son thème devait charger. D'une part, l'auteur du thème pourrait charger un script de 1,29 Ko sans dépendances pour faire le travail. L'autre option était d'utiliser le script dépendant de jQuery inclus dans le noyau de WordPress pour un total de 105 ko car « la plupart » des sites WordPress chargent de toute façon jQuery.

Pour moi, la réponse était simple. Utilisez le plus petit script, sauf si le script principal a déjà été chargé sur le frontal. Je n'y ai pas pensé en termes d' optimisation prématurée . Je le considérais comme une simple optimisation quotidienne, banale et banale.

Les développeurs ne doivent pas confondre l' optimisation prématurée avec le concept de prise de décisions de conception intelligentes au début du processus. Ils ne doivent pas non plus attendre la dernière étape du développement pour commencer à optimiser, un moment où l'accent est mis sur la livraison d'un produit aux utilisateurs finaux. C'est le signe d'un processus de conception de produit médiocre.

Au cours de la dernière année, cette conversation est restée avec moi. Cela m'a aidé à devenir plus conscient d'une tendance terrifiante, non seulement dans la communauté des développeurs WordPress, mais avec le développement Web en général. Bien trop souvent, les développeurs sont si éloignés des utilisateurs normaux et la technologie sur laquelle ces utilisateurs s'appuient pour cette optimisation n'est guère plus qu'une réflexion après coup. Au lieu de cela, il devrait toujours être au premier plan de l'esprit de tout développeur.

Le recours excessif à cette citation mal utilisée a contribué à pousser la tendance à mesurer le poids des pages en mégaoctets au lieu de kilooctets. Il est trop souvent utilisé comme justification fourre-tout pour ne pas faire d'optimisation en phase de développement tout en se rattrapant par la compression des fichiers et la mise en cache en production.

Une partie de l'écriture d'un code de qualité consiste à optimiser ce code à chaque étape du processus de développement. Il s'agit de prendre des décisions difficiles pour couper les choses inutiles au fur et à mesure que le logiciel se met en place. La mise en cache devrait être un dernier recours après que tout le reste a été nettoyé.

L'optimisation prématurée consiste davantage à tenter d'optimiser lorsqu'il n'y a pas de gains clairs ou à travailler sur des micro-optimisations qui modifient la conception du logiciel pour un bénéfice minime ou nul. Cela ne signifie pas négliger les gains de performances évidents pendant le développement.

Tout le monde n'est pas sur Internet Gigabit

La plupart des développeurs que je connais utilisent des connexions Internet ultra-rapides, souvent avec des vitesses de téléchargement de 1 Gbps et des données illimitées. Dans cette situation, il est facile d'oublier que de grandes parties du monde sont toujours sur des connexions lentes avec des plafonds de données.

Certains peuvent même associer des connexions lentes avec des pays du tiers monde où des millions de personnes utilisent la technologie de téléphonie mobile 2G. Cependant, de vastes pans des États-Unis et d'autres pays développés n'ont pas de lignes directes par câble ou DSL, qui sont généralement disponibles dans les villes et les banlieues.

Cette déconnexion est directement évidente lorsque d'autres développeurs ont initié des discussions avec moi. Au cours des deux dernières années, il est devenu de plus en plus courant pour eux de demander un chat vidéo. On ne se demande même pas si une telle chose est possible (les chats vidéo ne sont au mieux pas fiables pour moi). La possibilité de discuter par vidéo à tout moment est considérée comme acquise.

Il existe deux options de service Internet dans la région où j'habite : par satellite ou par ligne commutée. Même la compagnie de téléphone locale refuse d'offrir le DSL dans cette zone en raison des coûts d'infrastructure avec des lignes téléphoniques vieilles de plusieurs décennies. En raison des coûts prohibitifs de l'accès Internet par satellite, qui s'accompagne généralement de limites de données, beaucoup sont bloqués avec l'accès commuté. Les compagnies de téléphonie mobile changent le jeu dans une certaine mesure, en supposant que le service est fiable, mais il y a des inconvénients à emprunter cette voie, qui peuvent inclure des limitations de données ou de points d'accès.

Pour un pays aussi avancé sur le plan technologique, beaucoup de ses habitants rattrapent à peine ce que d'autres étaient il y a dix ans.

Bien que j'aie la chance de choisir où je vis et que rien ne m'empêche de déménager, la plupart n'ont pas cette option. Ils sont coincés avec le meilleur qu'ils peuvent se permettre. Même dans les zones rurales, Internet fait partie intégrante de la vie quotidienne et les développeurs ne facilitent pas la tâche de ces personnes.

Bien que ce soit anecdotique, c'est la dure réalité de la vie rurale dans les poches des États-Unis.

L'avantage de vivre dans l'arrière-pays de l'Alabama est que cela a changé ma perspective en tant que développeur. Cela signifiait que je devais remettre en question chaque décision de code pour chaque plugin et thème que j'ai construit. Avec les plafonds de données, je devais m'assurer que je n'utilisais pas trop de ressources.

Plus que tout, le fait d'avoir un plafond de données a changé ma façon d'utiliser Internet. Je lance maintenant un bloqueur de publicités. J'ai une extension pour tuer les vidéos du chargement automatique. Je désactive JavaScript sur les sites lourds que j'ai besoin d'utiliser. Certains sites semblent intéressants, mais je n'y retourne jamais car ils sont gourmands en ressources.

Lorsque vous vivez dans un endroit où chaque octet compte, vous avez tendance à éviter de les gaspiller.

Bien que n'ayant pas toujours réussi, depuis ma transition vers la vie dans une petite ville, j'ai tenté de créer des applications d'une manière qui serve les personnes qui ne sont pas assez privilégiées pour avoir un accès Internet ultra-rapide.

Le souligner consiste à s'assurer que les développeurs sont conscients de l'importance de l'optimisation. Cela compte à chaque étape du processus de développement. C'est important parce que ces personnes avec des connexions lentes et des plafonds de données doivent également acheter des produits, utiliser des services, lire du contenu et faire toutes les autres choses que les gens font sur le Web.

Si vous êtes un développeur qui envisage d'ajouter ce curseur, un mécanisme de balayage pour mobile ou un autre gadget astucieux, pensez à ceux qui doivent attendre que cette fonctionnalité se charge. Vérifiez que ses dépendances ne chargent pas trop de ressources supplémentaires. Faites des recherches pour voir si vous pouvez trouver une implémentation plus légère. Mais, d'abord, demandez-vous si c'est nécessaire.

Les thèmes et plugins créés par les développeurs WordPress ne devraient jamais être le goulot d'étranglement d'un site Web. Nous pouvons faire mieux.