# Slow Pages Cost Sales: A Practical Guide to Image Optimisation for Faster Websites
Most Irish businesses put real effort into their homepage headline, their service pages and their Google Business Profile, then quietly undo a lot of that work by uploading a six-megabyte photograph straight from a phone. Images are almost always the heaviest part of a web page, and the way they are saved, sized and delivered has a direct effect on how quickly a site loads for a customer standing in a car park in Portmarnock, browsing on a phone in a hotel lobby in Galway, or scrolling on the Dart into Connolly Station. The good news is that image optimisation is one of the cheapest and fastest performance improvements available — no redesign required, just a better set of habits applied consistently.
## Why Images Are Usually the Heaviest Load on a Website
A typical web page is made up of text, code, stylesheets, scripts and media. The text and code are usually tiny. Images are not. A single hero photograph exported at full camera resolution can weigh more than the rest of the page combined, and a gallery of twenty such images can push a page well past the point where a mobile visitor gives up waiting. Modern phone cameras produce files of four, eight or twelve megabytes without the user doing anything unusual, so the problem is not carelessness — it is simply that the default settings work against you.
The consequences show up in three places. The first is **user patience**. Research across the industry has consistently shown that visitors abandon pages that take more than a few seconds to become usable, and mobile users on patchy coverage are the least forgiving. In Ireland, where a customer might be on full-fibre in Stillorgan and a weak 4G signal in parts of Donegal or Mayo, your page has to perform for the worst realistic connection, not the best one.
The second is **Core Web Vitals**, the performance signals Google uses to describe page experience. *Largest Contentful Paint* (LCP) measures how long the biggest visible element takes to appear — and on most sites that element is an image, usually the banner or the main product photo. *Cumulative Layout Shift* (CLS) penalises pages where content jumps around as images load without reserved space. *Interaction to Next Paint* (INP) reflects how responsive the page feels once someone starts tapping. Heavy, unsized images damage all three.
The third is **rankings and revenue**. Page speed is not a magic ranking button, but it feeds into how Google evaluates page experience, and it strongly influences whether a visitor stays long enough to convert. A café whose menu page stalls, a solicitor whose team photo blocks the contact button, or a retailer whose product grid loads one tile at a time will lose enquiries they never see. Slow pages rarely announce themselves in analytics as “lost sales” — they simply show up as short sessions, high bounce rates and disappointing conversion figures.
## Choosing the Right Formats, Sizes and Loading Techniques
The first decision is **format**. The traditional JPEG remains fine for photographs, but newer formats deliver the same visual quality at a fraction of the size. *WebP* is now widely supported and typically saves a significant percentage over JPEG and PNG. *AVIF* goes further still, though it needs a modern stack and careful fallbacks. PNG should be reserved for images that genuinely need transparency or crisp flat colour; logos and icons are better served as **SVG**, which stays sharp at any size and weighs almost nothing. Screenshots and graphics with text are common offenders — exporting them as large PNGs is one of the quickest ways to bloat a page.
The second decision is **dimensions**. There is no benefit to uploading a 4,000-pixel-wide photograph to fill a 600-pixel slot; the browser still has to download every pixel you sent. Resize before upload, using the largest size the image will actually be displayed at, and account for high-density screens by supplying roughly double that width rather than ten times it. Then use *responsive images* — the `srcset` and `sizes` attributes — so the browser can pick a smaller file for a phone and a larger one for a desktop monitor.
The third is **compression**. Most images can be compressed to somewhere around 70–80% quality with no perceptible loss on screen, and tools for this are free and quick. Run every upload through compression, or configure your CMS or an image-optimisation plugin to do it automatically on upload and on delivery.
The fourth is **loading behaviour**. Adding `loading=”lazy”` to images below the fold tells the browser to fetch them only as the visitor scrolls, which dramatically improves initial load. The important exception is the largest image at the top of the page — lazy-loading your hero image will *hurt* LCP, so it should load immediately, ideally preloaded and served from a fast host or CDN. Always set explicit `width` and `height` attributes so space is reserved and the layout does not shift as images arrive.
Finally, **delivery infrastructure** matters. A content delivery network caches images at edge locations close to your visitors, so someone in Cork or Belfast is not waiting on a server in another continent. Image CDNs go further, converting and resizing files on the fly. Caching headers, browser caching and a clean, modern hosting setup often deliver as much speed gain as the images themselves.
## Where Image Optimisation Meets SEO, Local Search and Everyday Workflows
Speed is only half the story. Images are also *content*, and they are indexed, ranked and read by both search engines and assistive technology. Every meaningful image needs a descriptive **alt attribute** written in plain language — “solicitor’s office reception on Church Street, Portmarnock” rather than “IMG_4471”. Alt text serves visitors using screen readers, gives Google context it cannot get from the pixels, and creates a second chance to rank for relevant searches. File names should be similarly descriptive, with hyphens rather than underscores, and written before upload rather than cleaned up months later.
On-page images also do real work for **local and service visibility**. A tradesperson’s gallery of completed bathroom installations, a clinic’s photos of its treatment rooms, a restaurant’s images of its dishes, or a hotel’s shots of sea views all reinforce what the business does and where it does it. Those images are eligible to appear in Google Images, feed into image sitemaps, and enrich a Google Business Profile, where fresh, well-shot photos often make the difference between a listing that gets tapped and one that gets scrolled past. Retailers have an additional layer to consider: consistent product photography, zoom-friendly resolution and correctly sized thumbnails all affect whether a shopper trusts the listing enough to add it to a basket.
The practical reality is that most sites accumulate images over years, across several staff members and at least one website redesign. A **workflow** beats a one-off clean-up. Set a maximum upload width. Compress everything. Ban the direct-from-camera upload. Give whoever publishes blog posts a one-page checklist covering resizing, alt text and file names. Then review quarterly with a speed testing tool on a real mobile connection, watching LCP and total page weight rather than only the headline score.
Illustrative patterns are easy to recognise. A hotel with a beautiful but unoptimised gallery of forty photographs can see its mobile homepage transform once those images are converted, resized and lazy-loaded. A trades site that uploads job photos at full resolution every week slowly drifts back into slow territory within a year. A professional services firm that shot team portraits at a photoshoot in 2019 may still be serving those originals with no compression and no responsive sizes at all.
*Image optimisation is rarely a single fix; it is a set of technical and editorial decisions that belong inside a wider speed and search strategy.* If your site has built up years of unoptimised uploads and you would rather not untangle them alone, a technical review covering images, code, caching and page structure together is often the sensible shortcut — you can learn more here about how that kind of audit works in practice.
Born in Sapporo and now based in Seattle, Naoko is a former aerospace software tester who pivoted to full-time writing after hiking all 100 famous Japanese mountains. She dissects everything from Kubernetes best practices to minimalist bento design, always sprinkling in a dash of haiku-level clarity. When offline, you’ll find her perfecting latte art or training for her next ultramarathon.