How to speed up a slow website

Large uncompressed images are the number one cause of slow sites. A page often downloads several megabytes of images that could be ten times smaller.

Convert images to WebP or AVIF and upload them at the right size. Add lazy loading so images load only when the visitor scrolls to them.

Caching stores a ready version of the page so the server does not rebuild it for every visitor.

On WordPress a good caching plugin gives an instant win. On custom sites, static generation or a CDN does the same. After images, this is usually the biggest single improvement.

Every script and style sheet adds load time. Many sites load code that is not even used on the current page.

Remove unused plugins and third-party scripts. Each analytics tag, chat widget and tracking pixel has a cost. Keep only what earns its place.

Cheap shared hosting is often the quiet cause of a slow site. The server responds slowly and no optimisation fully fixes a weak foundation.

If images, caching and code are handled and the site is still slow, the host is the likely culprit. Decent hosting costs a little more and gives a solid base.

Speed work goes wrong when five things are changed at once and nobody knows which one helped. Use a simple log instead.

• •Pick three pages: the homepage, your most visited inner page and the page where money or inquiries come in.
• •Test each on mobile, logged out, in a private window. Write down load time and page weight.
• •Change one thing, clear the cache, test again, write the new numbers next to the old.
• •Keep a copy of the site from before you started, so any step can be undone.
• •Stop when the three pages feel instant on a real phone. Chasing a perfect score past that point costs more than it returns.

If a developer does the work, ask for the same log. A before and after table for three pages is a fair way to see what you paid for.

A site in Estonian, Russian and English has a few costs that a single-language site does not.

Translation plugins on WordPress add database work to every page view. Make sure the cache stores a separate ready copy per language, otherwise the server rebuilds each page for each visitor.

Shop modules for bank links and parcel lockers often load their scripts and styles across the whole site. They are needed in the cart and checkout only. Limiting them to those pages is usually a small job with a visible effect.

Fonts are a quiet weight. A family that covers Latin, Estonian letters and Cyrillic in four weights can be larger than all your text together. Two weights, modern font formats and subsets per script are enough for most brands.

Finally, do not detect language by location and redirect. It slows the first view, and a Russian speaker in Tallinn or an English-speaking founder in Tartu gets the wrong version anyway. Let people choose, and remember the choice.

• •Testing while logged in to the admin. Logged-in users skip the cache, so the site looks slower than it is.
• •Testing only on office wifi and a new laptop. Your customers are on a phone in a bus.
• •Testing only the homepage when the slow page is the product list or the checkout.
• •Testing from Estonia when the customers are abroad. An e-resident company selling to another continent should check from there, and a content delivery network is the usual answer if it is slow.
• •Stacking a second and third optimisation plugin on top of the first. They conflict, and the site gets slower and harder to fix.