When a site is slow, the first thought is usually to switch hosting. Sometimes that's right, but often it isn't. A situation we see often: on many small business sites, the cause isn't the server but the page itself. Unoptimised images, unnecessary plugins and third-party code added to the page. The order below starts with the job that gives the most gain for the least effort.
Measure first
Improving without knowing what's slow is shooting arrows in the dark. Before starting, take three measurements and write the results down; you'll need them for comparison later.
Run your homepage and your two or three most important pages (your most visited service page, the contact page, a product page if you sell online) through PageSpeed Insights separately. Focus on the mobile result; a large share of your visitors probably come from phones. The 'Opportunities' and 'Diagnostics' sections usually show the biggest problem near the top.
Check the Core Web Vitals report in Search Console. It comes from real visitor data and shows which metric is a problem on which group of pages. We explained what LCP, INP and CLS mean in a separate article.
Finally, open the site on your own phone with Wi-Fi off, on mobile data. You'll notice something measurement tools don't tell you: what the visitor actually feels.
Shrink images and use modern formats
On small business sites, the biggest and easiest win is often here. A picture we see often: at the top of the homepage, a photo of several MB taken on a phone, 4000 pixels wide. It's displayed at 1200 pixels on screen, 400 on mobile. The visitor downloads a file far bigger than the image they'll see.
Here's what to do. Resize images to the largest size they'll be shown at; for a full-width cover image, 1600 to 2000 pixels is usually enough. Use WebP or AVIF instead of JPEG and PNG; file size often drops noticeably at the same visual quality. Make images further down the page load only as they approach the screen (lazy loading), but don't apply this to the main image on the first screen, or LCP gets worse. Where possible, serve different image sizes for different screen sizes.
If you use WordPress, an image optimisation plugin can do most of this automatically. But make sure it converts existing images too; some only process new uploads. We covered the SEO side of image optimisation, along with alt text and file names, in a separate article.
This single step can noticeably cut page weight on many sites.
Unnecessary plugins and third-party scripts
The second big win is getting rid of excess code. On plugin-based systems, installed plugins, used or not, often add their own CSS and JavaScript to pages. Plugins tried and forgotten over the years, a slider plugin never used on the site, two contact form plugins, three SEO tools... Each can make the page a little heavier.
Third-party scripts are usually heavier still: live chat windows, social media feeds, embedded Instagram galleries, Google Maps, YouTube videos, multiple tracking and ad codes, heavy cookie banners. Each pulls files from another server and keeps the browser busy.
The job is to take inventory. Look at your installed plugins and ask of each one, 'what does this do right now?' Delete the ones without an answer. Do the same for third-party scripts: is the code for a heatmap tool you haven't looked at in six months still on the site? For what remains, consider: could the map or video be shown as a preview image until the visitor clicks? Could the live chat window load a few seconds after the page opens?
This step particularly improves INP, the site's response to clicks.
Caching and CDN
Caching means serving a ready copy of a page instead of building it from scratch on every visit. On systems that generate pages from a database on each request, the difference can be noticeable. Page caching can be set up with a plugin or through server-level caching offered by your host. Browser caching keeps images, CSS and JavaScript in the visitor's browser, so those files aren't downloaded again on the next page.
A CDN (content delivery network) copies your site's files to servers around the world and serves them from the one closest to the visitor. If most of your visitors are in Türkiye and your server is too, the speed gain from a CDN may be limited. It's more noticeable if you get visitors from abroad or your server is overseas. Free plans from some CDN services may also offer basic security protection; check the plan details on the provider's own site.
After setting up caching, don't forget to check one thing: personalised pages like forms, the cart and member login must not be cached. Otherwise one visitor might see another's cart. It's a common mistake in cache settings.
When is hosting the problem?
If you've done the steps above and the site is still slow, it's the server's turn. One clear sign of a server problem is a high 'server response time' (TTFB) in PageSpeed Insights. If the server takes a long time to send the first byte even though the page is served from cache, the problem is most likely the hosting.
Other signs: the site slows down at certain times of day (load from other sites on a shared server), the PHP version on the server is old and the hosting panel won't let you upgrade, or traffic has outgrown what a shared hosting package can handle. In these cases, moving to a better shared package, managed hosting or a VPS can make a difference.
Order matters here. Moving a site full of unoptimised images to a more expensive server solves only a small part of the problem and has you paying more every month.
Set a speed budget
You've sped the site up. A common reason it slows down again six months later is newly added content and code. An uncompressed banner for a campaign, a new tracking code added by the marketing team, three videos embedded in a blog post.
The way to prevent this is a simple speed budget. For example: the homepage's total weight won't exceed 1.5 MB, no single image will exceed 200 KB, mobile LCP stays under 2.5 seconds, and before any new script is added to the site, what it does and how it affects speed is checked. Share these rules with everyone who adds content to the site.
Repeating the PageSpeed Insights measurement once a month and comparing with the numbers you noted at the start shows whether the budget is being exceeded. Fixing a slowdown the moment it's noticed is much easier than untangling an accumulated problem six months later.
Frequently Asked Questions
Is installing a speed plugin enough on its own?
Usually not. Caching and minification plugins help, but they don't remove large images or unnecessary scripts. Cleaning up images and the plugin list first can make a bigger difference.
When will I see the effect after speeding up?
In lab tests, immediately. In Search Console's real user data, it can take about a month to fully show, since data from the last 28 days is used.
Blog posts are for general information only and are not a substitute for legal, financial or technical advice.
