Jquery : CDN Google ou CDN Jquery
- Auteur de la discussion saluts92
- Date de début
Pareil que Spout; tout en local. Sauf que je build pas (encore).
Par contre j'ai Google font en accès distant. Je ne sais pas si on peut le mettre en local ?
@saluts92 >> Tu peux tester les 2 et comparer les performances dans la console de ton navigateur et aussi faire quelques tests distants avec GtMetrix etc ...
Mais ama au niveau des perfs on doit assez proche.
Par contre j'ai Google font en accès distant. Je ne sais pas si on peut le mettre en local ?
@saluts92 >> Tu peux tester les 2 et comparer les performances dans la console de ton navigateur et aussi faire quelques tests distants avec GtMetrix etc ...
Mais ama au niveau des perfs on doit assez proche.
il y a t-il une raison particulière à cela ?
spout
WRInaute accro
Je trouve que c'est plus facile de maintenir avec NPM.
Si j'utilisais un CDN ce serait un privé pour y uploader mes assets, pas un 3rd party pour jQuery, Vue.js, Bootstrap, ...
AMHA c'est plus rapide de servir 1 seul fichier bundle.js que 10 sur des CDN.
colonies
WRInaute impliqué
Ça a TOUJOURS été une mauvaise idée. Mais quand je dis toujours, c'est toujours, même en HTTP 1.x, et ça l'est encore plus avec H2 : tu fais une modif de 3 caractères sur une fonction et hop, il faut tout retélécharger, y compris ton jQuery qui n'a pas bougé d'un pouce... alors que H2 est, pour vulgariser (très) grossièrement, un concaténeur de fichiers automatique.
En HTTP 1.x, il fallait essayer d'équilibrer le poids entre autant de fichiers JS + CSS que le navigateur permettait de connexions simultanées (pour des ressources bloquantes placées en en-tête de page). Sauf que c'est pas facile à mettre en place, c'est pas aussi simple à retenir, du coup entre les dizaines de fichiers et un seul gros, il valait encore mieux un gros et c'est devenu une règle de base indiquée aux développeurs en recherche de conseils pour améliorer les perfs.
Mais ça n'a jamais été optimal.
Et personnellement, je préfère defer à async. En général, ça finit avec un async qui attend que le DOM soit prêt, et du coup c'est moins efficace. Async n'est vraiment intéressant que pour les choses qui ne concernent pas vraiment le contenu de la page, par exemple Analytics, encore que c'est discutable.
rick38
WRInaute passionné
Absolument faux ! Je ne répondrai pas sur le HTTP/2 qui n'est même pas encore actif sur tous mes sites.
Mais quand on veut de la vitesse, on ne fait pas charger des liens qui se trouvent sur un autre domaine ! Cela fait perdre du temps. Donc on fait 1 lien sur son domaine à soi, plutôt que de faire appel aux librairies hébergées ici et là. Ce n'est pas une question de taille mais de recherche et réponse du domaine, DNS tout ça tout ça...
Et des sites qui modifient leur code JS souvent, heu, c'est en général quand le site n'est pas fini ! Sinon les utilisateurs sont de toute façon, depuis le temps, des nouveaux visiteurs qui de toute façon n'ont pas en cache l'ancien JS. Tant pis pour les quelques habitués, ils ont a recharger le fichier quoi, 2 fois par an...
D'autant qu'avec l'asynchrone, un fichier de 50 ou 100 ou 200 Ko, ça ne change pas grande chose !
(je ne fais pas partie de ceux qui mettent 10 Mo de JS par contre)
spout
WRInaute accro
Si c'est pas compatible il fallback en HTTP 1 donc no souci.
colonies
WRInaute impliqué
Je n'ai pas dit qu'il fallait répartir sur divers domaines, mais en plusieurs fichiers sur le même domaine.
Le truc, c'est que le navigateur, en HTTP 1, cherche toujours à ouvrir son nombre max de connexions. S'il trouve une CSS, un JS, il complète avec ce qu'il trouve d'autre, typiquement des images. Du coup, la bande passante allouée aux ressources critiques est partagée avec des choses moins essentielles. Fais deux pages de test et analyse la vitesse de chargement, tu verras...
De plus quand on n'a qu'un fichier, c'est bien souvent qu'on charge les pages de choses qui ne concernent pas uniquement le contenu que l'utilisateur consulte. Généralement, je divise en 1 fichier qui concerne tout le site / 1 fichier qui concerne la rubrique / et éventuellement 1 fichier qui concerne la page. En JS comme en CSS.
Ou des sites qui sont actifs.
Non non : ce que j'ai exposé est mieux pour les chargements avec un cache vide ET pour les sites régulièrement mis à jour, avec un public régulier. Pour te donner un exemple, selon Analytics, sur la semaine j'ai : Returning Visitor 47,5% / New Visitor 52,5%. J'ai à peu près 41% d'utilisateurs sur mobile - qui ne sont pas forcément sur leur canapé en WiFi ou dans une ville couverte par la 4G.
Et enfin, je fais beaucoup, beaucoup plus que deux mises à jour par an, d'où un autre intérêt de splitter le code par site / rubrique / page : une modif faite pour une zone du site ne va pas déclencher un rechargement des ressources sur l'intégralité du site.
spout
WRInaute accro
En général, au delà de la vitesse et tout trafic réseau, on essaie d'utiliser le moins possible de truc externes.
Surtout parce que tout ce qui est externe, peut être modifié, mis à jour ... avec à la clef des plantages et parfois des lenteurs sans qu'on ait la main sur l'extérieur (j'ai déjà vu des scripts des chat , ralentir des sites parce qu'il avaient un problème).
Donc si on peut avoir une version figée et qui fonctionne c'est mieux que de dépendre d'un contenu / javascript externe
Pour le trafic "interne" c'est du cas par cas, mais . Mais tout ce qui regroupe est bien. On va même jusqu'a bourrer le css et le javascript dans un 1 seul fichier html
Surtout parce que tout ce qui est externe, peut être modifié, mis à jour ... avec à la clef des plantages et parfois des lenteurs sans qu'on ait la main sur l'extérieur (j'ai déjà vu des scripts des chat , ralentir des sites parce qu'il avaient un problème).
Donc si on peut avoir une version figée et qui fonctionne c'est mieux que de dépendre d'un contenu / javascript externe
Pour le trafic "interne" c'est du cas par cas, mais . Mais tout ce qui regroupe est bien. On va même jusqu'a bourrer le css et le javascript dans un 1 seul fichier html
Discussions similaires
