Why is my website slow, and what do I actually do about it?

Before changing anything, get a baseline. Run your homepage and your two or three most important pages through Google's PageSpeed Insights, it's free, takes under a minute per page, and gives you both a score and a specific list of what's slow, which is more useful than the score itself.

Pay attention to two things it shows: the 'field data' section, which is how real visitors on real devices actually experience the page if you get enough traffic to be measured, and the 'diagnostics' list, which names the specific culprits, large images, unused JavaScript, slow server response, and so on. The diagnostics list is your actual to-do list; the single number at the top is mostly for bragging rights.

This is the one small business owners skip because it involves a monthly bill rather than a setting to flip, and it's often the single biggest lever available. Cheap shared hosting, the kind sold for a few hundred rupees a month with unlimited everything, puts hundreds of other websites on the same server, sharing the same limited CPU and memory. When a neighbouring site on that server has a traffic spike, gets crawled hard, or is running badly written code, your site slows down too, and there is nothing you can fix in your own code to solve someone else's problem.

You don't need to guess whether hosting is the issue. Look at the 'Time to First Byte' or server response time in your diagnostics. If that number is high even on a page with almost no images or content, hosting is very likely your bottleneck, not anything on the page itself.

This is the most common cause on sites that are otherwise fine, and it's covered in full in the image SEO guide on this site, but the short version bears repeating here because it's genuinely the highest-value five minutes most site owners can spend. A photo straight off a phone or camera is routinely several megabytes. A page with ten of those, uncompressed, at full camera resolution, displayed at a fraction of that size in a content column, is a multi-megabyte page load for no visual benefit whatsoever.

The fix costs nothing and requires no coding: resize images to roughly the size they'll actually display at, and run them through a free compressor before uploading. Most people are stunned at how much smaller a photo gets with no visible difference to the eye.

If your site runs on WordPress, and a large share of small business sites in Nepal do, plugin accumulation is the third usual suspect and often the one that's crept up slowly enough that nobody noticed. Every plugin you install typically loads its own CSS and JavaScript on every page, whether or not that page actually uses the feature. A contact-form plugin loading its assets on your blog posts, an SEO plugin's admin scripts leaking onto the front end, a slider plugin nobody's touched in two years, they all add up.

The same applies more broadly to any third-party embed: live chat widgets, tracking pixels, social share buttons, review widgets, each one is a separate request to a separate server, and each one is a small tax on every single page load regardless of whether that visitor ever interacts with it.

There is a long tail of speed advice that technically helps and practically doesn't matter for a small business site: shaving a few kilobytes off a CSS file, minifying HTML by hand, agonising over whether to use one font-loading technique over another that differs by tens of milliseconds. These aren't wrong, they're just not where the time is, and chasing them while ignoring the three suspects above is a very common way to spend a weekend and see no real change.

If you have limited time and no developer, work in this order: check and fix hosting response time first, because everything else is built on top of it; compress and resize images second, because it's the highest ratio of effort to result; and audit plugins and third-party scripts third. Only after those three are genuinely handled is it worth diving into finer technical tuning, and at that point you're usually better served bringing in someone who can read a Lighthouse report properly than guessing at CSS delivery order yourself.

Caching means storing a ready-made copy of a page (or its assets) so the server doesn't have to rebuild it from scratch on every single visit. For a WordPress or similar CMS site especially, this is one of the cheapest wins available: a caching plugin, or caching built into your host, can turn a page that takes two or three seconds to assemble on each request into one served almost instantly from a stored copy.

The catch is that caching can serve stale content if misconfigured, showing an old price or an outdated announcement after you've updated it. That's a real annoyance, not a reason to avoid caching altogether, it's a reason to know how to clear the cache after you make a change, which every caching plugin and most hosts provide a simple button for.