Why website speed matters more than design

The relationship between website speed and SEO is direct and measurable, but most Baku businesses still treat speed as a technical concern the developer handles "if there's time." That ordering is wrong. A beautifully designed site that takes 5.4 seconds to render on a mid-range Android phone loses to a plain site that renders in 1.8. The customer doesn't know why — they just don't wait.

What "slow" actually means

"The site is slow" is a feeling. To do anything useful with it, you need numbers. Google formalised three of them under the Core Web Vitals banner, and they're the ones search ranking actually uses.

LCP — Largest Contentful Paint

How long until the largest visible thing — usually the hero image or headline — finishes drawing. Target: under 2.5 seconds on mobile. Above 4.0 seconds is a failing grade and a ranking penalty.

INP — Interaction to Next Paint

How long the page takes to respond when the user taps or clicks. Target: under 200 milliseconds. This replaced FID in March 2024 and is more honest about real interactivity.

CLS — Cumulative Layout Shift

How much the page jumps around as it loads. Target: under 0.1. Ads inserting late, fonts swapping, images without dimensions — all cause CLS, and all annoy users.

Google measures these three in real-world conditions via the Chrome User Experience Report, not via Lighthouse synthetic tests. Lighthouse is useful for development; CrUX is what ranking is based on.

The revenue arithmetic

The studies on this aren't speculative.

Akamai found a 100-millisecond load time delay reduces conversion rate by 7%.
Google's own analysis shows that as page load time goes from 1 to 5 seconds, bounce probability increases by 90%.
Walmart published that every 1-second improvement in their page load time corresponded to a 2% conversion rate uplift.
BBC reported losing an additional 10% of users for every additional second of load time.

Apply this to a typical Baku e-commerce site. 30,000 monthly visitors, 2% conversion rate, average order 80 AZN. That's 30,000 × 0.02 × 80 = 48,000 AZN/month in revenue. If the site is currently taking 4.2 seconds to LCP and you bring it to 1.8 — roughly a 2.4-second improvement — you should expect a 15–25% conversion rate lift, somewhere in the 7,000–12,000 AZN/month range. The site work to get there costs perhaps 3,000 AZN, one-off.

That math is why Lighthouse score conversations belong in business meetings, not just developer ones.

Where the time actually goes

For a typical mid-tier Baku marketing site that scores 35–55 on Lighthouse mobile, the time budget breaks down roughly:

900–1,800 ms downloading uncompressed images that are 4× larger than they need to be.
600–1,200 ms blocked rendering on third-party scripts — Facebook Pixel, Google Tag Manager, chat widgets, multiple analytics, a few CRM integrations.
500–1,000 ms hydrating JavaScript that does almost nothing visible to the user.
200–600 ms font loading swap, causing CLS in the process.
200–500 ms server response time on a slow shared host.

Note what's not in that list: the design. Design adds almost nothing to the timing budget if it's executed correctly. A well-designed site can be fast; a badly-engineered site is always slow regardless of how it looks.

The fixes, in order of leverage

1. Images

Biggest single win. Convert all images to WebP or AVIF. Specify width and height attributes on every <img> tag to prevent CLS. Use loading="lazy" on below-the-fold images and fetchpriority="high" on the hero. Serve responsive sizes via srcset so a phone doesn't download a 2400px-wide image.

Typical impact: 1,000–1,500ms off LCP. Single biggest lever.

2. Fonts

Preload the one or two critical font files. Use font-display: swap. Self-host instead of pulling from Google Fonts (which adds a third-party round trip). Subset the font to only the glyphs you actually use — for an Azerbaijani site, you need Extended Latin, you don't need Cyrillic-Ext-A.

3. Third-party scripts

This is the unsexy one. Most Baku sites carry 4–7 analytics and tracking scripts they don't need. Audit them: any script not actively used in the last 30 days gets removed. The remaining ones get loaded with async or defer, and Google Tag Manager (if used) gets configured to fire heavier tags after page load.

4. JavaScript budget

If the site is on Next.js or a React-heavy stack and ships 200KB+ of JS to render an essentially static marketing page, the framework is the problem. For a marketing site, ship as close to zero JS as possible — that's the Astro argument, but the same logic applies to Eleventy, Hugo, or even a well-engineered Next.js static export.

5. Hosting and CDN

A 350ms TTFB from a shared Baku host becomes 80ms from a Cloudflare-fronted setup. The work is half a day; the gain is permanent.

Lighthouse score — honest targets

You don't need 100/100. You need:

Mobile Performance: 85+ for marketing sites, 75+ for e-commerce, 65+ for sites with heavy interactive components.
LCP under 2.5 seconds on a 4G connection.
CLS under 0.1 always.
INP under 200 ms always.

Below those numbers, you're losing customers. At those numbers, you're competitive. Going from 85 to 98 is engineering vanity — real for some sites, irrelevant for most.

The design-vs-speed false choice

Design and speed aren't opposed. They're opposed only when design is being executed badly — when "design" means "stack lots of heavy hero images and animation libraries." Real design is constraint-aware. Hero images can be fast. Animations can be cheap if they're done on the compositor. A bespoke site can ship in 25 KB of JavaScript if the people building it care about that.

A site that's beautiful and fast is also possible. A site that's beautiful and slow is a developer choice masquerading as a designer choice.

At Qaynaq, every site we ship has a written performance budget — LCP target, CLS target, JS bundle ceiling — agreed before design begins. If you want a Lighthouse audit on an existing site, with a prioritised fix list and an estimated revenue uplift, write to salam@qaynaq.com with the domain.