Website Speed Optimization: Faster Pages, More Leads

Someone who opens your website on their phone will not wait. If the page stays blank for a few seconds, they go back to the search results and click on a competitor. Good design, strong content and an expensive campaign will not help if the site loads slowly.

Speed is not just a technical concern for developers. It affects how many enquiries you get, how much each lead costs you in paid campaigns and where you rank on Google. The good news: most problems can be found with free tools and fixed without rebuilding the website.

In this guide we cover:

• why loading speed affects sales and SEO;
• how to measure speed and what the Core Web Vitals metrics actually tell you;
• how to speed up images, fonts, code, the server and the database;
• what to do in practice in WordPress and Webflow;
• the usual hidden speed killers on business websites, and how to build a work plan without unnecessary mistakes.

Even if you have no technical background, this guide will help you understand what to ask your developer for and how to check that the work has actually been done.

Why website speed affects sales and SEO

Speed is the currency of the web. Every second of waiting lowers the chance that a visitor will scroll, fill in a form or complete a purchase. A 2020 study by Deloitte, commissioned by Google, found that improving mobile site speed by just a tenth of a second was associated with higher conversion rates in online retail and travel. User expectations have only risen since then.

The impact shows up in three places:

• Conversions. A slow landing page loses visitors before they have even seen your offer. This is especially painful with campaign traffic, where you pay for every click.
• Advertising costs. If some visitors leave before the page loads, the same budget brings in fewer leads. Google Ads also takes landing page experience into account when it assesses ad quality.
• Organic search. Google uses page experience signals, including Core Web Vitals, in its ranking systems. Relevance of the content matters more, but when several pages are equally good, a fast and stable page is in a stronger position.

In other words, speed will not rescue weak content, but a slow site wastes the money you have invested in content, design and advertising.

How to measure website speed: Core Web Vitals and tools

Before you fix anything, measure. Without measurement it is easy to spend time on improvements that change nothing.

The three Core Web Vitals metrics

Google defines three core metrics for user experience. A page is considered good when it meets the threshold for at least 75% of visits:

• LCP (Largest Contentful Paint). How long it takes for the largest element in the first screen to appear, usually the hero image or the main heading. Target: 2.5 seconds or less.
• INP (Interaction to Next Paint). How quickly the page responds to a tap, a keystroke or opening a menu. It replaced FID in 2024. Target: 200 milliseconds or less.
• CLS (Cumulative Layout Shift). How much the content "jumps" while loading, for example when a banner loads above the text and pushes the button down. Target: 0.1 or less.

Lab data vs field data

It is important to understand the difference between two types of data. Lab data is a single test that a tool runs under fixed conditions. It is useful for diagnosis and for checking a fix. Field data is collected from real Chrome users over 28 days, and that is what Google takes into account. A lab score of 100 does not guarantee a good experience for visitors on an older phone and a congested mobile network.

Tools worth knowing

• PageSpeed Insights shows field data, if the site has enough traffic, plus a Lighthouse test with a list of recommendations.
• The Core Web Vitals report in Google Search Console groups all pages of the site by issue and shows which page templates need attention.
• Chrome DevTools, in the Performance and Network tabs, shows exactly what loads, in what order and how long it takes.
• WebPageTest lets you test from different locations and network conditions and watch a video of the page loading.

A detailed explanation of the metrics and thresholds is available on web.dev, the official site of the Chrome team.

Image and video optimization

On most websites, images are the heaviest part of the page. That is usually where you find the biggest and quickest win.

Modern formats and compression

WebP and AVIF are lighter than JPEG and PNG at similar quality, and all modern browsers support them. For manual compression, Squoosh and TinyPNG work well. On larger sites it is better to set up automatic conversion in the CMS or the CDN, so the result does not depend on who uploads the image.

A simple rule: do not upload a 5,000-pixel-wide image when it is displayed at 800 pixels. The file size should match the display size.

Responsive images

With the srcset attribute and the picture element, the browser picks the image version that fits the screen. A phone downloads a small file, a wide monitor gets a large one. We wrote more about how responsive design and speed are connected in our guide to a responsive website.

Lazy loading, but not for every image

The loading="lazy" attribute delays loading images below the fold until the visitor scrolls close to them. This saves a lot on the initial load. However, the hero image, which is usually the LCP element, should not be lazy-loaded. Quite the opposite: mark it with fetchpriority="high" so the browser downloads it first.

Fixed dimensions to prevent layout shifts

Give every image, video and iframe a width and height, or an aspect-ratio in CSS. This way the browser reserves space in advance and the text does not jump when the media loads. It is the most common fix for CLS problems.

Video and background videos

A background video on the home page looks impressive, but it can weigh more than the rest of the page combined. Compress it, shorten it, show a poster image until it loads, and consider replacing it with a still image on mobile. For YouTube and Vimeo embeds, it is better to show a thumbnail with a play button and load the player only after a click.

Fonts, CSS and JavaScript: less code blocking the page

Even once the images are light, a page can still load slowly because of code the browser has to download and run before it shows anything.

Fonts

• Use two or three font weights, not eight.
• Host font files on your own domain or CDN, in WOFF2 format.
• Add font-display: swap so text appears immediately in a fallback font instead of staying invisible.
• Preload only the font used in the main heading.
• A variable font can replace several separate files.

CSS

Minifying and compressing CSS files is the baseline. What matters more is getting rid of unused CSS: themes and page builders often load styles for every possible component, even if the page uses only three of them.

JavaScript and third-party scripts

This is where most INP problems live. Every script that runs during loading keeps the browser busy, and the page responds slowly to taps and clicks. What to do:

• load scripts with defer or async so they do not block rendering;
• go through every tag in Google Tag Manager and remove what is no longer in use: pixels from old campaigns, heatmap tools nobody looks at, finished A/B tests;
• load chat, review and map widgets only after user interaction or after the page has loaded;
• check in DevTools which scripts are the heaviest and decide whether each one really adds value.

Compression in transit

The server should send files compressed with Brotli or Gzip. Most modern hosting enables this by default, but it is worth checking in the Network tab that the Content-Encoding header is actually there.

Server, hosting, caching and CDN

Server and hosting

Server response time (TTFB) is the foundation for everything else. If the server takes a second to respond, a good LCP is hard to reach. What to check in your hosting:

• CPU and memory resources that match your traffic, rather than an overcrowded shared server;
• a current, supported PHP version if it is a WordPress site;
• support for HTTP/2 or HTTP/3;
• server-side caching and an option for object caching, for example Redis;
• a server location or CDN points of presence close to your audience.

Caching

A cache stores a ready-made copy of a page or of files so they do not have to be rebuilt on every visit. There are several layers: page caching on the server, object caching for the database and browser caching for static files. For files that do not change, such as images, fonts and CSS files with a version in the file name, set a Cache-Control header with a long lifetime so the browser does not download them again on a return visit.

CDN

A CDN (Content Delivery Network) is a network of servers around the world that stores copies of your files and serves them from the server closest to the visitor. The main server gets fewer requests and the visitor gets the files faster. Well-known providers include Cloudflare, Amazon CloudFront, Fastly and Bunny.net. To connect a CDN, you choose a provider, add your domain and update the DNS records or nameservers. If your site is hosted in one country and your customers are spread across Europe or further afield, a CDN with nearby servers shortens the delivery time of every file.

The database

On dynamic websites such as online stores and large content sites, the database is often the bottleneck. These are the main areas a developer will look at:

• indexes on columns that are frequently searched or filtered;
• slow queries that can be simplified, using EXPLAIN and the slow query log;
• cleaning up accumulated data: old post revisions, transients and autoloaded options that are read on every request;
• caching the results of repeated queries.

What to do in practice in WordPress and Webflow

WordPress

In WordPress, flexibility is also the risk: every plugin, theme and page builder adds code. What works:

• A lightweight theme. Themes such as GeneratePress, Kadence and Astra, or a block theme built on theme.json, start with a low page weight.
• One caching plugin. For example WP Rocket, LiteSpeed Cache (on LiteSpeed servers) or WP Super Cache. Two caching plugins at the same time create problems, not speed.
• Fewer plugins. Go through the list and remove what you do not use. The Query Monitor plugin helps you find slow plugins and queries.
• Elementor. Turn on the built-in performance features, such as improved asset loading and optimized DOM output, and avoid deeply nested containers.
• Images. WordPress generates multiple sizes and srcset automatically and supports WebP and AVIF. An optimization plugin or a CDN with image conversion covers the rest.

For more on building a WordPress site properly from the start, including choosing hosting, see our guide on how to build a WordPress website.

Webflow

In Webflow, much of the work is already done by the platform: hosting includes a global CDN, files are served compressed and images get responsive versions automatically. There is still plenty you can do:

• convert images to WebP or AVIF directly in the Assets panel;
• set lazy loading for images further down the page, and eager loading for the hero image;
• be careful with heavy interactions and animations that run on page load;
• review custom code in Custom Code settings and Embed elements, and load third-party scripts with defer;
• avoid overloading a single page with large Collection Lists;
• keep a clean class structure, for example following Client-First, so the CSS does not bloat.

Hidden speed killers on business websites

Some of the heaviest elements on a typical business website have nothing to do with design. They are added one by one, often by different people, and nobody checks their combined weight:

• Mobile first. For most business websites, the majority of visits now come from phones, often on a mobile connection. Always start with the mobile results in PageSpeed Insights, not the desktop ones.
• Multilingual fonts. If your site runs in several languages, a font that covers extended Latin, Greek or Cyrillic can be several times heavier than you need. Load only the character subsets and weights that each language version actually uses.
• Cookie consent banners. Under GDPR and the ePrivacy rules in the EU, most sites show a consent banner, and many consent platforms load a large script before anything else. Choose a lightweight solution, make sure it does not cause layout shifts, and check its weight like any other script. This is not legal advice: what your site needs depends on the tools you use, so check the requirements with a qualified adviser.
• Accessibility overlays. Accessibility requirements in Europe are getting stricter, and some sites respond by adding an overlay widget. Some of these tools load a lot of JavaScript. Real accessibility is built into the code itself, and any extra tool should also be checked for its weight.
• WhatsApp and chat widgets. A simple WhatsApp button is a light link. A full chat widget loads entire libraries. If you need one, load it after the page is ready.
• Pixels and payments. Meta Pixel, Google Ads, GA4 and payment pages inside an iframe all add requests. Keep only what you actually use for measurement, and consider moving part of the tracking to the server side.

Work plan: where to start and what to avoid

Step 1: Measure the current state

Run PageSpeed Insights on your key pages: the home page, service pages, campaign landing pages and a product page. Check in the Core Web Vitals report in Search Console which groups of pages are flagged as poor. Save the results as your baseline.

Step 2: Prioritise by impact

Start with the pages that bring in the most traffic and revenue, and with issues that repeat across a whole template. One fix in a product page template improves hundreds of pages at once.

Step 3: Fix the quick wins

Images, unnecessary scripts, lazy loading and image dimensions. These are short fixes that usually deliver most of the improvement.

Step 4: Deal with the infrastructure

Caching, CDN, a hosting and PHP upgrade, database cleanup. This is where you need a developer or a DevOps specialist.

Step 5: Test and monitor

After every change, check that the site still works: forms, payments, menus and conversion tracking. Field data updates slowly, so come back to the report after a few weeks. Keep checking after every theme update, new plugin or campaign with a new landing page.

Common mistakes

• Chasing a score of 100. The Lighthouse score is a diagnostic tool, not a goal. It matters more that your field data passes the thresholds.
• Testing only on desktop. A site can be fast on the office computer and slow on a customer's phone.
• Adding another plugin to solve a plugin problem. Sometimes the fix is to remove, not to install.
• Lazy-loading the hero image. This slows down LCP instead of improving it.
• Breaking the site in the name of speed. Aggressive minification and file merging can break forms or tracking. Test after every change.
• Forgetting about speed during a migration. A migration is the best moment to build things properly from the start. Take the chance to handle redirects too, as we explained in our guide to the 404 error page.

How RJL Studio speeds up websites

At RJL Studio we review website speed as part of a technical SEO audit: we measure Core Web Vitals in field and lab data, find what slows the pages down and build a fix plan ordered by impact. We work on images, multilingual fonts, scripts and tags, caching and CDN, and we build new websites in Webflow and WordPress with speed as a requirement from day one.

Want to know what is slowing your website down? Read about our SEO services and Webflow website development, or get in touch and we will get back to you.

Frequently asked questions

How fast should a website load?

There is no single number for every site, but a good target is to meet the Core Web Vitals thresholds: LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, for at least 75% of visits. In practice, the faster the main content appears, the better.

Does website speed affect Google rankings?

Yes, but it is not the main factor. Google uses Core Web Vitals as part of its page experience signals, and the relevance and quality of the content matter more. The bigger impact of speed is on visitor behaviour and conversions.

Why does my PageSpeed Insights score change every time I test?

The lab test is affected by server load, the network and third-party scripts that load differently each time. That is why the score moves by a few points. For decisions, rely on field data and on several repeated tests, not a single run.

Is Webflow faster than WordPress?

In Webflow, the infrastructure, hosting and CDN are managed by the platform, so it is harder to "break" the speed. WordPress can be very fast, but the result depends on the hosting, the theme and the plugins. On both platforms, heavy images and unnecessary scripts will slow the site down just as much.

Can you improve speed without rebuilding the website?

In most cases, yes. Image optimization, cleaning up plugins and scripts, caching and a CDN improve most websites without touching the design. A rebuild is mainly needed when the theme or page builder itself is too heavy to fix.