Improving Site Speed: What Really Slows Your Site Down, and How to Fix It

A slow site almost never looks slow to the person who built it. On the office computer, on fiber internet, with every file already stored in the browser, it opens instantly. Your customers open it on a phone, on a cellular network, and usually for the first time. In this guide we'll go over what Google actually measures, how to test your site properly, and what to fix first. Where we can, we'll show you the numbers from our own site.

Why speed matters to your business, not just to Google

In a 2020 study Google commissioned from Deloitte, covering 37 brands and more than 30 million visits, a 0.1 second improvement in mobile site speed went along with an 8.4% rise in conversions on retail sites and 10.1% on travel sites. The study measured a correlation, so it's no guarantee, but the direction is clear: every moment of waiting costs you customers.

In Google search itself, the picture is less dramatic than people make it sound. Google says Core Web Vitals, its speed metrics, are part of what its ranking systems look at, and also that it will still show the most relevant content even when that page's experience is weaker. A fast site with thin content won't overtake a slow site with a better answer. That said, when the content is similar, speed can tip the balance, and above all it decides what happens after the click: how many visitors stay, fill in a form or buy.

And it's not just other people's sites. According to the 2025 Web Almanac report, only 48% of websites worldwide pass all three metrics on mobile.

What Google measures: LCP, INP and CLS

Google calls these three metrics Core Web Vitals. Each one checks a different part of the experience for someone visiting your site:

Google's three metrics and their targets

Metric	What it measures	Good	Poor
LCP	How long until the largest element on the page appears, usually the hero image or the main heading	2.5 seconds or less	Over 4 seconds
INP	How quickly the page responds when you tap a button, open a menu or type	200 milliseconds or less	Over 500 milliseconds
CLS	How much the page jumps while it loads, like a button that moves just before you tap it	0.1 or less	Over 0.25

Google checks each metric separately, and mobile and desktop separately. It takes the value that 75% of visits to the page fall below. Put simply: three out of four visitors need to get a good experience, not just you at the office.

Website speed test: how to test it properly

The basic tool is PageSpeed Insights from Google. Enter a page's address and you get two very different things, which are worth keeping apart:

• Real-user data, at the top: measurements from Chrome users who visited the page in the last 28 days. This is the data Google uses.
• Lab test, at the bottom, with the 0 to 100 score: a simulation of a mid-range phone on a slow 4G network. It's great for finding problems, but Google doesn't rank by it.

How to run a test you can trust

1. Start with the Mobile view. It's stricter, and that's where problems show up.
2. Test several pages, not just the home page: a service page, a product page and an article. Each type of page is built differently and behaves differently.
3. Run it two or three times. The score moves by a few points from one run to the next, so look at the metrics themselves, not the colored number.
4. Once your site has enough traffic, open Google Search Console and go to the Core Web Vitals report. It groups similar pages and marks each group as good, needs improvement or poor, based on its weakest metric.

How it looks on our site

We ran the test on our blog page. It has no heavy animations, and Google Analytics only loads on it after the visitor accepts cookies:

• Performance score 99 Good 90 or above is good
• LCP 1.8s Good Target: 2.5 seconds or less
• CLS 0 Good Target: 0.1 or less
• TBT 0ms Good Lab target: 200ms or less

On the desktop test, the same page scored 100, and the main content appeared after 0.4 seconds. The metric worth knowing here is TBT: the time the phone's processor was too busy to respond to a tap. It's the lab metric that predicts INP, and it's worth 30 of the score's 100 points. Heavy animations, sliders and external scripts are what inflate it, so each of them has to earn its place on the page.

What about our home page?

Our home page has an animated 3D world, and that's exactly the case where this metric explodes. Google's test runs on a computer with no graphics card, so the browser drew the world on the processor, frame after frame, until it had no time left to respond to clicks:

Our home page in PageSpeed Insights, before and after the fix (October 30, 2026)

What we measured	Before	After
Mobile score	68	100
Mobile TBT	23,980ms	40ms
Mobile LCP	1.2 seconds	1.2 seconds
Desktop score	The test didn't finish in time	99

The fix wasn't to remove the animated world. We changed the page so the world only loads when there's a graphics card that really draws it, and in every other case it shows a still version of the same sky. That's the version Google's test sees now, and so does an old computer or a device without graphics acceleration, where the animation used to stutter. Anyone with a graphics card still sees the animated world.

What slows down business websites in Israel

The slowness almost always comes from one of these five places. They're listed in the order worth checking them:

1. The hero image or slider

It's usually the largest element on the page, so it's what sets the LCP. The problems that keep coming up: an image uploaded straight from the camera or phone that weighs several megabytes, a slider that loads five images when you only see one, and a background video.

• Upload the image at the width it's shown (and up to twice that, for sharp screens), not the original file.
• Save it as WebP or AVIF. According to Google, WebP is 25% to 34% smaller than JPEG at similar quality, and AVIF often saves even more. Both formats work in almost every browser today.
• Don't lazy-load the first image people see. It needs to load right away, and you can mark it with fetchpriority="high". Lazy-load everything else.
• Give every image a width and height, so the browser saves space for it and the page doesn't jump when it arrives.

2. Hebrew fonts

A font is a file the browser has to download before it can show the text the way you designed it. Many Hebrew sites load four to six weights of the same font, or full TTF files of a commercial font, with thousands of characters nobody needs.

• Two weights are enough, or one variable font file that contains them all.
• Save it as WOFF2, with only the characters you need: Hebrew and basic English. Before you trim a commercial font, check that its license allows it.
• Preload only the font that appears at the top of the page.
• Choose what happens until the font arrives: with font-display: swap the text appears right away in a fallback font and then swaps, and with optional the browser gives up on the font if it's late. The second is faster, the first keeps the look.

3. External scripts: chat, pixels, the cookie banner and the accessibility plugin

Each of them is code that runs on the visitor's phone. One usually goes unnoticed. Put five together, and that's where INP suffers: the page looks ready, but the button responds late when you tap it.

• Go through the list and remove what you don't use: a heatmap someone turned on a year ago, a pixel from a campaign that ended, two tools that do the same thing.
• Check for duplicates. Google Analytics installed both through a plugin and through Google Tag Manager loads twice and counts every visit twice.
• Load the chat only when someone clicks it, and show a YouTube video or a map as an image that turns into a player only on click.
• Load analytics tools and pixels only after the visitor accepts cookies. That way, visitors who don't accept never load them at all.

4. Hosting and server location

Before the browser starts building the page, it waits for the first response from the server (TTFB). Google recommends, as a rough guide, keeping this to 0.8 seconds or less. Cheap, overcrowded hosting, or a server on the other side of the world, can eat up most of that time before a single image has loaded.

• For a site aimed at an Israeli audience, a server in Europe or Israel is better than one in the US.
• A page cache keeps the page ready, so the server doesn't rebuild it on every visit.
• A CDN like Cloudflare serves the files from the server closest to the visitor. Note that with its default settings it caches images, CSS and JavaScript, but not the pages themselves. For that you need a Cache Rule, or on WordPress, their APO service.

5. The theme and plugins

Every WordPress plugin can add CSS and JavaScript files to every page on the site, even pages that don't use it. A heavy theme, with sliders, animations and dozens of options, does the same.

• Delete plugins you don't use. Deactivating them isn't enough.
• One caching plugin only. Two caching plugins clash, and the result is usually slower and more broken.
• Choose a lightweight theme. For Elementor, Elementor's own Hello theme was built for exactly this.

What to fix first

You don't have to do everything. Here's how we rank the fixes, by how much they usually help against how much work they take:

The fixes in order of priority

Fix	Impact	Effort	Mainly improves
Hero image	High	Low	LCP
External scripts	High	Low to medium	INP, LCP
Fonts	Medium	Low	LCP, CLS
Reserved space for images and banners	Medium	Low	CLS
Caching and CDN	High	Medium	LCP
Switching hosts	High if the server is slow	Medium	LCP
Theme and plugins	High	High	All metrics

Speeding up WordPress and Elementor sites

Elementor's settings

In Elementor, under Settings, on the Performance tab, there are a few switches worth checking. According to Elementor:

• Optimized Image Loading: marks the main image to load right away and defers the images below the fold.
• Lazy Load Background Images: defers background images until you scroll to them.
• Element Cache: caches rendered widgets instead of building them again on every load.
• Load Google Fonts Locally: serves the fonts from your own server instead of Google's (see above).

After every change, go through the site and check that nothing broke, especially on mobile.

One caching plugin, set up right

If your hosting runs on a LiteSpeed server, the free LiteSpeed Cache plugin works directly with the server. On other servers, WP Rocket is a paid option that works well out of the box. Either way: one plugin, and once it's on, check that the forms, the cart and checkout still work.

PHP, the database and what's been left behind

WordPress recommends PHP 8.3 or later and MySQL 8.0 or MariaDB 10.11 or later. Older versions, like PHP 7.4, still work, but they no longer get security updates. You update the version in your hosting control panel, ideally after a backup and a test on a staging site.

Is your site on Wix or Shopify? What you do control

On closed platforms, the platform runs the server, the caching and the CDN. That's also an advantage: fewer things can go wrong. What does stay in your hands is what you add to the site:

• Images: exactly the same rules. A huge hero image will slow down a Wix site too.
• Apps and plugins: every app adds code. Remove the ones you don't use, and check that their code doesn't stay behind in the theme after you uninstall them.
• Background videos, extra fonts, and external widgets like chat and reviews.

Both platforms have a built-in speed report in the admin panel, worth checking after every big change.

4 myths that cost businesses time and money

"You need a score of 100"

No. 90 or above already counts as good, and Google itself says that chasing a perfect score just for SEO probably isn't the best use of your time. The goal is for your real visitors to pass all three metrics.

"A speed plugin will fix everything"

A caching plugin helps the server, but it won't shrink a 3MB image, remove a heavy chat widget, or make a heavy theme light.

"Lazy-load every image"

For the images below the fold, yes. For the hero image it actually slows down the LCP, because the browser waits before it starts downloading it.

"A CDN solves everything"

A CDN brings the files closer to the visitor. It doesn't make them smaller, and with its default settings it doesn't cache the pages themselves. If the server is slow to build the page, the visitor still waits.

When it's time for new hosting or a rebuild

If you've gone through the whole list and the server's first response still takes more than a second, the problem is probably your hosting. If the site is built on a theme or page builder that loads hundreds of kilobytes of code on every page, it's sometimes cheaper to rebuild than to keep patching it.

We give an honest answer even when it's "you don't need anything": a short call is enough, and we'll tell you what's worth doing. You can read more on our building a business website and hosting and care for your site with us.

Checklist: 15 minutes to check your site

FAQ

Sources

1. web.dev: Web Vitals The metrics and their targets
2. web.dev: INP becomes a Core Web Vital March 2024
3. Google Search Central: Page experience in search results
4. PageSpeed Insights: About real-user and lab data
5. Milliseconds Make Millions Deloitte, commissioned by Google, 2020
6. HTTP Archive: Web Almanac 2025, Performance
7. Google: WebP
8. web.dev: Optimize LCP
9. web.dev: Font best practices
10. web.dev: TTFB
11. Cloudflare: Default cache behavior
12. Elementor: Performance settings
13. WordPress: System requirements