Frontend Development Best Practices for Business Websites

Most frontend advice is written for developers and argues about frameworks. This is written for the business paying for the site, and covers the decisions that actually change whether it converts, ranks and survives contact with its next developer.

Semantic HTML first

A page built from generic <div> elements works visually and fails at everything else. Use <header>, <nav>, <main>, <article>, <section> and <footer> for what they mean.

Three concrete consequences: search engines understand your page structure, screen readers can navigate it, and browsers give you keyboard behaviour and focus handling for free. A real <button> is focusable, activates on Enter and Space, and announces itself correctly. A <div onclick> does none of that until someone writes twenty lines to reimplement it, usually incompletely.

One H1 per page, describing that page. Headings in order — H2 under H1, H3 under H2 — because they form an outline, not a set of font sizes.

Mobile-first, tested on real devices

Most of your traffic is mobile. Design and build for the small screen first and expand upward, because the reverse means cramming a desktop layout into a phone and hoping.

Resizing a desktop browser window is not testing on mobile. It does not reproduce touch targets, actual device performance, the on-screen keyboard covering your form, or how iOS Safari handles viewport height. Test on a real phone, preferably a mid-range Android rather than the newest iPhone.

Test at 320px wide. It is the narrowest you are likely to encounter, and it surfaces layout problems everything else hides.

Set a performance budget

Without a number, page weight only ever grows. Someone adds a chat widget, someone adds a tracking script, and a year later the site is three times heavier and nobody can point to when it happened.

Reasonable starting budget for a business site: under 1 MB total, under 300 KB of JavaScript, LCP under 2.5s on a mid-range phone on 4G. Then hold to it — when something new needs to be added, something else justifies its place or goes.

The recurring offenders are unoptimised images, third-party scripts, and font files. Marketing tools are the usual culprit: five tracking scripts, each individually justified, collectively ruining the experience for everyone.

Accessibility, for commercial reasons

Set aside the ethics for a moment, because the business case stands on its own. Accessibility is a legal requirement in a growing number of markets, it overlaps almost completely with SEO best practice, and the fixes are cheap when built in and expensive when retrofitted.

The parts that matter most:

• Keyboard navigation. Tab through your whole site. If you cannot reach and operate everything, neither can a significant group of users.
• Visible focus states. Never remove the focus outline because it looks untidy. Restyle it instead.
• Colour contrast. 4.5:1 for body text. Light grey on white fails, and it fails for everyone in bright sunlight, not only people with low vision.
• Labelled form fields. A real <label>, not placeholder text — placeholders vanish the moment someone starts typing.
• Meaningful alt text. Describe the content. Decorative images take an empty alt="" so screen readers skip them.

Components that stay small

A component that has grown a dozen boolean props and three special cases is one everybody copies instead of reuses. That is how a codebase ends up with four button implementations.

Keep components focused. When one starts sprouting flags to handle unrelated cases, that is the signal to split it. Name things for what they are, not what they look like — PrimaryButton survives a rebrand; BlueButton becomes a lie the moment the brand colour changes.

Forms that actually work

Your contact form is usually the most commercially important element on the site, and routinely the least tested.

• Use the right input types — type="email", type="tel" — so phones show the right keyboard.
• Set autocomplete attributes so browsers can fill fields.
• Validate on submit, not aggressively on every keystroke.
• Put error messages next to the field, describing the fix.
• Disable the submit button while sending, and confirm clearly when it succeeds.
• Test the failure path. What the user sees when the request fails matters more than the happy path, because that is when you are about to lose the enquiry.

A related point: a JavaScript error early in a script file stops everything after it from running. On this site, an unguarded element lookup meant the contact form handler never registered on the contact page — the form looked fine and did nothing. Test the actual submission on the actual page, not just the one you built it on.

Handover that holds up

The measure of a good handover is that the next developer does not need to ask you anything.

• Conventional patterns over clever abstractions. Clever costs someone a day in six months.
• Comments that explain why, not what. The code already says what.
• A readable commit history.
• A README that covers running it locally and deploying it.
• Documentation for anything non-obvious — especially the workarounds, which look like mistakes to anyone without the context.

What this adds up to

None of this is exotic. Semantic markup, real-device testing, a weight budget, keyboard access, small components, forms that fail gracefully, and a handover somebody can pick up. It is the difference between a site that works and one that merely looks like it does.

If you want this applied to an existing build or a new one, that is what the frontend development page covers.