Every visitor's browser currently calls he.wikipedia.org directly to fetch MK portraits — see ui/src/hooks/useWikipediaImages.ts, which batches page titles 25 at a time against the Wikipedia API on page load.
Why this should change
- Third-party dependency on first paint. If Wikipedia is slow, rate-limits us, or changes its API, the site loses its portraits.
- No control over what arrives. Image sizes and availability are whatever Wikipedia returns that day.
- Layout shift. Portraits arrive after the grid has rendered.
- Visitor traffic goes to Wikipedia. Every reader of our site generates requests to a third party who did not ask for them.
The work
Resolve images once, server-side, and store them — either the resolved URL against mk.photo_url, or the image bytes in our own object storage with the API serving a stable URL. The UI then reads a field it already has instead of calling out.
Whichever is chosen, the licence and attribution for each image has to travel with it. Wikipedia images are not uniformly licensed and some require attribution on display.
Pairs with the issue on sourcing photographs for MKs who have none.
Every visitor's browser currently calls
he.wikipedia.orgdirectly to fetch MK portraits — seeui/src/hooks/useWikipediaImages.ts, which batches page titles 25 at a time against the Wikipedia API on page load.Why this should change
The work
Resolve images once, server-side, and store them — either the resolved URL against
mk.photo_url, or the image bytes in our own object storage with the API serving a stable URL. The UI then reads a field it already has instead of calling out.Whichever is chosen, the licence and attribution for each image has to travel with it. Wikipedia images are not uniformly licensed and some require attribution on display.
Pairs with the issue on sourcing photographs for MKs who have none.