@daycode Et les 2 se moquent de la sécurité, et des perfs en général. Parce que avec leurs CPU de joueur et leurs 12 GB de RAM « Chez moi, ça marche bien! » avec 3 frameworks JS à la mode pour 3 pauvres animations dans les menus, ou cette bouse d'electron « pour faire des applications multiplate-formes (sans rien bitter à la programmation système) »…

Follow

@devnull le dev front pas trop mauvais est généralement sensibilisé un minimum aux performances 😉

surtout qu'il y a de très bon outils déjà dans le navigateur (que chrome pour le moment) pour simuler des connexions lentes et donner des pistes d'optimisations 😊

@Madeorsk @devnull
oui, moi par exemple 😊

chez le client où je bosse, on leur a fait tout un plan d'optimisation en différente parties et on est en train de terminé 😉

au global, mise à jour des dépendances, concaténation et minification des CSS et JS, spécialisation des CSS et JS par type de page (pour ne pas avoir tout le code de toutes les pages sur chaque page), lazyload des images, lazyload du JS non nécessaire au chargement de la page

@Madeorsk @devnull
lazyload du CSS en dessous de la ligne de flotaison (appeller critical CSS), création d'un framework CSS custom (pour éviter la duplication de code) et nettoyage du code historique 😊

@daycode Firefox aussi permet de simuler une connexion lente, mais c'est pas que ça dont je parle. Je parle les performances de l'exécution du code même hors temps de chargement de la page (Bien sûr, c'est important aussi). Je parle du navigateur en PLS parce que beaucoup de sites utilisent 36 scripts usinagaz pour une poignées de fonctionnalités superflues.

Je ne sais pas qui est « le dev front » mentionné, mais d'experience/vu la plupart des sites, il n'est pas représentatif…

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!