Et tu as prévu de t'intéresser à ce dont tu parles un jour histoire d'éviter de tirer des conclusions à partir de rien ?
Oui, je m'y suis déjà intéressè. Il paraitrait même que je fais du développement web depuis 1994 et que j'ai grouillé dans le code des navigateurs, voir même contribué.
Le single page, c'est une page plutôt légère qui va dynamiquement charger le contenu dont tu as besoin et ça remplace le changement de page par de l'ajax.
Ou pas. Tout dépend comment c'est foutu. Certaines ne remplacent rien, ils ajoutent (et cachent ce qu'il y avait avant). Certains pour des raisons de "perf" : éviter des appels réseaux, pouvoir garder des données ou je ne sais quoi d'autres. Bref. Ouvre le profiler et l'inspecteur réseaux de ton navigateur et navigue sur des beaux sites kikoulol single page utilisant le dernier super framework à la mode. Tu seras surpris des résultats.
Et je ne parle pas des sites single page (ou pas single d'ailleurs) qui chargent le contenu au fur et à mesure que l'on scrolle (et donc ne supprime pas ce qui est au dessus, logique). Un exemple ultra connu : Twitter. Arrivé en bas de la page (façon de parler, disons plutôt, quand on arrête de scroller au bout de trente secondes), le poid total de la page est monstrueux.
Si tout avait été chargé dés le départ, ça aurait pas mal ralentit "l’expérience utilisateur" (c'est pour ça qu'on ne faisait pas de la single page ou du chargement progressif il y a quelques années). Mais au final, dans les deux cas, lazy loading ou pas, le navigateur et l'os en prenne un coup dans la tronche. Encore une fois, suffit de regarder les métriques données par les outils de dev des navigateurs.
Cher un fonctionnement qui peut être lourd ou léger selon comment c'est fait
Voilà, on y est. Ce que je viens d'expliquer quoi.
et ce que tu utilise comme navigateur
Non. Il y aura quelques différences (pas forcément importantes au final) entre navigateurs, mais une page qui charge 1Mo de ressources, ça reste 1Mo de ressources à charger quelque soit le navigateur. Et donc ça fait 1Mo de ressources à traiter, qui sont multipliée par X fois puisque les images sont décompressées, le html est transformé en arbre DOM et en arbre de rendu avec tout ce que cela implique au niveau du layout, du compositing etc etc...
Et de nos jours, en prenant l'exemple de 1Mo, je suis super gentil. Je viens de regarder avec twitter, une application que bon nombre d'internaute utilise, tu en conviendra. Après un scrolling de quelques pages (138 messages twitters chargés et affichés, et non je ne les ai pas compté, le DOM s'en est chargé pour moi ;)), j'en suis à 23 Mo de ressources chargées d'après l'inspecteur réseau, et cela occupe au final 86 Mo après traitement (arbre DOM, JS et tout le toutim) d'après about:memory. À la fin de la journée, au fur et à mesure des messages reçus (plusieurs dizaines ou centaines?), je n'ose imaginer la quantité de mémoire que prend twitter. Et après on accuse les navigateurs d'être lourd, lent etc...
(Possible qu'après un certain nombre de messages, (200 ? 300 ? 1000 ?) il efface les plus anciens, mais je n'ai pas vérifié. En tout cas il n'a pas fait le ménage pendant ce test)
mais il ne s'agit pas de charger tout au début pour ne plus dépendre du réseau ensuite.
Bah si justement. Il y a même des applications qui sont développées spécifiquement comme ça, car elles ont besoin de fonctionner offline ou d'éviter trop de requêtes ou de temps de latence dans l'utilisation à cause des requêtes (avec la pile de lib js qu'on entasse de nos jours dans les sites/apps web, pas étonnant). Les services workers ont d'ailleurs été créés pour ce genre de besoin et résoudre les problèmes des technos appcache &cie.
[^] # Re: Poids Plume
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Sortie de Linux Mint 18 « Sarah ». Évalué à 3.
Oui, je m'y suis déjà intéressè. Il paraitrait même que je fais du développement web depuis 1994 et que j'ai grouillé dans le code des navigateurs, voir même contribué.
Ou pas. Tout dépend comment c'est foutu. Certaines ne remplacent rien, ils ajoutent (et cachent ce qu'il y avait avant). Certains pour des raisons de "perf" : éviter des appels réseaux, pouvoir garder des données ou je ne sais quoi d'autres. Bref. Ouvre le profiler et l'inspecteur réseaux de ton navigateur et navigue sur des beaux sites kikoulol single page utilisant le dernier super framework à la mode. Tu seras surpris des résultats.
Et je ne parle pas des sites single page (ou pas single d'ailleurs) qui chargent le contenu au fur et à mesure que l'on scrolle (et donc ne supprime pas ce qui est au dessus, logique). Un exemple ultra connu : Twitter. Arrivé en bas de la page (façon de parler, disons plutôt, quand on arrête de scroller au bout de trente secondes), le poid total de la page est monstrueux.
Si tout avait été chargé dés le départ, ça aurait pas mal ralentit "l’expérience utilisateur" (c'est pour ça qu'on ne faisait pas de la single page ou du chargement progressif il y a quelques années). Mais au final, dans les deux cas, lazy loading ou pas, le navigateur et l'os en prenne un coup dans la tronche. Encore une fois, suffit de regarder les métriques données par les outils de dev des navigateurs.
Voilà, on y est. Ce que je viens d'expliquer quoi.
Non. Il y aura quelques différences (pas forcément importantes au final) entre navigateurs, mais une page qui charge 1Mo de ressources, ça reste 1Mo de ressources à charger quelque soit le navigateur. Et donc ça fait 1Mo de ressources à traiter, qui sont multipliée par X fois puisque les images sont décompressées, le html est transformé en arbre DOM et en arbre de rendu avec tout ce que cela implique au niveau du layout, du compositing etc etc...
Et de nos jours, en prenant l'exemple de 1Mo, je suis super gentil. Je viens de regarder avec twitter, une application que bon nombre d'internaute utilise, tu en conviendra. Après un scrolling de quelques pages (138 messages twitters chargés et affichés, et non je ne les ai pas compté, le DOM s'en est chargé pour moi ;)), j'en suis à 23 Mo de ressources chargées d'après l'inspecteur réseau, et cela occupe au final 86 Mo après traitement (arbre DOM, JS et tout le toutim) d'après about:memory. À la fin de la journée, au fur et à mesure des messages reçus (plusieurs dizaines ou centaines?), je n'ose imaginer la quantité de mémoire que prend twitter. Et après on accuse les navigateurs d'être lourd, lent etc...
(Possible qu'après un certain nombre de messages, (200 ? 300 ? 1000 ?) il efface les plus anciens, mais je n'ai pas vérifié. En tout cas il n'a pas fait le ménage pendant ce test)
Bah si justement. Il y a même des applications qui sont développées spécifiquement comme ça, car elles ont besoin de fonctionner offline ou d'éviter trop de requêtes ou de temps de latence dans l'utilisation à cause des requêtes (avec la pile de lib js qu'on entasse de nos jours dans les sites/apps web, pas étonnant). Les services workers ont d'ailleurs été créés pour ce genre de besoin et résoudre les problèmes des technos appcache &cie.