The plugin details page lists github stats, which are grabbed via JS that queries for them. GitHub places are fairly small rate limit on these queries per IP address though, so if someone is browsing many plugins, or going back and forth between a few for a while, the stats will stop appearing until enough time passes that they're under the rate limit again.
These JS queries are grabbing current values, so I don't think I want to get rid of them, but I think we should gracefully fall back to values that we query for ourselves during build time. I haven't done the styling for this, but the project_data plugin already is capable of downloading the data. The templates just need to start using it, and we need some styling so that the user can't tell the difference when the rate limiting kicks in. This should probably come after #206 though, because without the project data being cached this will cause a jump in build time.
Post #194
The plugin details page lists github stats, which are grabbed via JS that queries for them. GitHub places are fairly small rate limit on these queries per IP address though, so if someone is browsing many plugins, or going back and forth between a few for a while, the stats will stop appearing until enough time passes that they're under the rate limit again.
These JS queries are grabbing current values, so I don't think I want to get rid of them, but I think we should gracefully fall back to values that we query for ourselves during build time. I haven't done the styling for this, but the project_data plugin already is capable of downloading the data. The templates just need to start using it, and we need some styling so that the user can't tell the difference when the rate limiting kicks in. This should probably come after #206 though, because without the project data being cached this will cause a jump in build time.