Okay so this started as a mildly procrastinatory rabbit hole and turned into something I think is actually worth writing up properly. I was bored one evening, opened dev tools on a local bakery's site I'd ordered from, and just... kept going. Twenty sites later, mostly small businesses around Punjab, salons, clinics, a couple of consultancies, a furniture shop, I noticed the exact same root issue showing up in roughly 17 out of 20 of them. Not a design issue. A code issue. And it's one that's genuinely easy to fix once you know to look for it, which is what bugs me most about it.
The pattern: unoptimized, uncompressed images being served at full resolution regardless of viewport, with zero lazy loading, and in a few cases, the same hero image being loaded twice because of a CSS background-image declaration stacked on top of an actual tag doing the same job. One site was loading a 4.2MB PNG as a hero banner. On mobile. Over what was, in my test, a throttled 4G connection. That's not a minor inefficiency, that's borderline hostile to anyone not on fiber.
Why This Keeps Happening
My theory, having poked around enough of these codebases, is that most of these sites were built fast, by freelancers or small agencies working off a fixed quote, optimizing for "client approves design in the demo" rather than "site performs well in production six months later." Nobody's malicious here, I want to be clear. It's just that image optimization is the kind of thing that's invisible in a quick screen-share demo and very visible in a Lighthouse audit, and clients rarely ask for the latter.
<!-- what I found, repeatedly -->
<div style="background-image: url('hero-banner-full-res.png')">
<img src="hero-banner-full-res.png" alt="">
</div>
Two requests for the same asset, no srcset, no responsive sizing, empty alt text on top of it which is its own accessibility and SEO problem. I'm not picking on any specific dev here, this exact pattern showed up across sites clearly built by different people, which tells me it's systemic rather than one bad freelancer's habit.
The Fix Isn't Hard, Which Is the Annoying Part
This is genuinely a few hours of work, not a rebuild. Proper srcset with multiple resolutions, WebP with a fallback, lazy loading via the native loading="lazy" attribute which has decent support now and doesn't even require a JS library for the basic case anymore:
<img
src="hero-banner-800.webp"
srcset="hero-banner-400.webp 400w, hero-banner-800.webp 800w, hero-banner-1200.webp 1200w"
sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
loading="lazy"
alt="Custom furniture showroom interior in Ludhiana"
/>
That one change alone, across the sites where I actually got to test before/after on a real deploy, dropped Largest Contentful Paint by anywhere from 1.5 to nearly 4 seconds depending on how bad the original asset was. For context, Google's own Core Web Vitals guidance treats anything over 2.5 seconds LCP as needing improvement, and several of these sites were sitting at 6+ seconds. That's not a borderline case. That's a site actively working against itself.
The Second Pattern: No Structured Data, Anywhere
This one's less about performance and more about missed opportunity. Of the 20 sites, exactly 3 had any JSON-LD structured data at all. Not "good" structured data, just any. No LocalBusiness, no Organization, nothing telling Google explicitly what kind of business this is, where it's located, what hours it operates. Which means these businesses are relying entirely on Google's text-parsing inference to figure out what they are, instead of just telling it directly in a format it explicitly prefers.
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "[Business Name]",
"address": {
"@type": "PostalAddress",
"addressLocality": "Ludhiana",
"addressRegion": "Punjab",
"addressCountry": "IN"
},
"openingHoursSpecification": {
"@type": "OpeningHoursSpecification",
"dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"],
"opens": "09:30",
"closes": "18:30"
}
}
This isn't complicated to add and yet almost nobody bothers, probably because it produces no visible change in the browser, so it's easy to deprioritize when you're racing toward a launch deadline. It's the kind of thing that pays off slowly and invisibly, which makes it exactly the kind of thing that gets skipped under time pressure.
Why I'm Writing This Up Here Specifically
I think there's a slightly underappreciated gap between how dev-focused communities talk about performance, Lighthouse scores, Core Web Vitals, bundle sizes, all the stuff we obsess over for our own side projects and how that knowledge actually trickles down to the small business sites that make up a huge chunk of the actual web. Plenty of small business owners hire whoever's cheapest or most available locally, get a site that looks fine in a demo, and have genuinely no way of knowing whether the underlying code is solid or held together with duct tape, because they're not developers and shouldn't be expected to check.
If you're a dev who occasionally takes on small business client work, or you know someone who does, this is worth treating as a checklist rather than an afterthought: image optimization, basic structured data, an actual mobile-first responsive approach rather than a shrunk desktop layout, and a quick Lighthouse pass before calling anything "done." None of this is advanced. It's just consistently skipped, and the businesses paying for these sites have no way of catching it themselves.
The Third Pattern: Nobody's Actually Touched These Sites Post-Launch
This one's less a code smell and more something you can infer from git-blame-style archaeology, except most of these sites don't even have proper version control, just FTP'd files sitting on a server somewhere. Looking at last-modified timestamps on assets and reading through commented-out code that clearly belonged to an earlier iteration of the design, it's pretty obvious most of these sites got built once and then never touched again. No dependency updates, no revisiting the Lighthouse score after launch, nothing.
This tracks with something I've heard repeated by people doing actual SEO services in Ludhiana work seriously: a huge percentage of small business sites in this market get treated as one-time deliverables rather than living assets that need periodic technical attention. Which makes sense from a freelancer's incentive structure, you get paid once for the build, there's no ongoing retainer pulling you back to revisit performance regressions or accumulating cruft. But it does mean a meaningful chunk of small business sites are quietly decaying, performance-wise, just from accumulated neglect rather than any single dramatic failure.
Why I Think This Is an Industry-Wide Blind Spot, Not Just a Local One
I want to be careful not to make this sound like it's uniquely a Punjab thing or an India thing, because I genuinely don't think it is. I think this is just what happens anywhere small business web development gets commoditized into fixed-price, fast-turnaround projects without a feedback loop built in. The closest analogy I can think of is contractors who'll build you a house that looks great on handover day but cut corners on the wiring because nobody's going to open the walls and check for another decade.
That said, this is exactly the gap that good website designing company in Ludhiana outfits who actually care about retention and reputation tend to close, because repeat business and referrals depend on the site still working well a year or two later, not just looking polished at handover. The economics shift when a business depends on long-term client relationships instead of one-off project fees, and you can usually tell the difference just by reading the markup, honestly, without ever meeting the team that built it.
For what it's worth, the better-performing sites in my sample of 20, the 3 with structured data, faster load times, and the works, tended to be the ones built by teams that clearly treated this as ongoing technical work rather than a one-time design delivery. A few were built by a Ludhiana-based outfit, Mittal Technologies, and the difference in how those sites were structured under the hood versus the rest of the sample was honestly pretty noticeable once you started actually reading the markup instead of just looking at the rendered page.
If you're building for small business clients, or you're a small business owner trying to evaluate whether your own dev did right by you, treat the stuff that's invisible in a demo with at least as much seriousness as the stuff that gets applause in one. The applause fades. The Lighthouse score doesn't lie to anyone six months later.
Top comments (0)