A slow site costs money in three places: visitors leave without waiting, ad budget is wasted, and the page experience looks weak in search results. Speeding a site up is usually less miraculous and more disciplined than people expect: shrink the big images, clean out unnecessary code, load the right thing at the right time.
In this article we explain the nine fixes that really reduce load time, why each one works and how to check it. Instead of giving a theoretical list, we also share what we did and measured on our own site, because the thing that misleads people most about speed is a measurement taken under the wrong conditions. If you want to learn the concepts first, take a look at what Core Web Vitals are.
Measure Speed First: The Right Tool and the Right Conditions
Before you fix something you need to know what is slow. Three tools are enough for measurement: Lighthouse in Chrome (mobile mode), PageSpeed Insights and the Core Web Vitals report in Search Console. The first two take lab measurements; the third shows real user data and fills in only for pages with enough visits.
Avoid three mistakes when measuring:
- Looking at a single page. The home page may be fast while a blog post or product page is slow. Measure at least three different page types.
- Measuring on a local server without compression. On a local development server, gzip or brotli compression is often off and the score comes out lower than it should. We measured this on our own site: on a server without compression we got falsely low scores, and with compression on, as on a real server, the results rose noticeably.
- Deciding from a single measurement. Lighthouse results move by a few points. Measure the same page a few times and look at the average before you decide.
Do not turn measurement into a hunt for points. A score of 100 is an indicator, not a goal; the real question is how quickly the visitor can see and use the page.
Images: Most of the Load Time Is Usually Here
In the vast majority of slow sites the problem is images. The first three steps of the fix always start here.
1. The right size and a modern format. Loading a photo that appears 600 pixels wide on screen at 4000 pixels wastes both bandwidth and time. Save the image close to the size at which it will be shown and convert it to a modern format such as WebP. If you have few enough images to convert one by one, our free image compression tool and image format converter run in your browser; your files are not sent to a server.
2. Write the width and height values. If the space an image takes is not written, the browser cannot reserve room until the image arrives and the page shifts. This “layout shift” is the CLS metric in Core Web Vitals. Every image should have width and height attributes. Setting up a rule that adds these values automatically to images in blog posts is much safer than making the same fix by hand across hundreds of posts.
3. Lazy-load what is off screen, but not the first screen. Images lower on the page load as you scroll with loading="lazy". But the largest image on the page (usually the photo or hero image on the first screen) must not be lazy-loaded; LCP, the time the largest content appears, depends on this image. Give priority to the first-screen image and defer the rest.
Fonts and CSS
After images, the second group that slows a page is the resources that make the browser wait: font files and style files.
4. Reduce fonts and define a fallback. Every font weight is a separate file. With three weights, two families and two language subsets, the page downloads ten files. Keep the weights you really use. With font-display: swap, let the text show before the font arrives. Then bring the fallback font’s metrics close to the real font so the lines do not move when the font arrives. On our own site we use a web font for headings and a system font for body text, and we matched the fallback font to the metrics of the real font; while the page loads, the number of lines and the height of the headings stay almost the same.
5. Keep CSS small and reduce blocking requests. Unused style code can grow to hundreds of kilobytes on sites that depend on themes and plugins. Removing a plugin you do not use is often the most effective CSS cleanup. On our own site we embed the style code in the page rather than as a separate file, and we chose this by measuring. When we moved the same styles to a separate file there was no gain, and the first paint was delayed by 0.1 to 0.3 seconds. So there is no general rule: measure the options on your own site.
JavaScript and Third-Party Scripts
Images make a page heavier, while JavaScript delays usability: the page is visible but does not respond to touch.
6. Remove scripts you do not use and defer the ones you need. An old slider, an unused animation library or an abandoned plugin may still be loading. The “Coverage” panel in Chrome DevTools shows which code never runs. Scripts that are needed but not essential on the first screen (chat windows, popups, maps) should run after the page has loaded.
7. Leave measurement and ad code to the first interaction. Analytics and ad tags are a significant part of page weight. On our own site the Google tag’s command queue is set up immediately, but the tag file is downloaded on the first interaction (scroll, touch, click) or 3.5 seconds after load. Measurement is usually not lost, because the queued commands are processed when the tag loads; but the browser does less work while the page is loading.
8. Load embedded content on click. An embedded video or map brings hundreds of kilobytes and many requests on its own. Showing a preview image first and loading the content when it is clicked removes from the page a load that most visitors never open.
Server Side: Compression, Caching and Hosting
9. Compression, caching and adequate hosting. If your server does not send HTML, CSS and JavaScript files compressed with gzip or brotli, every page downloads larger than it needs to. Giving static files (images, fonts, CSS, JS) a long-lived cache header prevents returning visitors from downloading them again. How quickly the server sends the first byte (TTFB) depends on hosting quality; on a shared and busy server even the best optimized site opens slowly.
Choosing hosting is a separate subject; compression and cache settings, on the other hand, can be switched on in most hosting panels or in a configuration file with a few lines. Be careful when changing cache settings: a wrong configuration can delay updates reaching visitors. Adding a version number or a content hash to file names makes a long cache safe.
What Did We Do and Measure on Our Own Site?
We applied most of the items above on our own site and measured them. In our Lighthouse measurement of 24 October 2026 (mobile mode, lab conditions, a local server with compression on, similar to a real server) the home page performance score was 99, our web design page 99 and our about page 100; the time for the largest content to appear was between 1.7 and 2.0 seconds. The accessibility, best practices and SEO scores were 100 on the pages measured.
These figures are lab measurements; real users’ experience varies with device and connection. That is why we use them not as a promise but to compare before and after with the same measurement. What matters is to re-measure the same pages under the same conditions after each change and to notice immediately if a change lowers the score. On multi-section pages like our home page, small settings such as not drawing the sections after the first screen until they approach the viewport also reduce the work done at first load.
Common Mistakes When Fixing Speed
- Expecting a single plugin to speed things up. Cache or speed plugins help up to a point; if heavy images and unnecessary scripts remain, the score does not move.
- Hurting quality while shrinking images. The quality loss should not be visible; on product and portfolio images, lower the compression gradually and compare.
- Skipping mobile measurement. Speed problems are much more visible on a phone than on a desktop; measure in mobile mode.
- Aiming only at the score. Removing features to raise the score (for example deleting the measurement code) does not solve the problem; it just means you stop measuring.
- Not testing after optimization. Image conversion or a cache setting may have broken something; also check the pages by eye on phone and desktop.
A 9-Fix Checklist
- I measured speed on three different page types, in mobile mode and with compression on.
- Images are close to the size at which they are shown and in a modern format such as WebP.
- All images have width and height values written.
- The main image on the first screen is not lazy-loaded, the lower images are.
- The number and weight of fonts are only as many as needed; a fallback font is defined.
- Unused plugins, theme components and scripts are removed.
- Measurement and ad code loads after the page is visible.
- Embedded videos and maps load on click.
- Compression is on at the server, and cache is on for static files.
Each item is an opportunity; start with the ones you answered “no”. For regular upkeep, add the monthly checks in website maintenance and a monthly checklist to your calendar.
How Does Soft Ajans Handle Speed Optimization?
In our web design service speed optimization is a separate step: images, code, cache and server settings are arranged for performance. If you want to handle the technical side with a more comprehensive audit, our technical SEO service examines crawling, indexing and speed together. To see the current state of your site, you can request a free pre-analysis.
For the mobile side of speed work, see how to test a mobile-friendly website, and for the relationship between user experience and ranking, see SEO and user experience.
Frequently Asked Questions
Does website speed directly affect SEO?
Page experience is one of the signals Google evaluates, but it does not determine ranking on its own. A slow site still loses visitors and lowers conversion. Improving speed has direct business value independent of SEO.
What should a good Lighthouse score be?
Seeing 90 and above is a sufficient indicator as a target; but follow the trend and real user data more than the number itself. The score can move a few points depending on the tool version and the measurement conditions.
Is a cache plugin enough for speed?
Not on its own. Caching reduces the load on the server and the time on repeat visits, but it does not solve heavy image and script problems on the first visit. Images and unnecessary code come first, then cache and server settings.
Does converting images to WebP work in every browser?
All current browsers support WebP. If you are not targeting a very old browser, using WebP is safe. Free tools that run in the browser do the job for one-by-one conversion.
Does delaying ad and analytics code lose measurement?
Not when it is set up correctly. Commands are queued and processed when the tag loads. A small difference may arise for very short visits (exits without interaction); it is necessary to know this before setup and to interpret the measurement approach accordingly.
How long does a speed-up project take?
It depends on the scope. Image optimization and basic settings finish quickly; with theme or plugin problems the size of the work grows. Starting with a measurement of what is slow on which page lets you foresee the time and cost realistically.
