Launching a website means dealing with roughly ten different image slots at once, each with its own dimensions, format expectations and byte budget. Get any of them wrong and you either ship a slow site, a soft-looking site, or a site whose share previews get cropped in embarrassing ways. This checklist is what we run through on every site launch, in the order we recommend building the assets. It assumes a modern responsive site targeting Core Web Vitals compliance.
1. Favicon set (the invisible one people forget)
The favicon is the browser-tab icon, the mobile home-screen icon when a user saves your site, the PWA manifest icon, and the icon Google shows next to your search result on mobile SERPs. Modern favicon sets need at least: 32×32 (browser tab), 180×180 (Apple touch icon for iOS home screen), 192×192 (Android home screen), 512×512 (PWA manifest and Google search result), plus the classic favicon.ico for old browsers.
Start from a single 512×512 PNG source. Every smaller variant downsamples from that master, so the source needs to look good at 512 px with crisp edges. Anything below 200 px in the source shows visible blur when scaled up to the 512 variants. Our favicon generator produces the full set from one upload — save yourself the eight separate exports.
2. Open Graph and Twitter card images
Open Graph is the image that shows when your URL is shared on Facebook, LinkedIn, Slack, iMessage, WhatsApp, Discord and virtually every modern messaging platform. Twitter (X) uses a separate but similar spec. Missing OG images kill social-share traffic — the shared link becomes a boring text card that nobody clicks.
Dimensions: 1200×630 for Open Graph (Facebook standard, which every other platform accepts as fallback). 1200×675 for X's summary_large_image. Same content, different aspect ratio. Format: JPEG at quality 85, under 500 KB. Don't use WebP — some social scrapers still don't decode it cleanly.
You need at minimum a site-level default OG image (used for the homepage and any page without its own custom card). For blog posts, product pages, and long-form articles, custom per-page OG images with the article title readable at thumbnail size produce 2–4× the click-through of the site default. Our Open Graph generator and Twitter card generator have four practical templates each.
3. Homepage hero (the CWV killer)
The homepage hero is the Largest Contentful Paint element on virtually every marketing site. That means it's the single asset Google measures for the LCP Core Web Vital, and CWV is a documented ranking signal. Target: under 200 KB WebP at 1920 px wide for a full-width desktop hero, or under 150 KB WebP at 1200 px wide for a bounded hero.
Preload the hero explicitly in the HTML head — that shaves 200–400 ms off LCP on cold visits because the browser starts fetching the hero before parsing the CSS. In Next.js: `priority` prop on the `<Image>` component. In HTML: `<link rel="preload" as="image" href="..." />`.
4. Product / feature imagery
Product page mains are the second-highest-value image slot on an e-commerce site (after homepage hero). They also drive conversion directly — users spend 4–8 seconds on a product image before adding to cart. Target: 1600 px WebP at quality 85, under 150 KB. This is retina-sharp at typical product-page display sizes (600–800 px) and hits the CWV budget.
Include a second larger variant (2400–3200 px) for the zoom-in view. Load it lazily — the browser only fetches it when the user actually clicks zoom. This saves 200–400 KB on the initial page load per product image.
5. Blog post inline images
Blog inline images typically render at 600–800 px wide in modern content templates. Upload at 1200 px WebP for retina, quality 82, under 100 KB per image. Blog posts often have 5–10 inline images stacked vertically, so the per-image budget matters — a 100 KB budget × 10 images is 1 MB across a post, which is a reasonable ceiling.
Lazy-load every inline image below the first. Native `loading="lazy"` on the `<img>` tag or via Next.js `<Image>` covers this. Lazy-loading the first inline image is a mistake — it typically sits above the fold on desktop and being lazy-loaded there means the browser fetches it later than it should.
6. Blog post thumbnails and article cards
Blog category and index pages render post thumbnails at ~300 px wide. Upload at 600 px WebP for retina, quality 80, under 40 KB per thumbnail. A blog index page with 20 posts is 20 thumbnails × 40 KB = 800 KB just in card images, so the budget is real.
If your blog uses a "featured image" slot in the CMS, that same image is often reused as the OG image for share previews. In that case use the OG dimensions (1200×630 aspect ratio) as your featured-image aspect ratio to avoid double-managing.
7. Background images and decorative content
Full-viewport background images can afford lower quality (75) because text overlays hide compression artefacts. Target: 2400 px WebP at quality 75, under 250 KB. If the background is a decorative pattern rather than a photo, seriously consider SVG or CSS gradients instead — they scale infinitely and compress to a few KB.
8. Icon set and UI graphics
Every icon, button graphic, empty-state illustration and decorative UI element on your site: SVG. Not PNG, not WebP. SVG is infinitely scalable, ~50–80% smaller than raster equivalents at typical sizes, and can be styled with CSS (colour, size, animation). If you inherited a codebase full of PNG icons, migrating them to SVG is usually a 1–2 hour win with 40–60% asset-size savings.
9. Author photos and testimonial images
Author bylines, team pages, testimonial thumbnails: 400×400 WebP at quality 82, under 30 KB per image. These are always small on-page (60–100 px typically) so retina 400 px is enough. Round-cropped author photos are the standard convention; do the crop in the export, don't rely on CSS border-radius alone (you save the extra image weight of the corners).
10. Every image needs alt text
This isn't a sizing issue but the launch is the moment to enforce it. Every image on the site needs an `alt` attribute. Decorative images that add nothing beyond visual polish get `alt=""` (empty but present — signals to screen readers to skip). Content images get real, descriptive alt text (what would the image communicate to someone who can't see it). Missing alt text hurts SEO (Google can't index the image) and hurts accessibility (WCAG 2.1 Level A violation).
CWV budget for the whole page
A launched-page Core Web Vitals budget worth targeting: total page weight under 1 MB (aim for 600–800 KB), hero image under 200 KB, LCP under 2.5 seconds on a mid-tier 4G connection, no more than three above-the-fold images total. Under those constraints, you'll pass CWV on the vast majority of visits from real users.
Test with real Chrome DevTools throttling ("Fast 3G" or "Slow 4G" profile) — the desktop Wi-Fi experience always looks fine and hides the real performance issues that hit mobile users. If your hero image renders in under a second on throttled mobile, you're in good shape.
The launch checklist in one paragraph
Favicon set from a 512 px source; site-level Open Graph and Twitter card; per-page custom OG images for blog posts; homepage hero at 1920 px WebP under 200 KB, preloaded; product mains at 1600 px WebP under 150 KB; blog inline at 1200 px WebP under 100 KB; blog thumbnails at 600 px WebP under 40 KB; background images at 2400 px WebP quality 75 under 250 KB; author photos at 400 px WebP under 30 KB; every UI icon as SVG; alt text on every image; test on throttled 4G before shipping. Bookmarkable, printable, one page. That's the launch checklist.
Once the site is live, run our website image optimiser against the built assets folder to spot anything that snuck through the checklist. It flags oversized files, wrong-format files, and estimates the byte-savings from re-encoding at the right settings.