Directory Image Optimization Guide

Images on directory sites are almost always the largest contributor to page weight — and most directory operators ignore them entirely until Core Web Vitals scores become a problem. Largest Contentful Paint (LCP) failures on listing pages are frequently traced to unoptimised business logos or category hero images that were uploaded once and never touched again.

Format Selection: WebP First, AVIF Where Supported

Serve WebP as the default for all directory images. WebP delivers 25–34% smaller file sizes than JPEG at equivalent visual quality, and 26% smaller than PNG. AVIF offers better compression still — typically 50% smaller than JPEG — but still has edge-case compatibility issues on older Android WebViews and some embedded browsers.

Use the <picture> element with AVIF first, WebP fallback, and JPEG or PNG as the last resort:

<picture>
  <source srcset="logo.avif" type="image/avif">
  <source srcset="logo.webp" type="image/webp">
  <img src="logo.jpg" alt="Business name logo" width="120" height="120">
</picture>

For a directory serving thousands of listing thumbnails, the difference between PNG and WebP at the same quality level is typically a 30–50% reduction in file size per image. Across a category page loading 24 listing thumbnails, that's the difference between 3MB and 1.5MB of image payload — a measurable impact on LCP.

Tools to convert existing image libraries at scale:

• Cloudinary — managed image service with automatic format negotiation and on-the-fly resizing via URL parameters. Charges per transformation but eliminates server-side processing entirely.
• ImageOptim — free desktop app for batch compressing PNGs and JPEGs before upload. Lossless compression removes 15–30% of file size without visible quality loss.
• Sharp (Node.js library) — the standard for server-side image processing in directory software. Handles format conversion, resizing, and quality reduction in a single pipeline call.

Setting File Size Limits That Actually Matter

Most directory upload forms accept any file the submitter provides. This is how a 4MB PNG business logo ends up being served as a listing thumbnail on a mobile device with a 4G connection.

Set and enforce these upload limits server-side:

• Maximum upload size: 2MB — enforced via server validation, not just client-side JavaScript (which is bypassable)
• Accepted formats: PNG, JPG, WebP, SVG — reject GIF, BMP, TIFF, and HEIC at the upload boundary
• Target display size at render: under 100KB per image for standard listing thumbnails at 120×120px
• Featured listing images: under 200KB at 400×300px

Auto-resize on upload using Sharp or Cloudinary to generate canonical versions at your display dimensions. Never store and serve the original upload directly — a submitter's 3000×3000px product photo served at 120px display size is the most common cause of excessive image payload on listing pages.

Lazy Loading and Above-the-Fold Priority

The correct lazy loading strategy for directories is not "add loading="lazy" to everything" — it's about distinguishing which images are above the fold and which aren't.

Step-by-step implementation:

1. Identify the first 3–5 listing cards visible on page load without scrolling (at a 1280px viewport for desktop, 375px for mobile)
2. Apply loading="eager" and fetchpriority="high" to images in those first cards
3. Apply loading="lazy" to all listing images below the fold
4. Apply loading="lazy" to all images in the right sidebar and footer
5. Test the result in Google Search Console's Core Web Vitals report — LCP should drop within 2–4 weeks as Googlebot records the field data change

The reason this matters: if your directory's largest above-the-fold element is a listing logo and it's lazy-loaded, the browser deliberately delays fetching it. That inflates your LCP score for every page using the same template. LCP above 2.5 seconds is flagged as "needs improvement" in Google's field data — category pages and search result pages are the most common offenders.

Logo Handling: Enforcing Quality Without Manual Review

Business logos submitted to directories are chronically poorly sized. Common problems:

• Too small — a 40×40px logo served at 120px display size looks blurry at retina density
• Too large — a 2MB PNG for a 120px thumbnail
• Wrong aspect ratio — a horizontal banner logo forced into a square container, cropped badly
• Transparent background on JPEG — common when submitters convert a PNG logo to JPEG and lose the transparency

A server-side processing pipeline using Sharp solves all of these at upload time:

await sharp(uploadedFile)
  .resize(480, 480, { fit: 'contain', background: { r: 255, g: 255, b: 255 } })
  .webp({ quality: 80 })
  .toFile(`logos/${listingId}-2x.webp`);

await sharp(uploadedFile)
  .resize(240, 240, { fit: 'contain', background: { r: 255, g: 255, b: 255 } })
  .webp({ quality: 80 })
  .toFile(`logos/${listingId}-1x.webp`);

Store a canonical version at 480px (2x) and serve the 240px (1x) version for standard listings. Use the srcset attribute to serve the right size for the device pixel ratio. This adds under 100ms to the upload processing time and eliminates all the downstream problems from user-submitted logos.

Alt Text for Directory Listing Images

Alt text on directory images serves two functions: screen reader accessibility and image indexing signals for Google Image Search. Most directories either leave alt text blank or autogenerate something unhelpful like listing_4521.jpg.

The correct pattern for listing logo alt text: [Business name] logo — simple, accurate, and informative. For category hero images: [Category name] businesses in [Location] where location is relevant.

What to avoid:

• Blank alt attributes (alt="") on non-decorative images — this fails WCAG 2.1 Level A
• Keyword-stuffed alt text: alt="best accountant London cheap accounting services tax returns" — Google's image guidelines explicitly flag this as a quality issue
• Filename as alt text: alt="IMG_4521_final_v2.jpg"

For directories using Cloudinary for image management, alt text can be stored as metadata on the asset and pulled automatically at render time — this keeps alt text management centralised rather than scattered across listing records.

Serving Directory Images from a CDN

Directory images should never be served from the same origin as your application server. Use a CDN with edge caching — Cloudflare's free tier handles this adequately for most directories. Set long cache headers on static assets:

Cache-Control: max-age=31536000, immutable

Use content-addressed filenames (a hash in the URL, e.g. logo-a3f4b2.webp) to bust the cache when images update. If you use Cloudflare, enable Polish (lossy or lossless image optimization at the edge) as a secondary compression layer — this adds another 10–20% file size reduction at no additional cost on Pro plans.

Audit your current image delivery setup with Screaming Frog — crawl your directory and filter the asset list to images, then check the Content-Type header to confirm WebP is being served, and the Cache-Control header to confirm long-lived caching is active. If images are being served as PNG or JPEG with Cache-Control: no-cache, you have immediate gains available without any application changes — just Cloudflare configuration.

---

Knowing which directories actually matter is the hard part. DirectoryReady tracks and scores directories by quality, activity, and link type — so you can focus on submissions that move the needle.