Top 10 website performance tips for small business owners

Compress image files

Large images are the single biggest cause of slow websites for small businesses. A single unoptimised photograph can be 4–8 MB; serve it on a slow mobile connection and you've added 4–6 seconds to page load time.

Use an online tool like TinyPNG, ImageOptim, or Squoosh to reduce file size by 50–80% without visible loss of quality. JPEGs work best for photos; PNGs for graphics with solid colours. WebP format is newer and smaller still, but not all browsers supported it until recently—check your audience.

If you're editing a site yourself, do this before uploading. If a designer built your site, ask them to serve images via a content delivery network (CDN) with automatic compression. Most modern hosts, including Vercel, do this by default.

Defer non-critical JavaScript

Every line of JavaScript you load slows down your site—not just at download time, but while it runs. Third-party scripts (analytics, chat widgets, consent banners, tracking pixels) often arrive before your page is usable.

Set them to load only after the page is interactive. Most analytics platforms (Google Analytics, Plausible) support deferred loading via a simple code flag. Chat widgets can wait 3–5 seconds. Ad networks and tracking pixels rarely affect the user experience if delayed by a few seconds, but they can shave 1–2 seconds off your Time to Interactive if you don't load them immediately.

This is especially important on slower mobile devices, where JavaScript execution time (not just download time) becomes a bottleneck.

Identify and audit third-party script overhead

It's hard to know which scripts are actually hurting performance without looking. Open your site in Chrome DevTools (F12 → Network tab), reload the page, and sort by file size or time. Look for anything from a domain you didn't write.

Google Analytics, Intercom, Zendesk, Drift, Typeform, and similar tools are common culprits. A single chat widget can add 200–500 KB and 1–2 seconds to load time. Ask yourself: do I need this widget on every page, or only on contact pages?

This is where most guides go vague—they tell you "audit your scripts" but don't say how. The concrete answer: if a script is over 100 KB or takes longer than 500 ms to load, consider whether you can remove it, defer it, or replace it with something lighter. Document the trade-off. Removing a chat widget saves 2 seconds but costs you live support.

Set a performance budget for your site type

"Fast is good" doesn't give you a target. Real guidance depends on what you're selling.

A small e-commerce site (10–50 products) should aim for a Lighthouse score of 85+ on mobile and a Time to First Byte under 1 second—customers abandon slow checkout flows. A service-business site (plumber, accountant, coach) can afford 75–80 because visitors are less price-sensitive; they're there to verify you exist and book a call. A blog or content site can sit at 70+ because readers are patient, but faster still means more traffic from Google.

Most design agencies ignore this. They'll build a site with Lighthouse 85 and call it done, whether you're a dentist or a Shopify merchant. Slower devices and slower networks—common in rural areas and on 4G—make a bigger difference than you'd think. A visitor on a cheap Android phone over 4G will experience the same Lighthouse 75 site as 3–4 seconds slower than a desktop user on broadband.

Replace or optimise slow database queries

This only matters if you're running a dynamic site (a blog with thousands of posts, a membership site, a SaaS app). If you're on WordPress or another CMS and posts take 2+ seconds to load, the problem is almost never images or JavaScript—it's the database.

Ask your hosting provider or developer to run a database query log and look for queries that take longer than 100–200 ms. Common culprits: fetching related posts without indexes, "N+1" queries (one query per item in a loop instead of one query for all items), or missing database indexes on sorting fields.

Fixing this often takes one afternoon and saves 1–2 seconds per page. Most small-business owners don't know this is possible because their web host doesn't expose query logs, and generalist guides assume "performance" means images and scripts.

Sitewright

Sitewright builds small-business sites on Next.js and Tailwind with performance built in. Every site launches with a Lighthouse score of 90+ on mobile out of the box.

• Hand-written Next.js and TypeScript code → No bloated page-builder overhead
• Global CDN and auto-compression on all assets → Images and CSS served fast from the edge
• Deferred third-party script loading → Analytics and tools don't slow down page render
• Strapi CMS with database indexing pre-configured → Fast content queries on larger sites
• 30-day post-launch optimisation → Broken images, missing meta-tags, and crawl errors fixed free

Most small-business sites from template builders ship with Lighthouse 50–65. Sitewright's process assumes performance is non-negotiable.

Minimise render-blocking CSS

When your page loads, the browser must download and parse your CSS before it can display anything. If your CSS file is 100 KB (common in sites built with template builders), that's 1–2 seconds wasted.

Split your CSS: keep only the styles needed for the "above the fold" content inline in the HTML header. Load the rest asynchronously. This cuts the time to First Contentful Paint by 0.5–1 second on slower connections.

If you use Tailwind CSS or similar utility frameworks, the opposite applies—your CSS is already tiny (often 10–20 KB) because you're only including the styles you use. This is one reason why hand-written modern CSS frameworks outperform older templating systems.

Lazy-load images and non-critical content

Images that appear below the fold (content users have to scroll to see) should not load until the user scrolls near them. This saves bandwidth on mobile and speeds up initial page load.

Most modern web frameworks do this automatically. WordPress plugins like Lazy Load by WP Rocket do it for you. The trade-off: aggressive lazy-loading can hurt SEO if you load images too late—search engines may not see them. Set your lazy-load threshold to start loading 500–1000 pixels before the image comes into view, not when the user scrolls to it.

For hero images and important product photos, don't lazy-load them at all. Only lazy-load gallery images, testimonial photos, and content that's nice-to-have but not essential for conversion.

Choose a host with edge caching and global CDN

The physical distance between your server and your visitor matters. A server in London serving a customer in Sydney adds 150–200 ms of latency before the first byte of data even arrives.

A global CDN (content delivery network) copies your site's static files—images, CSS, JavaScript—to servers around the world. Requests are routed to the nearest edge location. Vercel, Cloudflare Pages, and Netlify all do this. Shared hosting (GoDaddy, Hostinger) usually does not.

If your customers are mostly in one geography, this is less critical. If you're a UK business but have clients in Australia or the US, a CDN saves 1–2 seconds for non-local visitors. The cost is negligible for most small sites (£0–20/month). It's worth it if you're targeting international customers.

Measure performance in real-world conditions

Lighthouse (the tool built into Chrome) is useful but incomplete. It tests your site on a simulated slow 4G connection and a mid-range Android phone. Real customers on real networks are even slower.

Use Google's Core Web Vitals report (in Google Search Console) to see how actual visitors experience your site, broken down by device type and geography. If your Lighthouse score is 85 but real mobile visitors see a 3-second First Contentful Paint, something on your real network (ISP throttling, third-party CDN lag, geo-specific DNS) is slower than the simulation.

Set up Google Analytics 4 for performance tracking if you want the numbers. Most small businesses skip this step and assume Lighthouse score = real-world speed. That's where 90% of optimisation efforts go to waste.

Picking the right one

Website performance tips sound abstract until you need to implement them. The real challenge isn't knowing what to do—it's knowing where to start and whether the time investment is worth the outcome.

If you're building a new site, the simplest move is to choose a host and framework that handles performance by default. Sitewright builds every site with a 90+ Lighthouse score, performance budgets per page, and automated image compression and caching. You're not choosing performance later; it's baked in from day one. No performance audits needed; no mystery "why is this slow?" questions after launch.

• Avoid performance rework: fix it during the build, not after launch
• Understand real-world impact: measure Core Web Vitals, not just Lighthouse scores
• Know your trade-offs: faster CDN = monthly cost; lazy-loading images = SEO risk; deferring scripts = delayed analytics
• Prioritise by site type: e-commerce needs speed more than a blog does
• Set a budget early: "we want Lighthouse 85 on mobile" is actionable; "make it fast" is not

If your site is already live and slow, start with image compression and third-party script audit—both take an afternoon and often cut load times by 30–50% with no development cost.