Building a Static Background Gallery With Astro and No Backend

People searching for a video-call background want one thing: click, download, done. No signup wall, no watermark, no "premium" grid.

That single constraint shaped how I built a small gallery of 1920×1080 backgrounds for Teams and Zoom, and most of the work turned out to be file handling rather than design. The site is live at MeetingBG, if you want to see the result before reading the notes.

One manifest, many pages

Every background lives in a JSON manifest: filename, title, page slug, alt text, dominant color. A small render step turns that manifest into static pages, and Astro builds the rest. There is no CMS, no image API, and no database to keep in sync.

The trade-off is that adding a background means editing a file and redeploying. For a gallery that changes a few times a month, that is a feature: the build fails loudly if an image is missing, and the sitemap is generated from the same source of truth as the pages.

The spec I refuse to compromise on

• 1920×1080, 16:9. Anything smaller looks soft on a 1440p display, and anything non-16:9 gets cropped by both Teams and Zoom.
• sRGB, no CMYK exports. Phone screenshots and print exports are the two most common sources of washed-out backgrounds.
• Under roughly 400 KB per file. Teams will accept larger images, but uploads over a few megabytes make the "Add new" flow feel broken on older laptops.
• No important detail in the bottom third. That is where your name plate and the call controls sit.

The size rules matter more than people expect, so I keep a size guide I keep sending people instead of retyping it in every reply.

Download links should be real links

The download button is an anchor with a download attribute pointing at the actual file, not a JavaScript handler that fetches a blob. Three reasons:

• Middle-click and "Save link as" work, which is how a lot of people actually save images.
• The filename survives: office-desk-1920x1080.jpg is far more useful in a Downloads folder than image7.jpg.
• It degrades gracefully. If JavaScript fails, the gallery still works.

Three support questions that keep coming back

"I uploaded a new background but Teams still shows the old one." Teams keys custom backgrounds by filename in the local cache. Rename the file, or upload under a new name, and the old entry stops winning.

"The text in my background is backwards." Zoom mirrors your self-view by default. Either avoid text in the image, or turn off "Mirror my video" while you check it.

"My edges look ragged." That is the segmentation model, not the image. A plain wall behind you and a background without a busy pattern right behind your head will do more than any resolution bump.

What "no backend" bought me

Static hosting on Cloudflare Pages, a sitemap generated at build time, and a deploy that takes seconds. Image variants are generated ahead of time, so the HTML ships with width and height on every image and there is no layout shift while the grid loads.

The parts I would do differently next time: generate WebP and AVIF variants instead of shipping JPEG only, and store the dominant color per image during ingest rather than computing it in the browser for placeholders.

Numbers I check after every deploy

• Largest Contentful Paint on the gallery pages, on a throttled connection. A 49-image grid will find your mistakes fast.
• Cumulative Layout Shift. Zero, or the grid is broken.
• Every download link returns 200 and the correct Content-Type. A gallery that 404s on the "Download" button is worse than no gallery.

None of this is novel. It is just the unglamorous part of shipping a content site that people actually use: fixed dimensions, real files, real links, and a build that refuses to guess.

Top comments (1)

下载链接坚持用真实 加 download 属性这点最打动我，中键另存和文件名保留都是平时最容易被 JS 下载方式偷偷破坏的细节。Teams 按文件名缓存旧图那段也很实用，改名再上传比让用户清缓存靠谱得多。我还会把底部三分之一不放关键信息这条单独记下来，会议里的名牌和控制条确实会把画面下沿挡住。