Note : RSS - Blogotext
La semaine dernière j’avais dit que BT contiendra un lecteur RSS de mon cru.
Je suis en train expérimenter un truc pour diminuer les charges serveur (PHP / SQL / réseau). J’avais déjà ça dans la gestion des images, et c’est assez performant.
Il s’agit de mettre la data sur le serveur, mais de donner au navigateur le soin de trier les données.
La data est envoyée au client dans le code source (en JSON ici) et c’est le navigateur qui traite tout JS.
Si on dispose d’un serveur un peu faible, ça peut être un gros avantage : ça libère des ressources, pas seulement pour vous, mais pour *tous* les visiteurs : la puissance de calcul est alors prise chez le client, pas le serveur.
Et en plus, il n’y a pas de transfert réseau permanents (sur ma liste de flux, par exemple, que je liste les entrées RSS de tel ou tel flux, le tri se fera côté internaute et non pas côté serveur : plus de transferts et de chargement de page !).
Après, faudra que j’invente un truc pour les mise à jour et les articles lus/non lus, mais j’ai déjà des idées (comme des hit très légers, ou des caches listant les 10 dernières actions du client, qui sont envoyés par groupe au serveur).
Bien-sûr, ça a ses inconvénients, comme une page initiale plus chargée : toute la data est envoyée (mais si on utilise la compression Gzip, c’est finalement plus léger : plus de données = théoriquement meilleur ratio de compression), ou un affichage plus lent sur des smartphones (mais pas tant que ça : sur mon Cink Five, ça passe nickel).
Si je mets ça en place, c’est en voulant éviter des choses que je retrouve dans les autres lecteurs RSS en PHP, à savoir :
- les rechargement de pages à chaque action
- les accès réseau trop nombreux
- le serveur qui croule sur les calcul
Oh et ça marche aussi dans IE 8 !
Ah non, ça c’était une blague… Pardon.
Je suis en train expérimenter un truc pour diminuer les charges serveur (PHP / SQL / réseau). J’avais déjà ça dans la gestion des images, et c’est assez performant.
Il s’agit de mettre la data sur le serveur, mais de donner au navigateur le soin de trier les données.
La data est envoyée au client dans le code source (en JSON ici) et c’est le navigateur qui traite tout JS.
Si on dispose d’un serveur un peu faible, ça peut être un gros avantage : ça libère des ressources, pas seulement pour vous, mais pour *tous* les visiteurs : la puissance de calcul est alors prise chez le client, pas le serveur.
Et en plus, il n’y a pas de transfert réseau permanents (sur ma liste de flux, par exemple, que je liste les entrées RSS de tel ou tel flux, le tri se fera côté internaute et non pas côté serveur : plus de transferts et de chargement de page !).
Après, faudra que j’invente un truc pour les mise à jour et les articles lus/non lus, mais j’ai déjà des idées (comme des hit très légers, ou des caches listant les 10 dernières actions du client, qui sont envoyés par groupe au serveur).
Bien-sûr, ça a ses inconvénients, comme une page initiale plus chargée : toute la data est envoyée (mais si on utilise la compression Gzip, c’est finalement plus léger : plus de données = théoriquement meilleur ratio de compression), ou un affichage plus lent sur des smartphones (mais pas tant que ça : sur mon Cink Five, ça passe nickel).
Si je mets ça en place, c’est en voulant éviter des choses que je retrouve dans les autres lecteurs RSS en PHP, à savoir :
- les rechargement de pages à chaque action
- les accès réseau trop nombreux
- le serveur qui croule sur les calcul
Oh et ça marche aussi dans IE 8 !
Ah non, ça c’était une blague… Pardon.