You know your website needs to be fast. But how exactly do you make that happen?
We covered why speed is critical for SEO and sales in detail here. If you haven't read that piece, here's the short version: a 0.1-second improvement equals 8.4% more conversions (data from Deloitte and Google). But today we're not going to rehash the why. Today we're going straight to what to do.
These 9 steps are ordered by impact - from the easiest with the biggest payoff to the more involved ones. You don't have to do everything at once. Start with the first 2-3 and you'll already see a difference.
A 0.1-second improvement = 8.4% more conversions
Data from a Deloitte and Google study spanning 30+ million sessions. Even small speed improvements drive real sales lift.
Before and after: a real client website
An e-commerce site from a client who came to us last month. Here's what changed after applying the steps in this article:
* Measured with Google PageSpeed Insights, mobile test, February 2026
In this article:
1. Check where you stand
Before you touch anything, you need to know your starting point. Otherwise you're optimizing blind and later you won't know what helped and what didn't.
You need three tools (all free):
Google PageSpeed Insights
The most important one, because it shows you exactly what Google sees. It gives you a score from 0 to 100 and specific recommendations for what to fix. Test both the mobile and desktop versions - the mobile score is usually significantly lower.
GTmetrix
More detailed than PageSpeed. It shows a waterfall diagram - which request takes how long. Useful when you want to pin down exactly what's slowing the site.
WebPageTest
For advanced users. You can test from different locations around the world. It shows a filmstrip - literally frame by frame how the site looks while loading.
Core Web Vitals in plain language
Google measures three things and calls them Core Web Vitals. Without diving into technical details:
Largest Contentful Paint
How quickly the largest element on screen loads (usually the hero image or headline). Target: under 2.5 seconds.
Interaction to Next Paint
How quickly the site responds when you click something. If you press a button and nothing happens for a second - that's a bad INP. Target: under 200ms.
Cumulative Layout Shift
How much content moves around while loading. You know how sometimes you try to click a link, an ad loads at that exact moment and you click the ad instead? That's CLS. Target: under 0.1.
Important: PageSpeed shows two types of data - lab (simulation) and field (from real users). Field data matters more, but it only shows up if your site has enough traffic. If you only see lab data, don't stress - that's normal for smaller sites.
2. Optimize images
If you only do one thing from this entire article - do this. In 80% of cases, images are the main reason a site is slow.
Last week we optimized images on a client's site and the page size dropped from 8MB to 1.2MB. Just from the images. The site loaded 3 times faster without touching anything else.
Here's what you need to do:
Use WebP format
WebP is an image format from Google that's 25-35% smaller than JPEG at the same quality. All modern browsers support it (yes, Safari included, since 2020).
If you have many JPEG/PNG images, convert them with Squoosh (from Google, free) or TinyPNG .
Size them correctly
We see this constantly - a photo from the phone, 3000x4000 pixels, uploaded for a 300-pixel thumbnail. The browser downloads the entire thing, then shrinks it. Pure waste. If the image is displayed in a 600px container, don't upload anything larger than 1200px (2x for retina displays).
Compress
Even at the right size, images can be compressed further without visible quality loss. For WebP, 75-80% quality is usually enough. You can't tell the difference with the naked eye, but the file is 2-3 times smaller.
At Coding Turtles we automate this for all our projects - images are optimized on upload. But if you work with WordPress, Imagify and ShortPixel are good plugins for the job.
3. Enable lazy loading
The idea is simple: why should the browser download an image that's at the bottom of the page if the user is only looking at the top? Lazy loading tells the browser "load this image only when the user is about to scroll to it".
In HTML it's trivial - you add loading="lazy" on the img tags:
<img src="image.webp" loading="lazy" alt="Description" />Two things to keep in mind:
- Don't apply lazy loading to the hero image (the first thing visible). You want that one to load as fast as possible.
- Set width and height on images. Otherwise the browser doesn't know how much space to reserve and you get layout shift (CLS issues).
The same applies to videos. If you have an embedded YouTube video, don't load it until the user scrolls to it. A single YouTube embed pulls in 500-800KB of extra JavaScript.
For the mobile version lazy loading matters even more, because mobile users are often on a slower connection.
4. Minify CSS and JavaScript
When you write code, you add spaces, line breaks, comments - so it's readable. But the browser doesn't care about readability. Minification is the process of stripping out everything unnecessary without changing functionality.
A 100KB file can become 60KB after minification. Doesn't sound like much, but multiply that by 10-15 files and it adds up.
But the bigger issue usually isn't minification, it's unused code. Honestly, most WordPress sites load 3-4 times more CSS and JavaScript than they actually use.
WordPress - which plugins slow it down the most?
If your site is on WordPress, these plugin categories are usually the biggest culprits:
Page builders (Elementor, Divi, WPBakery)
Load huge amounts of CSS and JS on every page, even when you're not using most of the features. Elementor adds 200-400KB of extra code.
Slider plugins (Revolution Slider, LayerSlider)
Sliders themselves are bad for UX (few people actually use them), plus they load heavy scripts. Ask yourself whether you even need a slider.
Social sharing buttons
Every social sharing plugin loads scripts from Facebook, Twitter, LinkedIn... If you must have them, use plain links instead of embedded buttons.
With the custom sites we build at Coding Turtles, this problem doesn't exist - we only load the code that's actually used on a given page.
5. Use a CDN
CDN (Content Delivery Network) in plain English: instead of your site loading from a single server in Germany (or wherever your hosting lives), the files are copied to servers around the world. When someone opens your site, they get it from the nearest server.
For a visitor in Sofia, instead of the request traveling to Frankfurt and back (30-40ms), it reaches a server in Sofia or Bucharest (5-10ms). For one request it's not a big deal. But a page makes 30-50 requests, and then you feel it.
Cloudflare - free and good enough
Cloudflare has a free plan that includes a CDN, basic DDoS protection, and SSL. Setup is fairly easy - you switch your DNS records to go through Cloudflare and you're done.
For most websites the free plan is more than enough. We use it on every client project.
If your hosting already provides a CDN (Vercel or Netlify, for example), use that one. Don't stack a CDN on top of a CDN.
6. Optimize fonts
Fonts are a silent speed killer. A single Google Fonts file is 20-50KB, and most sites load 2-4 weights (regular, bold, italic, bold italic). Add Cyrillic and you get one more file on top.
Three things you can do:
Add font-display: swap
Tells the browser "show the text in the system font while the custom font is downloading". Users see content immediately instead of staring at empty space.
Only load the weights you need
If you don't use italic, don't load it. If you only use regular and bold, load only those. Subsetting (including only the character sets you need) can shrink the file by 60-70%.
Consider system fonts
Inter, Arial, system-ui - these fonts are already on the user's machine and don't need to be downloaded. They aren't always right for the brand, but if speed is a priority, it's worth considering.
On Next.js projects we use next/font - it automatically optimizes fonts and hosts them locally, with no requests to Google.
7. Caching
When you open a site for the first time, the browser downloads everything - HTML, CSS, images, fonts. Caching tells the browser "keep these files, don't download them again next time".
The result? A second visit is dramatically faster. Instead of downloading 2MB, only 50-100KB of new content is downloaded.
Caching is configured through Cache-Control headers on the server. The idea is simple:
- Images, CSS, JS files - cache for a long time (1 year). If you change them, you change the filename.
- HTML pages - cache briefly (5 minutes to 1 hour) or not at all, so users see the latest changes.
For WordPress sites
WordPress by default caches nothing - every page is regenerated from scratch. That's why you need a caching plugin:
WP Super Cache
Easy to set up, free, made by Automattic (the team behind WordPress). A solid starting option.
W3 Total Cache
More settings, more impact, but also more complex. If you know what you're doing, you'll get more out of it.
With static sites and Next.js applications (which is what we build) caching is built in - no extra setup needed.
8. Pick the right hosting
If your site is on a $3/month shared host alongside 500 other sites, the problem may not be your site - it's the server. Shared hosting is like living in an apartment block with 500 units and a single water pipe. When everyone showers in the morning...
Here's how it breaks down:
Shared hosting
SlowSuperHosting, ICDSoft and similar. 3-8 EUR/month. Fine for a low-traffic blog, but usually not enough for a business site. TTFB (time to first byte) is often over 500ms.
VPS (Virtual Private Server)
GoodDigitalOcean, Hetzner, Linode. 5-15 EUR/month. You get dedicated resources. Faster, but you need to know how to configure it (or pay someone who does).
Vercel / Netlify / Cloudflare Pages
FastFree for small projects, 20-40 EUR/month for larger ones. Built-in CDN, automatic caching, edge rendering. TTFB is usually under 100ms. Ideal for Next.js and static sites.
At Coding Turtles we host most of our projects on Vercel. Not because it's trendy, but because speed genuinely impacts sales, and Vercel gives the best price/performance ratio for Next.js sites.
9. Think about the tech stack
Sometimes the problem isn't optimization, it's the foundation. If your site is on WordPress with Elementor, 30 plugins and shared hosting, you can optimize until you're blue in the face and it will still be slower than a clean Next.js or Astro site.
I'm not saying WordPress is bad - for certain cases it's an excellent choice. But for a business site where speed and conversions matter? The difference is significant.
Here's why modern frameworks are faster:
Of course, changing the tech stack isn't a trivial decision. But if you're planning a redesign or a new website, keep in mind how much a faster stack will save you long-term.
For conversions this matters - a fast site is the precondition, but you still need the right structure, clear CTAs, and good UX on top.
Where to start?
Don't try everything at once. These three steps will deliver 80% of the result:
Run PageSpeed Insights and record the result
That way you'll know what your progress is later.
Optimize images (WebP + correct sizing)
This is usually 50%+ of the problem.
Enable lazy loading and caching
Two simple changes with a big impact.
If after these three steps the result is still not good, the problem is most likely the hosting or the tech stack. In that case drop us a line - we'll take a look at what's going on.
Frequently asked questions
Sources
- Web Vitals - Google - Official documentation on Core Web Vitals metrics and thresholds (accessed June 2026)
- Milliseconds Make Millions - Deloitte - Study of 30M+ sessions on the impact of a 0.1s improvement (accessed June 2026)
- HTTP Archive - State of the Web - Data on average page size and trends (accessed June 2026)
- PageSpeed Insights API - Google Developers - How PageSpeed Insights works and what it measures (accessed June 2026)
- What is a CDN? - Cloudflare - Explanation of how a CDN network works (accessed June 2026)