Performance Lessons from Small Brighton Websites

Small websites are not automatically fast.

That sounds obvious, but it is still a common assumption. A business has only five pages, a few images, and no complicated application logic, so everyone assumes performance will take care of itself. Then the homepage ships with a huge hero image, three font families, a booking widget, a map embed, analytics, social scripts, a chat tool nobody answers, and a theme that loads half a page builder before rendering the first useful sentence.

Small websites can be slow for very ordinary reasons.

Brighton has plenty of independent restaurants, studios, trades, clinics, shops, venues, and professional services where the website does not need to be technically dramatic. It needs to be fast, clear, current, and useful. That is a different kind of discipline.

Start with the Customer Situation

Performance work should start with the visitor's real situation, not the owner's office Wi‑Fi.

For a local business, the visitor may be on a phone, outside, comparing two nearby options, and looking for one thing: opening hours, a menu, a phone number, directions, availability, or a quick answer.

That is not the same as somebody sitting at a desk on fibre broadband comparing enterprise software.

For a small Brighton website, I would usually care most about:

• how quickly the page becomes readable
• whether the main action is obvious
• whether opening hours and contact details appear quickly
• whether layout jumps around while the page loads
• whether third‑party scripts delay the page
• whether the site still works on a weak mobile connection

Lighthouse scores can be useful, but the real question is simpler: can the customer get what they came for without waiting or fighting the page?

Image Weight is Usually the First Problem

Independent businesses need good photography. Food, interiors, products, people, views, events, rooms, and work examples all matter.

The problem is not using images. The problem is sending images that are far larger than the page needs.

Common issues include:

• uploading camera originals straight into the CMS
• using the same large image for mobile and desktop
• missing width and height attributes, causing avoidable layout shift
• loading below‑the‑fold images immediately
• exporting images at poor quality settings
• using PNG for photographic images where JPEG, WebP, or AVIF would be more appropriate
• cropping through CSS rather than generating sensible image sizes

Good image handling is one of the highest‑value performance fixes on small sites. It also tends to be easy to explain to clients because they can see the difference.

The aim is not to make the site ugly. It is to make sure photography supports the page instead of punishing it. The usual fix is not complicated: generate sensible sizes, use responsive image markup, reserve image dimensions, compress properly, and avoid loading non‑critical images before they are needed.

Third‑Party Scripts Need a Reason to Exist

Small business websites often collect third‑party scripts quietly.

One script is added for analytics. Another for a booking form. Another for maps. Another for social proof. Another for a newsletter popup. Another came with the theme. Nobody remembers what two of them do, but nobody wants to remove them in case something breaks.

Each script may be defensible on its own. Together, they can make a small site feel heavy.

I like to ask:

• What does this script do?
• Who owns the data or feature it provides?
• Does it need to load on every page?
• Can it load after the main content?
• Is there a lighter alternative?
• Does the business still use the service?

A script that nobody uses is not neutral. It still costs the visitor time, battery, privacy, and attention.

Hosting Still Matters

Performance is not only front‑end code.

A small site on slow shared hosting can feel worse than a more complex site on a decent platform. Time to first byte matters because a slow initial response delays everything that follows. If the first response is slow, everything else starts late.

This is especially visible on WordPress sites that have accumulated plugins, old themes, and database work that runs on every request.

Improving hosting is not always the first fix, but it belongs in the conversation. So do caching, CDN configuration, image delivery, PHP versions, database health, and whether the site is doing server work it no longer needs.

Sometimes the cheapest host is fine. Sometimes it is expensive in every way except the invoice.

Page Builders Can Hide a Lot of Cost

Page builders can be useful. They let non‑technical people assemble pages quickly, and for some businesses that trade‑off is worth it.

The difficulty is that page builders can also ship a lot of markup, CSS, JavaScript, and layout complexity for simple content.

That becomes a problem when:

• every page loads the same large asset bundle
• unused components still contribute CSS or JavaScript
• headings are chosen for visual size rather than structure
• content order does not match the visual page
• mobile layouts rely on duplicated content blocks
• editors solve spacing by adding empty elements

The issue is not the existence of page builders, or that all page builders are bad. The issue is that convenience has a technical cost, and somebody needs to notice when the cost is no longer proportionate.

The Fastest Page is Often the Clearest Page

Bloated pages are often unclear pages.

A page with one clear job usually needs less furniture. A page trying to explain everything at once tends to grow heavy: more sections, more images, more icons, more carousels, more scripts, and more calls to action competing with each other.

For small local websites, the most useful performance question can be:

"What can we remove?"

Remove the carousel that hides the important information. Remove the map from every page and keep it where directions actually matter. Remove the social feed that slows the homepage and duplicates content. Remove the giant banner that says nothing. Remove the plugin that only existed for one campaign two years ago.

Good editing is performance work.

Mobile is the Main Test

It is easy to test a website on a good laptop and miss the problem.

Many local customers arrive on mobile. That means smaller screens, weaker connections, slower processors, browser UI taking up space, and more impatience. The page has to earn attention quickly.

On mobile, I check:

• whether the first screen tells me where I am
• whether the main action is visible without hunting
• whether text is readable without zooming
• whether navigation is obvious
• whether the page jumps while loading
• whether tap targets are comfortable
• whether images crop important detail
• whether sticky elements block content

If the phone number, booking action, or opening hours are hard to reach on mobile, the page is failing at the point of highest intent.

Measure Before Changing Everything

Performance work can become guesswork if nobody measures the page first. I would usually start with the obvious checks: field data where available, a Lighthouse run, the browser network panel, image transfer sizes, third‑party requests, and a real mobile test. The point is not to chase a perfect score. It is to find the few changes that will make the page meaningfully faster for real users.

Performance Fixes Should Be Maintainable

A one‑off performance rescue is useful, but the better goal is to stop the same problems from returning.

That means leaving behind a system the business can actually follow:

• image guidance for future uploads
• CMS fields with sensible limits
• reusable page patterns
• fewer plugins
• documented third‑party scripts
• simple hosting and cache notes
• a performance check before major content changes

Small businesses do not need a heavyweight engineering process. They need guardrails: image limits, fewer unchecked plugins, known script owners, and a simple review before major page changes.

Wrapping Up

The best performance lessons from small Brighton websites are not exotic.

The work is usually practical: reduce image waste, remove scripts that no longer earn their keep, make the first screen useful, test on real mobile conditions, and leave the business with habits that stop the site getting heavier after launch.

Small websites deserve performance care precisely because their users are often trying to do something simple.

Key Takeaways

• Small websites can still be slow because of images, scripts, hosting, themes, and unclear content.
• Local visitors often need quick answers on mobile, not a heavy visual showcase.
• Image optimisation is usually one of the best first fixes.
• Third‑party scripts should have a clear owner and purpose.
• Good content editing can reduce page weight and improve conversion.
• Performance improvements should be easy for the business to preserve after launch.