Website Designer in Pune: How to Fix Slow Images with WebP, AVIF, Responsive Images and LCP

Website Designer in Pune: How to Fix Slow Images with WebP, AVIF, Responsive Images and LCP

The fastest way to fix a slow website is usually to fix its largest image. Convert photos to WebP or AVIF, serve each visitor a file sized for their screen with srcset and sizes, give every image width and height, and treat the main banner differently from the rest: never lazy-load it, and tell the browser to fetch it first with fetchpriority="high". A good website designer in Pune checks these five things before touching anything else, because on most photo-heavy business sites the hero image is what decides your Largest Contentful Paint (LCP) score.

This article is for Pune business owners whose WordPress or custom-built site feels slow because of heavy photos: a clinic, a school, a real-estate developer, a manufacturer, a restaurant or an NGO. You do not need to write code. You need to understand enough to read a PageSpeed Insights report, ask a designer the right questions and spot a vague answer. It does not cover hosting plans in depth, payments, shipping or tax. Technical statements come from web.dev, MDN, Chrome, WordPress Core's own developer blog and caniuse, read in October 2026; where a figure comes from a secondary summary, I say so. Browser support and WordPress versions move, so check the current pages listed under Sources.

How images decide your LCP score

Largest Contentful Paint measures how long the biggest visible element takes to appear. According to web.dev, a good LCP is 2.5 seconds or less, and above 4.0 seconds is poor. Google recommends judging this at the 75th percentile of real visits, separately for mobile and desktop. That means three out of four of your visitors should see the main content within 2.5 seconds, not just you on office Wi-Fi.

The element that counts as "largest" can be an img element, a video poster image, an element with a CSS background image, or a big block of text. On most business home pages, it is the banner photo at the top. That is why one 3 MB photo from a phone camera can undo every other optimisation you have paid for.

The four parts of an LCP delay

web.dev's guide to optimising LCP splits the wait into four parts, and gives a rough ideal for how the time should be spread:

1. Time to first byte (TTFB), about 40 percent: how long your server takes to send the HTML.
2. Resource load delay, under 10 percent: the gap before the browser starts downloading the hero image.
3. Resource load duration, about 40 percent: how long the image takes to download.
4. Element render delay, under 10 percent: the gap between the image arriving and appearing on screen.

The guide's own summary is that most of the time should be spent loading the HTML and the LCP image, and little should be wasted elsewhere. This split explains why "compress the image" is only half the answer. If your load delay is large, the browser found the image late, perhaps because a slider script injects it or because someone marked it lazy. If your TTFB is large, the problem is the server, not the picture.

Layout shift

Images also affect Cumulative Layout Shift (CLS). web.dev's target is 0.1 or less at the 75th percentile, and anything above 0.25 is poor. A photo that loads without reserved space pushes the text below it downwards, which is exactly what CLS counts. We cover the layout side in a later section.

Interaction to Next Paint (INP) is mostly about JavaScript, so images are rarely the cause, although a heavy image slider script can be. For the wider picture on WordPress specifically, see our guide to WordPress Core Web Vitals optimisation.

Image formats: JPEG, WebP and AVIF

You will hear three names. Here is what MDN's image format guide and caniuse say about each, in plain terms.

JPEG

Universal support, good for photographs, and the safe fallback. Its weakness is that it is the least efficient of the three for the same visual quality.

WebP

MDN describes WebP as a good general-purpose choice, with broad support in Chrome, Edge, Firefox, Opera and Safari. It says WebP files are typically 25 to 35 percent smaller than JPEG at similar quality. Treat that as a typical range, not a promise: the saving on your photo depends on the photo. WebP supports transparency and animation and can render progressively.

AVIF

MDN says AVIF files are around 50 percent smaller than JPEG at the median, and that it supports transparency, HDR and wide colour gamuts. Two trade-offs matter to you. First, AVIF does not render progressively, so the browser must download the whole file before it can show it. Second, encoding is slower and fussier, so quality settings need a little more attention. For a hero image that is already small, that is fine. For a very large AVIF, the whole-file wait can erase the benefit.

On support, caniuse reported about 96 percent of global browser usage supporting AVIF as of September 2026 (read through a fetch summary, so verify on caniuse.com/avif if the exact number matters to you). It lists the first supporting versions as Chrome 85, Firefox 93, Safari 16.4 and Edge 121, with Internet Explorer and Opera Mini lacking it.

Which should you choose?

A sensible rule for a business owner: ask for WebP as the minimum and AVIF where the tooling supports it, with a JPEG fallback through the picture element or through a CDN that negotiates format automatically. Logos and icons should be SVG, and screenshots or line art can stay PNG or WebP. MDN's own advice for photos is WebP or AVIF with JPEG as the fallback.

Responsive images: srcset and sizes without the jargon

The format fixes the bytes per pixel. Responsive images fix the number of pixels. A phone that is 400 CSS pixels wide should not download a 2,400-pixel file.

MDN's responsive images guide explains the mechanism. The srcset attribute lists several versions of the same image with their real widths, such as hero-480.jpg 480w, hero-800.jpg 800w, hero-1200.jpg 1200w. The sizes attribute tells the browser how wide the image will be on screen at different viewport widths. The browser reads sizes, works out how many pixels it needs (also considering screen density), and picks the closest file in srcset that is large enough. If you leave sizes out, the browser assumes the image fills the whole viewport width, which makes it choose a larger file than needed for a narrow column.

What WordPress does for you

WordPress has generated multiple image sizes for each upload and added srcset markup automatically for years (this has been in core since 4.4, per my own knowledge; I did not re-verify the version for this article). Two more recent changes matter:

• WordPress 6.3 automatically adds fetchpriority="high" to the image it thinks is the LCP image. WordPress's own post says this typically improves LCP by 5 to 10 percent. The same release introduced one central function that decides the loading and fetchpriority attributes for images, and fixed cases where header images or images before the main post loop were wrongly lazy-loaded.
• WordPress 6.7 adds sizes="auto" to lazy-loaded images, so the browser uses the real rendered width when choosing a file. The Core post notes this works only when the image is also lazy-loaded, which is another reason the hero must be handled separately.

On formats, WordPress 5.8 added WebP upload support. WordPress 6.5 added AVIF upload support. In both cases your hosting needs an image library (Imagick or GD) that handles the format; you can check under Tools, Site Health, Info, Media Handling. Core can also generate AVIF versions on upload through a developer filter, with the original kept for later edits, and the default AVIF quality is 82. On multisite networks, AVIF must be enabled manually per site.

Core does not convert your old media library or shrink oversized originals, so a plugin, CDN or developer is still needed.

Width and height: the cheapest CLS fix

Write width and height on every image tag, matching the file's real proportions, and let CSS scale the image. The browser then reserves the right box before the file arrives. web.dev's lazy-loading guide says always to specify both attributes to prevent layout shift. WordPress adds them for images inserted through the editor, but images added through some page builders, custom HTML blocks or theme templates may lack them.

The CSS aspect-ratio property does the same job where attributes are impractical.

Lazy loading: use it everywhere except the hero

The loading="lazy" attribute tells the browser to delay an image until the visitor scrolls near it. web.dev's guide says browsers using it defer loading until a calculated distance from the viewport; on 4G Chrome uses 1,250 pixels, and 2,500 on slower connections. Support is broad: Chrome 77, Edge 79, Firefox 75 and Safari 15.4 onwards, and browsers that lack it simply ignore it.

The rule is simple.

• Below the fold: lazy-load. This cuts the data a visitor downloads on first view.
• The LCP or hero image: never lazy-load. web.dev's optimise-LCP guide is blunt: lazy-loading the LCP image always adds unnecessary load delay and hurts LCP.
• Other above-the-fold images, such as a logo: leave them eager (the default).

This is the most common mistake we see in audits because a "lazy load all images" setting in a speed plugin or theme is one click and looks like diligence. If your hero is lazy, switching that off for the first image is often the single biggest LCP win.

fetchpriority and discoverability

The browser scans the HTML early to find files to download. If the hero image appears there as a normal img element, it is found immediately. If it is injected by JavaScript, set as a CSS background in a stylesheet that loads late, or hidden in a slider's data attribute, it is found late, and your resource load delay grows.

Two fixes, both from web.dev:

1. Make the hero a real img element in the HTML where possible.
2. Add fetchpriority="high" to that one image so the browser requests it ahead of other images. The same guide warns that setting high priority on more than one or two images makes the signal unhelpful.

CDN and image resizing services

A content delivery network (CDN) stores copies of your files near visitors and can speed up the download part of LCP; web.dev lists CDNs and cache-control policies among ways to reduce load duration and edge servers among ways to cut TTFB. Many CDNs also offer image transformation (before agreeing to one, ask whether you keep your originals, how it performs from Indian networks, and what it costs; TODO: confirm current rates): you upload one good original and the service resizes it, converts it to WebP or AVIF depending on what the visitor's browser says it supports, and caches the result. This is useful when you have hundreds or thousands of images, such as a product catalogue or a property listing site.

If you run an online shop, the same ideas apply to product grids; our guide to store speed and Core Web Vitals for ecommerce in Pune goes through how catalogue pages behave differently from brochure pages.

A worked audit: from a slow hero to a faster one

The following is an illustrative walkthrough, not a real client result. The numbers are invented round figures chosen to show the method and are labelled as hypothetical. Do not read them as benchmarks.

Imagine a Pune interior-design studio's WordPress home page. The owner says it feels slow on mobile.

Step 1: Run PageSpeed Insights

Open pagespeed.web.dev, enter the home page URL and run the mobile test. Google's documentation explains that the top section, when available, is field data from the Chrome User Experience Report, based on a 28-day trailing period of real users, and falls back to the whole origin if the specific URL has too little data. The lab section underneath is a Lighthouse simulation of one device and network, so the two can differ. Look first at the field LCP: is it above 2.5 seconds at the 75th percentile? If a small site has no field data at all, treat the lab result as a guide only.

Suppose the lab report says LCP is 4.8 seconds and lists the LCP element as the hero banner image. The diagnostics point to "Improve image delivery" and "Largest Contentful Paint request discovery" style warnings. (Exact audit names change between Lighthouse versions, so read what your own report says.)

Step 2: Look at the LCP breakdown in Chrome DevTools

Open the page in Chrome, press F12, go to the Performance panel and record a page load. Chrome's tooling shows the LCP element and breaks the time into the same four parts web.dev describes. In our hypothetical, the breakdown shows a small TTFB, a very large load delay and a large load duration. That tells you two separate problems: the image is discovered late, and it is heavy.

Step 3: Inspect the markup

In the Elements panel, find the hero. You discover:

• It is a 3,200-pixel-wide JPEG of several MB, displayed 1,200 pixels wide on desktop.
• The tag has loading="lazy", added by an optimisation plugin.
• There is no fetchpriority and no srcset.
• The slider plugin builds the tag with JavaScript after load.

Step 4: Apply the fixes in order

1. Replace the slider's first slide with a plain image block in the template, or switch to a slider that outputs real HTML.
2. Remove lazy loading from that image (most plugins have an exclusion setting for the first image).
3. Resize to a sensible maximum, such as 1,600 pixels wide, and export WebP or AVIF versions plus a JPEG fallback at several widths.
4. Make sure srcset, sizes, width and height are present, and fetchpriority="high" appears only on that image.
5. Lazy-load everything below the fold, including the gallery.

Step 5: Re-test and compare

Run PageSpeed Insights again. Remember that field data takes a 28-day window to reflect changes, so judge the lab result at once and the field result a month later. Re-record the DevTools trace and see whether load delay and load duration shrank. If TTFB is now the largest part, the next problem is hosting or caching, not images. Our broader WordPress Core Web Vitals guide covers that stage.

Image optimisation for accessibility

Faster images should not cost clarity. Every meaningful image needs descriptive alt text, decorative ones should have empty alt, and text should never be baked into a banner image where screen readers and translation tools cannot read it. Over-compressed images can also make text in screenshots unreadable. Our article on accessibility and Core Web Vitals for a Pune designer covers where speed and accessibility help or hinder each other.

What to ask a website designer in Pune

A designer who understands image performance will answer these easily. A vague answer is information.

1. "Which image is the LCP element on my home page and on my top three pages?" They should be able to name it from PageSpeed Insights or DevTools.
2. "What formats will you deliver, and what is the fallback?" Expect WebP or AVIF with JPEG fallback, SVG for logos.
3. "How will you handle the hero image differently from the others?" The right answer mentions not lazy-loading it and setting fetchpriority.
4. "Do my images have width, height, srcset and sizes?" Ask them to show you the rendered HTML.
5. "How will future uploads stay optimised?" If staff upload 5 MB photos next month, the fix will undo itself unless there is an upload-time rule, a plugin or a CDN.
6. "What will you measure before and after, and when?" Look for field data over 28 days plus lab data on the day.
7. "Does my hosting support the formats?" Imagick or GD must handle WebP and AVIF.
8. "What does image work cost as a separate line?" Costs vary with the number of pages and images; see our website design cost guide for Pune for how to read quotes. A defensible range for a small site image audit and fix is TODO: confirm before quoting.

An image optimisation checklist you can hand over

On the site

• Photos are WebP or AVIF, with a JPEG fallback or automatic negotiation.
• Each image has width and height.
• srcset and sizes are present on content images.
• Hero image: real img element, not lazy, fetchpriority="high", not more than one or two high-priority images.
• Below-the-fold images: loading="lazy".
• No slider loads all slides at full size on first view.

Infrastructure

• Host supports Imagick or GD for WebP and AVIF (Tools, Site Health, Info, Media Handling).
• CDN or image service evaluated, with originals preserved.
• Cache-control headers are set for images.

Measurement

• PageSpeed Insights run on mobile for the top pages; field and lab noted separately.
• DevTools LCP breakdown recorded before and after.
• Re-check field data after 28 days.

Working with Govindani Infotech

Govindani Infotech is a website design and development company at 2nd Floor, Landmark Plaza, 206 Satara Road, Parvati Paytha, Pune 411009. We build WordPress and custom sites for businesses and for non-profits. If your pages feel slow, we can review your top pages in PageSpeed Insights and DevTools, tell you which image is your LCP element, and list what to change, in plain language, before anyone proposes a rebuild.

If you are planning a new site, our website creation service includes image handling as part of the build rather than as an afterthought, and for shops our ecommerce service deals with product-image volume. To start, contact us or message us on WhatsApp with your site's address and the page you most want faster.

Frequently Asked Questions

What is a good LCP score for my business website?

Per web.dev, a good LCP is 2.5 seconds or less, and over 4.0 seconds is poor, measured at the 75th percentile of real visits and separately for mobile and desktop. Check PageSpeed Insights field data first, because that reflects real users.

Should I use WebP or AVIF for my WordPress site?

WebP is the safer default, with broad support and typical savings of 25 to 35 percent over JPEG according to MDN. AVIF can be smaller, about half the size of JPEG at the median, but it does not render progressively and needs a fallback. WordPress supports WebP uploads from 5.8 and AVIF uploads from 6.5, provided the server image library supports them.

Should I lazy-load every image on my site?

No. Lazy-load images below the fold, but never the hero or other LCP image, because web.dev says that always adds unnecessary load delay. Set fetchpriority="high" on that one image instead.

Does WordPress optimise my images automatically?

Partly. Core creates multiple sizes with srcset, adds fetchpriority to the likely LCP image from 6.3, and adds sizes="auto" for lazy-loaded images from 6.7. It does not shrink your original uploads or convert your existing library, so you still need an optimisation plugin, a CDN or a developer.

How long before improvements show up in PageSpeed Insights?

The lab result changes at once when you re-run the test. Field data from the Chrome User Experience Report covers a 28-day trailing period, so give it about a month before judging the real-user effect.

Sources:

• https://web.dev/articles/lcp
• https://web.dev/articles/cls
• https://web.dev/articles/optimize-lcp
• https://web.dev/articles/browser-level-image-lazy-loading
• https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/Image_types
• https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Responsive_images
• https://make.wordpress.org/core/2023/07/13/image-performance-enhancements-in-wordpress-6-3/
• https://make.wordpress.org/core/2024/10/18/auto-sizes-for-lazy-loaded-images-in-wordpress-6-7/
• https://make.wordpress.org/core/2024/02/23/wordpress-6-5-adds-avif-support/
• https://make.wordpress.org/core/2021/06/07/wordpress-5-8-adds-webp-support/
• https://developers.google.com/speed/docs/insights/v5/about
• https://caniuse.com/avif