How Does Website Speed Affect SEO?

You open your site on your phone. The screen stays white for a while, then the text arrives, and just as you are about to tap the call button, the page jumps down. You wait, because it is your site. Your customer will not wait. They hit the back button and move on to the next business on the list.

There are two common exaggerations about site speed. The first is "get your score to 100 and you will rank first on Google." The second is "speed does not matter, content is enough." Both are wrong, and both cost business owners money.

In this article you will find the real weight of speed in rankings, the three things Google measures, how to measure your own site in fifteen minutes, and the seven common causes of a slow site together with their fixes. You do not need any technical background. The aim is for you to be able to discuss the right questions with your developer or your agency.

Does site speed really affect rankings?

The honest answer is this: yes, but its direct effect is smaller than people think, and its indirect effect is larger than people think.

Google states plainly in its search documentation that Core Web Vitals are used by its ranking systems. The same documentation also says that a good page experience is no substitute for relevant, helpful content. In other words, the first condition for ranking is that your page gives the best answer to the question being searched.

Three situations make this concrete:

• If your content is irrelevant to the search, speed will not save you. For a search like "used car inspection in Pendik," a page that never mentions inspections will not reach the top, however fast it loads. (Pendik is a district on Istanbul's Asian side.)
• If the content is close, speed sets pages apart. Of two pages that explain the same service in similar depth, the one that offers the better experience can move ahead.
• If the site is very slow, the damage is independent of ranking. Even if you appear at the top, that position is of no use to you when visitors leave before the page opens.

One more note for local businesses: in Google Maps results, ranking is determined by relevance, distance and prominence. Site speed is not one of those three factors. But what someone meets after tapping the "website" button on your profile is your site, and that experience decides whether the call or the appointment ever comes. We covered local visibility as a whole in our local SEO guide.

How does a visitor behave on a slow site?

Picture a parent in Pendik whose child has a toothache one evening. Phone in one hand, on mobile data, they search for "dentist near me." Three or four options come up, and they tap the first one. This person is not patient. They are in a hurry and they are worried.

A visitor like this shows three behaviors on a slow site.

Bouncing back. If the page stays blank for a few seconds, they hit the back button and move on to the next result. Most of the time you will not even see this visit in your reports, because they left before the measurement code had loaded.

Giving up halfway. The page opens, but nothing happens when they tap a button, and the form is slow to react. The person leaves without finishing what they started.

Loss of trust. Content jumps around, images arrive late, the font suddenly changes. The visitor does not read this as a technical problem. They read it as carelessness. In fields where trust is decisive, such as health, law and finance, that impression is costly.

If you run ads, the picture is even clearer. When someone clicks your ad and leaves before the page opens, you still pay for the click. We looked at ways to use an ad budget efficiently in our article on Google Ads budget efficiency. Landing page speed is one of the quiet but effective items on that list.

What are Core Web Vitals? The three things Google measures

Core Web Vitals are the three metrics Google uses to measure what kind of experience a page gives the user. If your tools are set to Turkish, you will see them labeled "Önemli Web Verileri." Each metric answers a different question, and the thresholds are published on web.dev.

LCP: when does the page's main content appear?

LCP (Largest Contentful Paint) is the time it takes for the largest element visible on the screen to load. On most sites this element is the large photo at the top or the main heading. It is more or less the moment the visitor thinks "the page has opened."

The good threshold is 2.5 seconds or less. The things that most often hurt LCP are oversized cover images, a slow server response, and style and script files that hold up the display of the page.

INP: how quickly does the page react when you tap?

INP (Interaction to Next Paint) measures how long the screen takes to respond when a visitor taps a button, opens a menu or types into a field. It does not look at a single click. It looks at the interactions made across the whole visit and reports a value close to the slowest of them.

The good threshold is 200 milliseconds or less. In March 2024, INP replaced FID, the metric used before it. If you see FID in older articles, know that its current equivalent is INP. The main thing that hurts this metric is too much JavaScript keeping the browser busy.

CLS: does content move around while the page loads?

CLS (Cumulative Layout Shift) measures elements on the page changing position unexpectedly. If an image loads at the top and pushes the "Call" button down just as you are about to tap it, that is what you are experiencing. CLS is not a duration. It is a ratio, and it has no unit.

The good threshold is 0.1 or less. Common causes are images with no dimensions specified, fonts that load late, announcement bars added to the page after it loads, cookie notices and embedded content.

One important detail: Google assesses these metrics not on the average but on 75 percent of visits. For a page to count as "good" on LCP, at least three quarters of visits have to come in under 2.5 seconds. So a handful of visitors on fast connections will not rescue the result. The experience of visitors on slow connections goes into the calculation too.

What is the difference between lab data and real-user data?

Most of the confusion around speed starts here. For the same site, one tool can show a score of 95 while Search Console says "needs improvement." Both are correct, because they measure different things.

Three tools, three jobs

PageSpeed Insights. This is Google's free tool. You paste in your address, and it shows real-user data in the upper section of the page, if any exists, and a lab measurement made with Lighthouse in the lower section. Mobile and desktop results are on separate tabs.

Lighthouse. This is the testing tool built into the developer tools of the Chrome browser, and it also produces the lab section of PageSpeed Insights. It scores performance from 0 to 100 and lists suggestions for improvement. In the mobile test it imitates a mid-range phone and a slow connection, which is why the mobile score can come out noticeably lower than the desktop score.

The Core Web Vitals report in Search Console. It groups your site's pages as good, needs improvement or poor based on real-user data. It shows groups of similar pages, not individual pages. For long-term tracking, this is the place you really need to look.

One more detail: Lighthouse cannot measure INP, because there is no real user interaction in the test. In its place it looks at a metric called Total Blocking Time, which shows how long the browser stays busy. A high Lighthouse score does not, on its own, prove that your INP is good as well.

If a low-traffic site shows "no data"

Many local business sites never reach the number of visits needed for real-user data to form. In that case the upper section of PageSpeed Insights stays empty, and the Search Console report tells you there is not enough data.

This is not an error or a penalty. It simply means Google does not hold enough measurements for your site. On a site like this, you use lab data and the trials you run on your own phone as your guide. As your traffic grows, real-user data starts to form, and to see a good result on that day you need to be prepared from today.

How do you measure your site's speed in 15 minutes?

You can see where your site stands yourself, without needing a developer. Follow the steps below in order and write the results down somewhere.

1. Pick four pages

   The home page, the service page that gets the most visits, the contact page and, if you have one, the page your ads point to. Measuring only the home page is misleading.

2. Test with PageSpeed Insights

   Paste each address into the tool and look at the result on the mobile tab. Note whether there is real-user data in the upper section.

3. Write down the three metrics

   For each page, record LCP, CLS and, if available, INP. Note the overall score too, but do not base your decision on it.

4. Repeat the test twice more

   Results fluctuate. Take the median of the three measurements so that a single bad or good result does not mislead you.

5. Try it on your phone

   Turn off Wi-Fi and open your site on mobile data. Find the service and reach the call button the way a customer would. Write down where you had to wait.

6. Check Search Console

   If you have an account, open the Core Web Vitals report. Is any group of pages marked as poor or needs improvement?

At the end of these fifteen minutes you have a concrete picture: which page, on which metric, by how much it falls short. Instead of telling your developer "the site is slow," you can say "mobile LCP on the service page is above the threshold, and the cover image is at the top of the list of suggestions." The difference between those two sentences decides whether the work is solved in days or in weeks.

Why do sites slow down? Seven common causes and their fixes

The cause of a slow site is almost never a single thing. The seven headings below describe the problems seen most often on small and mid-sized business sites, along with the fix for each.

1. Large, unoptimized images

A photo taken on a phone usually weighs several megabytes and is many times larger than the size at which it will be shown on screen. When that photo is uploaded to the site as it is, the visitor's phone has to download a giant file that will be displayed in a small box.

Fix: Resize images to the dimensions at which they will appear on the site, and save them in modern formats such as WebP or AVIF. Serve different sizes for phones and desktops. Have images below the visible screen load as the visitor scrolls down to them (lazy loading). The one exception is the main image at the very top: it should not be delayed. On the contrary, it should be loaded with priority.

2. Unnecessary JavaScript

JavaScript is the code that gives a page movement and interactivity. The problem is that code which is never used, or is more than the page needs, also gets downloaded and executed. While the browser is busy with that code, it responds late to the visitor's taps.

Fix: Each page should be sent only the code that page needs. Sliders, animation libraries and unused features should be reviewed. Having content prepared on the server and sent to the browser ready to display both speeds up the first view and makes it easier for search engines and AI crawlers to read the content.

3. Third-party scripts

A live chat window, a map, an embedded video, advertising pixels, analytics tools, review widgets. Each one loads from another company's server and is outside your control. One by one they look harmless. Added together, they can be the heaviest load on the site.

Fix: Start by taking an inventory. Which external tools are on your site, and which ones are really being used? Remove the ones that are not. Have the map and the video load when the visitor taps them, not the moment the page opens. Tie measurement and advertising code to cookie consent. This is in line with your legal obligations, and it also lightens the first load.

4. Fonts

Custom fonts give your brand character, but every typeface and every weight is a separate file. If a font loads late, the text is either invisible at first or appears in another font and then changes. That change alters the length of the lines and causes layout shift.

Fix: Reduce the number of fonts and weights you use. Serve the files from your own server and preload the most important one. If your site has Turkish content, make sure the subset containing Turkish characters is loaded. Otherwise letters such as ğ, ş and ı appear in a different font. Setting the dimensions of the fallback font close to those of the real font removes the shift at the moment of the switch.

5. Slow server response

When a visitor enters your address, there is a certain amount of time your server takes to give its first response. If that time is long, everything else starts that much later. The web.dev guidance recommends, as a target for most sites, a first response of 0.8 seconds or less.

Fix: Pages should be served from a cache, not generated from scratch on every visit. A content delivery network (CDN) should be used so files are sent from a point close to the visitor. Compression should be switched on. These are settings that are configured once and keep paying off.

6. Inadequate hosting

On very low-cost shared hosting packages, your site shares the same server with a large number of other sites. When one of the neighboring sites gets heavy traffic, your site slows down too. Because the problem comes and goes during the day, it is hard to spot.

Fix: Do not choose hosting on price alone. Is the server located close to your visitors? Are resources dedicated to you? Are backups and a security certificate included? Hosting is a small item among a site's annual costs, and it is the last place to cut corners.

7. Heavy themes and plugins

Ready-made themes are designed to answer every possible need, so they also carry the code for dozens of features you will never use. On top of that, every plugin you add brings its own style and script files. Drag-and-drop page builders also pay for their convenience with extra code.

Fix: Go through your plugin list and remove the ones that are not really used. If two plugins do the same job, pick one. Keep the theme and plugins up to date. If the site is slow from top to bottom and the cause lies in the basic structure, rebuilding can be more economical than patching. If you decide to rebuild, you can use the criteria in our guide to choosing a web design agency to weigh up who to trust with the job.

Which cause hurts which metric?

Why does mobile speed need separate attention?

Opening your site on the office computer, on a fast connection, and saying "it is plenty fast" is the most common mistake. Your customer is most likely opening your site on a phone, on mobile data, perhaps on a device that is a few years old.

Three reasons make mobile a subject of its own. Phone processors are weaker than computer processors, and running the same JavaScript takes longer. Mobile connections are uneven, and they slow down indoors or on the move. The screen is small, so even a small layout shift can make a finger land in the wrong place.

Google also crawls and assesses sites predominantly through their mobile versions. Core Web Vitals are reported separately for mobile and desktop. It is entirely possible for everything to look fine on desktop while you have problems on mobile, and for local businesses the mobile result is the one that really matters.

In practice, look at the following:

• What appears at the very top on mobile? A clear heading and a single action button are usually both faster and more effective than a giant slider or a video.
• Is the phone being sent small images suited to a phone screen, or the very same image as the desktop?
• Do the call and WhatsApp buttons work even before the page has fully loaded?
• Do a full-screen pop-up, the cookie notice and the live chat bubble all appear at the same moment when the page opens?

Picture a cafe in Kurtköy, a neighborhood of Pendik near Sabiha Gökçen Airport. Its site opens with a promotional video that plays automatically and looks impressive on desktop. On mobile, however, the visitor has to wait for that video to load before they can reach the menu. Replacing the video with a photo and making playback start on a tap is a simple step that could improve both speed and the number of people who reach the menu.

How does speed affect conversions?

A conversion is the visitor taking the action you want: a call, a WhatsApp message, a form, an appointment, an order. The relationship between speed and conversion is intuitively obvious, but we suggest you treat the "every second costs you this much" type of figures that circulate online with caution. Most of those numbers are the internal measurements of very large e-commerce sites and cannot be applied as they are to your site.

What can be said without quoting a number is this: some visitors are lost at every step, and slowness enlarges that loss at every step.

1. Click

   Someone taps your result in search or in an ad

2. Page appears

   If content is delayed, some of them turn back here

3. Reading and trust

   If content shifts or stutters, trust is damaged

4. Action

   If the button is slow to react, the call or form is left unfinished

How do you measure the effect on your own site?

Instead of relying on other people's numbers, look at your own data. Three things need to be in place for that: measurement of call, WhatsApp and form actions, Search Console, and a record of the date the speed improvement was made.

Compare the four weeks before the improvement with the four weeks after it. Look at the rate of actions per visitor, not at the total number. If the ad budget, the season or a campaign changed in the same period, do not attribute the result to speed alone. An honest assessment limits itself to saying "speed improved, and in the same period the action rate moved in this direction."

A real example: how did the lab score go up?

On the GK Therapy site, which we built for a physiotherapist in Kurtköy, the mobile Lighthouse performance score was raised from 63 to 96 and layout shift was brought down to zero. The three steps that achieved this are listed on the case study page: hosting the fonts on the server and preloading them, fallback fonts with matching dimensions, and image sizes made specifically for phones.

It is important to read this example correctly. The figures are lab measurements taken with Lighthouse's simulation of a slow connection and a throttled processor. They are not a claim about rankings or about an increase in revenue. What they show is how much difference it can make to fix just two of the seven causes in this article: images and fonts.

What should you ask your agency or developer?

You are not going to do the speed work yourself, but by asking the right questions you can tell whether the work is being done. The questions below are useful both when you are having a new site built and when you are improving your existing one.

"On which pages, with which tool and with how many measurements do you test speed?" A report that shows only the desktop result for the home page is not enough. Ask for the mobile result, more than one page and more than one measurement.

"Where does each of the three metrics stand?" Instead of a single overall score, ask to see the LCP, INP and CLS values separately. Which one is the problem determines what the fix will be.

"Who optimizes the images, and how?" Are the photos you upload through the panel automatically resized and converted to a modern format? Or does that job fall to you every time?

"Which external tools load on the site?" Ask for a list. If the list includes a tool you do not recognize or no longer use, ask for it to be removed.

"Where is the hosting, and what kind of package is it?" Find out where the server is located and whether caching and a CDN are in use.

"Who will monitor speed after launch?" A site gets heavier over time. It is reasonable to expect a measurement every three months, with the result shared with you.

"What can you not improve?" A good developer tells you the limits as well. A live chat tool you insist on using, or a ready-made theme, can cap the result that is achievable.

If you are planning a new site, speed is not a feature added later. It is a decision made at the start. In our web design service, a Core Web Vitals check is part of the delivery.

A 10-point quick checklist

Use this list while you go through your site or when you meet with your developer. Each item can be answered with a yes or a no.

• ✓The home page and the most important service page have been measured on mobile, and LCP is 2.5 seconds or less
• ✓CLS is 0.1 or less, and buttons and text do not move while the page loads
• ✓Buttons and the menu respond to a tap without delay, and INP is 200 milliseconds or less where data exists
• ✓Images are at the size they will be displayed and in WebP or AVIF format
• ✓The main image at the top is prioritized, and images below the visible screen are lazy loaded
• ✓Width and height values are specified for all images
• ✓The number of fonts is limited, the files come from your own server, and Turkish characters display correctly
• ✓Unused plugins, scripts and external tools have been removed
• ✓The map, video and live chat load when needed, not when the page opens
• ✓Caching, compression and a CDN are switched on, and hosting is in a location close to your visitors

Every item you answer with a no is a concrete work item to take to your developer. Do not try to solve them all at once. On most sites, the order of images first, then external tools, then fonts brings the quickest gains.

Common mistakes with site speed

Measuring only the home page. A significant share of visitors enter the site through service pages or blog posts. Your most visited pages should be at the top of your measurement list.

Looking at the desktop result and relaxing. The desktop score is almost always higher. Base your decision on the mobile result.

Mistaking the score for the goal. Removing a map or a reviews section that is useful to the visitor, just to reach a score of 100, may not be the right trade. The goal is for the visitor to get what they came for quickly.

Fixing it once and forgetting it. Every new photo, every new plugin and every new piece of advertising code makes the site a little heavier. Speed is not a one-off job. It is a regular check.

Thinking a speed plugin will solve everything. Caching and compression plugins are useful, but on their own they cannot carry the weight of a heavy theme and unoptimized images. Installing more than one speed plugin at the same time, meanwhile, can break the site.

Applying lazy loading to every image. If the main image at the top is delayed, LCP gets worse. Lazy loading is only for images that sit below the visible screen.

Adding the cookie notice and announcement bar afterward. If these elements push content down after the page has loaded, they cause layout shift. Their space should be reserved from the start, or they should be shown as an overlay on top of the content.

Putting speed ahead of content. A page that opens very quickly but does not answer the visitor's question earns neither rankings nor customers. Content and relevance first, then speed.

Leaving speed until the end of a redesign. Speed is not a polish applied after the project is finished. Decisions about infrastructure, the image pipeline and fonts are made at the very beginning. Fixing them afterward is both harder and more expensive.

Glossary: terms used in this article

Core Web Vitals

The three metrics Google uses to measure page experience: LCP, INP and CLS. Turkish-language tools label them Önemli Web Verileri.

LCP

The time it takes for the largest content element visible on the screen to load. The good threshold is 2.5 seconds or less.

INP

The time the page takes to respond to a visitor's taps and clicks. The good threshold is 200 milliseconds or less.

CLS

A measure of how much elements change position unexpectedly while the page loads. The good threshold is 0.1 or less.

Lab data

The result of a test run on a single device under set conditions. It helps you find the cause of a problem.

Real-user data

Anonymous measurements collected from real Chrome users who visit your site, covering the last 28 days.

Lighthouse

A Google testing tool that scores a page's performance from 0 to 100 and gives suggestions for improvement.

Lazy loading

Holding back images below the visible screen so they do not load until the visitor scrolls down to them.

CDN

Content delivery network. It sends your site's files from a server that is geographically close to the visitor.

Cache

Keeping frequently requested pages and files ready. It stops the server from doing the same work from scratch on every visit.

The first step you can take this week

Set aside fifteen minutes and measure your four most visited pages on mobile with PageSpeed Insights. Note the three metrics, then turn off Wi-Fi and go through your site on your own phone the way a customer would. This short list moves the conversation with your developer from guesswork to data.

Speed is one part of local visibility work, and it makes the most sense when it is handled together with local SEO. If you are not sure how to interpret the results, you can request a free review so we can look at your site's speed and visibility together.