Jamstack and static sites: preparing image assets with Git, previews, and browser-side tools

Teams that ship Jamstack, static sites, or Next.js with mostly pre-rendered pages often face a boring problem: images are binary blobs in Git, designers do not live in YAML, and Lighthouse still complains after the sprint ships. This article is not a tutorial for one framework - it is a workflow map that works with Astro, Eleventy, Hugo, Next export, or anything that ends up as HTML on a CDN.

Browser tools like toolit’s Image compress, Image crop, and Rotate image fit before commit: humans make creative decisions locally; CI enforces guardrails if you add them later.

Why “just use the CDN transform” is only half an answer

Image CDNs can resize on the fly, serve AVIF, and apply quality knobs - excellent at scale. But someone still has to:

Choose subject and crop so the crop center survives arbitrary aspect ratios.
Export a reasonable master so transforms have good source material.
Ensure social and OG images exist as real files or deterministic routes.

Transforms do not invent composition. They optimize delivery; they do not replace art direction.

A sensible repo layout for marketing sites

Opinions vary; a pattern that reduces chaos:

public/
  images/
    blog/
      2025/
        hero-analytics.webp
        figure-lcp-chart.png
    og/
      default.png
content/
  blog/
    my-post.md

Principles:

Stable paths - avoid renaming files every edit; broken links hurt SEO and trust.
Descriptive filenames - hero-analytics.webp beats IMG_2048.webp in Git diffs and content reviews.
Separate OG assets when marketing wants a different crop than the in-article hero.

The PR review loop (images are content)

Treat image changes like copy changes:

Diff shows a binary change - that is fine; pair it with a screenshot in the PR or a Netlify / Vercel preview link.
Alt text lives in Markdown or JSX - reviewers can comment on accessibility the same way they comment on headings.
Performance budget optional: fail CI if an image in public/ exceeds N MB - brutal but effective.

Responsive images without losing your mind

If you hand-author HTML, you eventually write srcset and sizes. The mental model:

srcset lists candidate files with widths or descriptors.
sizes tells the browser how wide the image will be at various viewports - so it picks a candidate.

Getting sizes wrong is a common reason mobile downloads desktop-sized files. If your team does not want to hand-maintain five widths, a pragmatic approach:

Ship one well-chosen width for blog figures (often enough for v1).
Add srcset when analytics shows image weight is a real problem.

toolit helps you produce those variants quickly from one master without a server round-trip - export 720w and 1440w WebP in two passes through Image compress and wire them in srcset.

Where OG Preview fits in staging

Before you merge the post that announces a feature, paste the preview deployment URL into OG Preview. Staging URLs sometimes differ from production (canonical, robots, auth) - validate on the URL you will actually share when the post goes live.

Gotcha: if staging uses basic auth, many crawlers will not see your meta tags - debug OG on an unauthenticated environment or use platform-specific preview tools that accept auth (rare).

Memes and “engineering culture” content

Internal newsletters and public blogs sometimes use Meme generator for fast visuals. Keep the same accessibility lens: if the meme carries meaning, reflect it in caption or alt; if it is pure ornament, empty alt may apply.

Security and privacy (why local browser processing shows up here)

Client-side cropping and compression mean sensitive screenshots for unreleased features never hit a random SaaS uploader during the draft phase. That is not a substitute for NDAs - but it removes one leak vector in the workflow.

When to graduate to heavy automation

Consider build-time optimization (next/image, astro:assets, eleventy-img) when:

You have hundreds of images.
You need automatic srcset and format negotiation.
Designers drop huge masters into a folder and expect the pipeline to fix everything.

Until then, disciplined humans + browser tools + Git often ship faster than a half-configured pipeline nobody trusts.

Checklist before you merge

Dimensions match real layout; no 6000px masters for 720px columns.
Format choice documented (WebP/JPEG/PNG) with a reason.
alt text written for informative images; empty for decorative.
OG/Twitter validated for the public URL after deploy.
Preview link shared in PR for non-technical reviewers.

Versioning and rollbacks

When marketing swaps a hero for a campaign, keep the old file in Git history - you will roll back faster than you can recreate art direction from memory. Naming with dates or campaign codes (hero-spring-2025.webp) helps git revert without guessing which binary was “the good one.”

If you use immutable CDN URLs with hashed filenames, document how HTML references update - otherwise you ship new bytes but old links.

When designers work in Figma

Export 2× when needed, but do not export unbounded @4x “for safety” into public/ - that is how multi-megabyte PNGs end up in Lighthouse. Agree on export presets: max width, format, and whether text stays in Figma or moves to HTML. Image compress is a good sanity check on exports before they touch the repo.

Closing

Jamstack rewards clarity: static assets, explicit paths, fast CDN delivery. Images are the messy part - creative, heavy, and easy to get wrong. Split the problem: humans decide crop, rotation, and quality in the browser; your site enforces structure, accessibility, and performance in code.

If you are small, stay small: master Image crop and Image compress before you buy complexity. You can always automate later - but you cannot un-ship a blurry hero that went viral for the wrong reason.

Image Tools

Other