Modern JavaScript Practices for Small Business Websites in 2026

Most small business sites don’t need more JavaScript. They need less of it, loaded more carefully. After a decade of building sites for local companies (I’m based in Commack and do a lot of Long Island web design), I’ve watched the same pattern repeat: a site gets rebuilt on a heavy framework, loads like molasses on a phone, and the owner has no idea why. This is what I actually do instead, and the code behind it.

Start by measuring, not guessing

Before you change a line of code, get a baseline. Chrome DevTools, the Lighthouse panel, and WebPageTest are all free. The numbers I care about in 2026:

• INP (Interaction to Next Paint) replaced FID as a Core Web Vital in 2024. Your site is graded on it now.
• LCP (Largest Contentful Paint) should be under 2.5 seconds on a mid-tier phone, not your laptop.
• Total blocking time tells you how much your scripts are freezing the main thread.

Run the test on a throttled connection with a 4x CPU slowdown. If your laptop on office wifi is your only test, you’re measuring the wrong thing.

Load scripts the way the browser wants

The single most common mistake I see: a pile of <script> tags in the <head> with no attributes. That blocks rendering until every file downloads. Two attributes fix most of it.

<!-- Defer: downloads in parallel, runs after HTML is parsed, keeps order -->
<script src="/js/site.js" defer></script>

<!-- Async: downloads in parallel, runs the moment it's ready, order not guaranteed -->
<script src="/js/analytics.js" async></script>

Use defer for anything that touches the DOM or depends on other scripts. Use async for independent stuff like analytics or a chat widget. Never leave a bare <script> in the head unless you have a specific reason.

Only ship what the page uses

Modern bundlers can split code per route. If your homepage doesn’t need the contact form’s validation library, don’t send it. With a bundler like Vite or esbuild, dynamic imports handle this:

// Load the heavy map library only when the user scrolls to it
const mapContainer = document.querySelector('#map');

const observer = new IntersectionObserver(async (entries) => {
 if (!entries[0].isIntersecting) return;
 observer.disconnect();
 const { initMap } = await import('./map.js');
 initMap(mapContainer);
});

observer.observe(mapContainer);

That’s a real pattern I use on service-area pages. The map loads when someone actually looks at it, not on page load.

Stop reaching for a framework by default

If your site is a handful of mostly static pages with a contact form, you probably don’t need React. You need HTML, a bit of CSS, and maybe 20 lines of JavaScript. A framework adds a build step, a dependency tree, and a runtime cost that a five-page site will never earn back.

Where frameworks genuinely earn their keep: dashboards, real-time data, complex forms with lots of state, and anything where the UI changes constantly. Everywhere else, ship less.

If you do need interactivity without a build step, the platform itself has caught up. Here’s a small component with plain web components:

class QuoteForm extends HTMLElement {
 connectedCallback() {
 this.innerHTML = `
 <form>
 <input name="email" type="email" required>
 <button type="submit">Get a quote</button>
 </form>`;
 this.querySelector('form').addEventListener('submit', (e) => {
 e.preventDefault();
 // handle submission
 });
 }
}
customElements.define('quote-form', QuoteForm);

No framework, no npm install, works in every current browser.

The accessibility stuff that’s also good JavaScript

Accessibility and performance overlap more than people think. A few things I check on every build:

• Interactive elements are real <button> or <a> tags, not clickable <div>s. Keyboard users can actually reach them.
• Any custom widget manages focus correctly. If a modal opens, focus moves into it. If it closes, focus returns to the trigger.
• Animations respect prefers-reduced-motion. Some people get genuinely sick from motion.

const reduceMotion = window.matchMedia('(prefers-reduced-motion: reduce)');

function animate(el) {
 if (reduceMotion.matches) return; // just show the final state
 el.animate([{ opacity: 0 }, { opacity: 1 }], { duration: 300 });
}

What I tell clients who ask for “more modern”

Modern isn’t a look. It’s whether the site loads fast on a phone in a parking lot, whether the forms work, and whether it’s still maintainable in two years. A site built with plain HTML and careful JavaScript often outperforms a rebuilt-with-everything site, and it costs less to keep running. That’s the pitch, and it holds up.

FAQ

Do I need to rewrite my site to fix performance?

Usually no. Deferring scripts, compressing images, and removing unused code fixes the majority of slow sites I look at. A full rewrite is a last resort, not a first step.

Is a JavaScript framework bad for SEO in 2026?

Not inherently. Google renders JavaScript now, but it’s slower and less reliable than plain HTML. Server-rendered or static HTML still indexes faster and more predictably. For a small business site, that reliability matters.

How often should I re-test performance?

After any notable change, and at least quarterly. Sites drift as plugins, analytics, and third-party widgets pile up. A five-minute test every few months catches problems before they cost you customers.