Je maintiens toujours mon propre lecteur RSS. Câest cool et ça me permet de faire face Ă des problĂšmes parfois incongrus pour des petits projets.
DĂ©jĂ , faut savoir que ma connexion est pourrie (<2 Mo/s) et que je ne souhaite pas encombrer mon serveur de requĂȘtes trop lourdes. Pour le moment, mon lecteur RSS tourne donc en local.
Si je met ça en ligne, ça me prendrait beaucoup de temps pour ne serait-ce quâouvrir le lecteur RSS.
Certains lecteurs RSS font une requĂȘte Ă chaque ouverture dâun post ou dâun site. Câest impensable pour moi : je ne veux pas attendre 3 secondes Ă chaque clics.
Depuis le dĂ©but, lâensemble des flux RSS "non lus" sont envoyĂ©s au navigateur. GĂ©nĂ©ralement, ça fait entre 2 et 3 Mo, mais comme câest en local, câest instantanĂ©.
Je cherche à améliorer ça.
Je suis aussi sur le point de transformer mon lecteur RSS en PWA (application mobile en HTML/JS/CSS). Pour ça, je dois scinder lâinterface de lâapplication des donnĂ©es. Vu que je bosse intĂ©gralement en JSON, câest trĂšs simple.
Concernant la vitesse, en quelques lignes de JS jâai ma page qui sâaffiche et une fois chargĂ©e, fait une requĂȘte vers le serveur avec les donnĂ©es. Câest pas plus lent quâavant (mais je fais un pas de plus vers la PWA).
LĂ oĂč je mâinterroge, câest comment accĂ©lĂ©rer ça encore plus ?
Sur les 3 Mo transfĂ©rĂ©s, la plus grande partie provient du contenu des articles, le reste Ă©tant plutĂŽt des mĂ©ta-donnĂ©es : date, ID, nom du flux et le titre de lâarticle.
Jâessaye donc :
â Ă lâaffichage de la page, lâinterface sâaffiche.
â Pendant ce temps, une premiĂšre requĂȘte qui rĂ©cupĂšre titre + mĂ©tadonnĂ©es et qui suffisent pour afficher les flux dans une liste.
â une seconde requĂȘte est ensuite faite qui rĂ©cupĂšre le contenu des articles et les attache Ă la liste principale.
La premiĂšre requĂȘte suffit pour afficher la liste des flux : lâutilisateur peut commencer Ă lire les titres et Ă trier visuellement les articles quâil souhaite lire (du moins, perso je fonctionne comme ça).
Pendant quâil repĂšre les articles quâil va lire, la page rĂ©cupĂšre le contenu des articles (2,5 Mo).
Dans lâensemble, ça prend peut-ĂȘtre quelques ms de plus pour charger, mais beaucoup moins de temps pour sâafficher : lâinterface sâaffiche instantanĂ©ment, par exemple. Câest une question de perception de rapiditĂ©.
PSÂ :
Quand je combine le rĂ©sultat des deux requĂȘtes, je fais deux boucles imbriquĂ©es, pour vĂ©rifier lâĂ©galitĂ© tableau1[i].id === tableau2[j].id.
Câest un super-exemple dâutilisation du « break » dont je parle dans cet article. Une fois quâil y a une Ă©galitĂ©, on sort de la boucle et on passe Ă lâĂ©lĂ©ment suivant.
RĂ©sultat : jâai 471 Ă©lĂ©ments RSS Ă parser, donc 471Ă471 = 221 841 tours de boucles Ă faire. Avec le break, je prĂ©disais quâon gagne environ 50 % de la charge. Ăa se vĂ©rifie sur cet exemple : le nombre de tours de boucle est de 111 214. Le gain est de 49,86 %. On y est.
En fait, je mĂȘme beaucoup mieux : comme les deux requĂȘtes renvoie deux tableaux de la mĂȘme base de donnĂ©e rapidement Ă la suite, il est fort probable que les deux tableaux (triĂ©s en SQL) comportent la mĂȘme indexation (sauf si une mise Ă jour des donnĂ©es RSS sâest glissĂ©e pile entre les deux requĂȘtes).
On peut donc faire ça :
// si les ID sont identique, on ne reboucle pas (les deux tableaux comparent à la position « i »)
if (tableau1[i].id === tableau2[i].id) {
# code here
}
// autrement, on recherche dans tout le tableau (tableau 1 sur « i », et le tableau2 sur « j »)
else {
for (var j=0, len2 = _this.feedList.length ; j<len2 ; j++) {
if (newFeeds[i].id === _this.feedList[j].id) {
# code here
break;
}
}
}
Dans le cas idéal, on passe à 471 tours de boucle (pour 471 éléments)
⊠au lieu de 111 214âŠ
⊠au lieu de 221 841.
Câest bien non ?
PPSÂ :
Finalement, le truc oĂč je fais deux requĂȘtes sĂ©parĂ©es câest pas une bonne idĂ©e.
Ăa marche, et lâidĂ©e peut fonctionner ailleurs, mais ici le gain nâest pas aussi important que je pensais. En fait, je viens de voir que les donnĂ©es sont dĂ©jĂ compressĂ©es par Gzip/deflate par le serveur (rĂ©duisant le poids de 2,5 Mo Ă 0,6 Mo environ).
Ăa reste beaucoup de donnĂ©es, mais mĂȘme avec une connexion pourrie, le temps que la connexion se fasse et que le serveur exĂ©cute la requĂȘte, jâen suis dĂ©jĂ Ă 1/3 du temps. Autant Ă©liminer une des deux requĂȘtes et nâen faire quâune seule : ça reste plus rapide.
â (
permalink)