Récemment, beaucoup de gens disent que les données sur la chaîne "coincent" un peu, en réalité ce n'est pas forcément la chaîne qui est lente, la plupart du temps c'est votre couche d'indexeur/subgraph/RPC qui respire difficilement.

Le subgraph doit balayer les blocs + analyser les événements, et lorsqu'il y a recomposition ou lecture de nœud, il y aura une reconstruction temporaire ;
De leur côté, la limitation de débit RPC est aussi très réaliste, si vous ouvrez trop de requêtes en même temps, les réponses commenceront à flotter, le plus ennuyeux c'est que le frontend peut aussi mettre en cache de vieux résultats, vous faisant croire que vous avez perdu la vue.
En résumé, ces données ne sont pas "en temps réel", mais "aussi proches que possible du temps réel".
Ce que je ne regrette pas, c'est… la fois où j'ai été bloqué par le nonce, j'ai durci le script pour qu'il puisse automatiquement ralentir, réessayer et basculer vers un RPC de secours, sinon je pense que je serais encore en train de râler contre le réseau.
Au passage, en regardant récemment la dispute autour des royalties NFT, en réalité beaucoup de ces chiffres de "transactions/ordres en attente" sont aussi affectés par ces latences, alors ne vous précipitez pas pour vous insulter, vérifiez d'abord si la source de données ne fait pas encore des siennes…
De toute façon, ma première réaction face à un ralentissement : regarder d'abord la limitation de débit, puis la hauteur de l'index.