Shields: improve shields.io site performance and load times

[tooomm]

Since there are many many badges linked on the shields page, and all of them are freshly generated ones it takes quite a lot of time to receive all replies and finish loading the page.

I mean, it's only supposed to be a preview right?
Why not simply load a static badge instead for each service to show off how it could look like. That would cut down all the generation and request time.
If a user clicks a badge to customize/adjust a particular one in the opening overlay... it could display the real "live" badge on the top there.

[chris48s]

Hi @tooomm Sorry nobody has properly responded to this issue. Performance of the home page is problematic for end users and has caused problems for some upstream services in the past. I definitely think we should look at improving this aspect of the project. Given this issue has a few :+1:s clearly others agree. Here's a few thoughts/questions on this topic:

It seems like if we make the examples a static badge, there is potential to introduce a kind of duplication or maintenance overhead for the examples i.e: as we change the behaviour of badge code or helper functions, we would have to remember to update the static examples to match (inevitably leading to some 'drift' as the examples don't reflect real world behaviour). If we adopted this approach, can anyone suggest a mitigation?

As noted in #1723 there is potential for us to reduce overhead by using CDN/downstream cache. It seems like this might be better to explore first.

Regardless of whether the badges are static or dynamic and how well cached they are, we've now got hundreds of images on the front-page of https://shields.io/ and we add services much more frequently than we remove them - this is only going to get bigger. Even if they're all well cached static images, loading hundreds of images generates hundreds of requests. Would we be better to split the examples down into a number of smaller pages with less examples (e.g: seperate pages for 'build', 'downloads', 'version' etc). This would give faster page loads for end users and fewer requests to handle server side.

Anyone have further thoughts/suggestions?

[paulmelnikow]

I agree with everything @chris48s said.

• We should not only precompute, but inline the svg badges on the frontend.
• Maintainability is a concern!
• We should build some navigation to split up the full list. It's a bit silly to show the entire list by default.

I don't have a clear answer on how we would maintain these. One option is a script that re-fetches them from a local dev server at deploy time. Though we'd need a way to handle the failed badges.

We could hard-code the badge result in the new-style service. There could still be drift, which I don't love.

Finally, another option is to specify mocks along with the hard-coded examples, which would make it easy to re-run them quickly.

[papakai]

+1 badge generator performance is too slow, badges time out on nearly every request

[chris48s]

I made a start on splitting the site up into smaller pages with examples for 'build', 'downloads', 'version' etc over the weekend. Not ready to submit a PR yet, but just putting a marker down so I'm not duplicating effort with someone else. I'm going to try and work on it some more this week.

[chris48s]

1808 is now merged which is one of the steps towards this

[chris48s]

1740 also now merged which allows us to start replacing 'live' examples (which call an API) with 'static' ones as we refactor badges out of server.js. To start with, only a small subset have a static example defined so there is more work to do here but the core feature is now in.

[paulmelnikow]

Lots of improvements were made here, including categories, static examples, and the broader downstream-cache improvements. 🏆

There's some follow-on working which is adding static examples for all the badges. If there's interest in tracking that specifically, let's open a new issue. Ref: #1961