Jquery : CDN Google ou CDN Jquery

Peu importe.
Mais perso je n'utilise plus les CDN, j'installe tout avec npm et je build avec Webpack.

 

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.

 

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.

 

Après l'avantage du cdn c'est que le fichier a de forte chance d'être déjà en cache sur le navigateur du client.

Mais j'aime bien l'idée d'un seul fichier js en local ;-)

 

Et à mon avis il y a un bon niveau de de chance que jquery chez Google et/ou chez Jquery soit déjà dans le cache du visiteur.

 

Pas de CDN non plus pour moi, afin de n'avoir qu'1 seul fichier .JS (je concatène à l'intérieur les différentes librairies, à commencer en général par jquery, puis mon code spécifique).
1 seul fichier, c'est une règle de base. Et en asynchrone bien sûr !

 

Ç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.

 

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)

 

Si c'est pas compatible il fallback en HTTP 1 donc no souci.

 

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.

 

Quelqu'un a fait un test et :

Src: https://twitter.com/mikesherov/status/1092802789435232261

 

Merci pour ce retour Spout. Super intéressant, comme quoi les chiffres éclairent toujours plus que les croyances...

 

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