Chapter 24: Why Is the Site Slow?

Last updated: November 1, 2026.

A site loading slowly usually doesn’t come down to a single cause. The hosting may be slow, the images may be too big, JavaScript may be doing more work than it needs to, third-party code may be holding the page up, or the most important content may be shown to the user late.

So when we say “the site is slow,” the first thing we actually need to do is find the source of the speed problem.

I think the biggest mistake here is going straight to PageSpeed Insights and looking only at the score.

Site speed isn’t just a score. What the user actually experiences matters more.

1. Why does a site load slowly?

We can roughly list the causes we run into most often like this:

• Slow or inadequate hosting
• The server responding late
• No caching, or caching set up wrong
• Very large images
• Unnecessary JavaScript
• Too much CSS
• Third-party scripts
• Ad code
• Chat tools
• Tracking code
• External fonts
• Too many HTTP requests
• No CDN
• Slow database queries
• The page loading more resources than the user needs

Some of these can be on the frontend, some on the server and some in the underlying infrastructure. So when we say “the page is slow,” we first need to pin down where the problem is.

2. Why do hosting and server performance matter?

When a user opens a page, the browser first waits for a response from the server. If the server responds late, the optimizations you make on the rest of the page can only do so much.

One of the metrics we often come across here is Time to First Byte (TTFB). Put simply, it’s the time between the user sending the request and the first data arriving from the server.

A bad TTFB isn’t only caused by hosting. It can also come from:

• Slow database queries
• Heavy application code
• Missing cache
• A distant server location
• DNS
• CDN configuration
• Server load

So saying “TTFB is high, change your hosting” isn’t always the right diagnosis. You first need to find out why it’s high.

3. What does caching do?

The server may not need to do the same work from scratch every time a user requests a web page.

For example, on a WordPress site, instead of doing the following for every visitor, we can store the previously generated result for a certain time:

• Connecting to the database
• Fetching the content
• Running the theme
• Running the plugins
• Generating the HTML

We call this caching. Used correctly, it can bring a serious speed gain.

But as in the news site example I described in Chapter 23, with caching it isn’t always “the longer, the better.” Caching the news sitemap for 10 minutes took load off the server, but it caused new articles to be added to the sitemap late.

So in performance optimization too, the basic question is:

What is this system used for?

A corporate site’s caching strategy and a news site’s caching strategy don’t have to be the same.

4. What is a CDN?

A Content Delivery Network (CDN) helps serve some of a site’s resources from servers geographically closer to the user.

For example, your server is in Germany but your visitor is in Singapore. Instead of every image and static file traveling from Germany, delivering them through a CDN from a point closer to the user can reduce latency.

A CDN can be very useful especially for:

• International sites
• Image-heavy sites
• High-traffic projects
• Geographically spread-out audiences

But using a CDN doesn’t make a site fast on its own. Putting a CDN in front of a slow application doesn’t magically solve every problem.

5. Images are one of the biggest loads on most sites

We talked about image SEO in Chapter 17. Images are very important for site speed too.

For example, if you’re showing a 4000×4000 pixel photo that’s several MB in size at 600 pixels wide on a product page, the user may be downloading unnecessary data.

What you can do:

• Use images at the size you need
• Compress them
• Consider modern formats like WebP or AVIF
• Use responsive images
• Define the width and height of images
• Use lazy loading for images below the fold

But there’s a balance here that I consider especially important.

6. Don’t ruin product quality for the sake of speed

Sometimes images get over-compressed to raise the PageSpeed score. On the technical side, the file size shrinks. But the product image gets blurry.

I don’t think this makes sense, especially in e-commerce. The user is about to buy a 10,000 TL product but can’t see the detail of the material in the product photo.

If we gained a few PageSpeed points and hurt product perception and conversion, did we really gain anything? I don’t think so.

The goal of performance optimization is to improve the user experience. Not to raise a performance score by damaging the user experience.

That’s why you always need to think about file size + image quality + user need together.

7. What is lazy loading?

Let’s say there are 20 images far down the page. When the user opens the page, we don’t have to load all 20 images at once. They can load as they get close to appearing on screen.

We call this lazy loading. Especially on long pages, it can seriously reduce the initial load.

But misuse is possible here too. If you delay the main image at the very top of the page, the one the user should see immediately, with lazy loading, you can end up making your LCP worse.

So automatically lazy-loading every image isn’t right either.

8. Why can JavaScript slow a site down?

Modern sites use a lot of JavaScript. Adding to cart, filtering, sliders, popups, analytics, chat, personalization and many other things are done with JavaScript.

The problem isn’t using JavaScript. The problem is running more JavaScript than necessary.

For example, if these are all running on the page at the same time, they can put a serious load on the user’s device:

• 4 different analytics tools
• 3 ad scripts
• A chat widget
• A heatmap
• An A/B testing tool
• Social media pixels
• Unused theme code

This becomes more noticeable especially on mobile devices. Because not everyone uses the latest computer and fast internet.

9. Third-party scripts are sometimes the invisible speed problem

When you look at it from the site developer’s side, your own code may be fast. But code loaded from outside can be very slow.

For example, these can weigh a page down:

• Dozens of tags running through Google Tag Manager
• Meta Pixel
• Chat tools
• Ad services
• Video embeds
• External comment services
• Personalization tools

So when doing a performance analysis, looking only at our own CSS and JavaScript files isn’t enough.

You need to see who is slowing the page down.

10. Google Tag Manager should be checked too

Especially in projects that have been running for years, Tag Manager containers can turn into a junkyard over time.

A campaign ran, code was added. The campaign ended but the code stayed. Another agency came in and added a new pixel. The old pixel wasn’t removed. After a while, dozens of scripts the user doesn’t even know about run when the page opens.

That’s why a speed project also needs to check the Tag Manager side. SEO, Ads, Analytics and development teams may need to work together here.

11. Even fonts can affect performance

Using different fonts on a website can look good from a design point of view. But these can add extra load:

• Too many font families
• Too many font weights
• Fonts loaded from an external server
• Unnecessary character sets

For example, if you only use Regular and Bold, you may not need to download all the 100, 200, 300, 400, 500, 600, 700, 800 and 900 weights.

Small optimizations may not make a big difference on their own, but they become meaningful when they add up across the site.

What are Core Web Vitals?

Google uses three core Core Web Vitals metrics to measure users’ page experience:

According to Google’s current documentation, Core Web Vitals are among the page experience signals used in its ranking systems. But Google also specifically states that good Core Web Vitals results don’t guarantee high rankings and that page experience isn’t made up of a single signal (Google for Developers).

I think this is the right approach from an SEO perspective too:

Important, but not all of SEO.

12. Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest main content element visible on the user’s screen to be displayed. This can be a large product photo, a hero image, a big heading or a large block of content.

For a good user experience, Google aims for LCP to be 2.5 seconds or less (Chrome for Developers).

For example, you use a huge banner on the homepage. The image is 4 MB. The server responds late. And the image is called in later with JavaScript. Your LCP will probably come out bad.

Just compressing the image may not be the solution here. You need to understand at which stage the problem is.

The LCP process can roughly be made up of these parts:

• The server response
• Discovering the resource
• Downloading the resource
• Rendering it on screen

Chrome’s performance tools can also break the LCP delay down into these sub-parts (Chrome for Developers).

13. Interaction to Next Paint (INP)

INP measures how quickly the page responds to user interactions.

For example, if the user does the following but the screen doesn’t react for a long time, the user will feel the site is slow:

• Clicks the menu
• Selects a filter
• Adds to cart
• Opens an accordion
• Presses a button

Google aims for 200 ms or less for a good INP. 200–500 ms needs improvement, and over 500 ms is considered poor (Chrome for Developers).

INP matters especially on sites that use heavy JavaScript. A page can load fast but be very slow to use. So “the page loads in 2 seconds” isn’t a sufficient measure of performance on its own.

14. Cumulative Layout Shift (CLS)

CLS measures unexpected shifts on the page.

We’ve probably all been there. You’re reading a news article. You’re just about to tap a link. An ad loads at the top and the content shifts down. You tap the wrong place. That’s a bad user experience.

Google recommends 0.1 or less for a good CLS value (Chrome for Developers).

CLS problems usually come from:

• Images without specified dimensions
• Ad slots that load later
• Embedded content
• Font swaps
• Elements added later with JavaScript

15. Should a 100 in PageSpeed Insights be our goal?

I don’t think so. Getting 100 can be nice, but the goal of SEO isn’t to get 100.

The Lighthouse performance score is a score built from measurements taken in lab conditions. On top of that, as the score goes up, the effort needed to gain a few more points can increase sharply; the Lighthouse documentation also talks about diminishing returns at high scores (Chrome for Developers).

Think of an e-commerce site: PageSpeed 93. The conversion rate is good. Core Web Vitals are good. Users aren’t having problems.

Is spending weeks of development just to hit 100 really the best investment? Maybe. But in most projects there are probably more important things to do on the SEO side.

In technical SEO, not every problem is equally important.

16. Are PageSpeed Insights and Lighthouse the same thing?

Not exactly. PageSpeed Insights can show two different types of data together.

The first is real user data (field data). This data comes from the Chrome User Experience Report (CrUX) and shows an aggregated view of real Chrome users’ experiences.

The second is lab data. This is the test Lighthouse runs under controlled conditions (Chrome for Developers).

This distinction matters. Because Lighthouse answers the question “What happened in this test?”, while CrUX answers more the question “What have real users experienced recently?”

17. Why do lab data and field data come out different?

It’s completely normal.

You may be testing in Istanbul on fast internet with a powerful computer. The real user, on the other hand, may be using:

• An old Android phone
• Slow mobile internet
• A different country
• A different device
• A different connection quality

So you can score 95 in the lab while the real user experience is bad. Or the opposite. The server may have slowed down temporarily at the moment of the test, while real user data is perfectly fine.

That’s why you need to read the two together in a performance analysis.

18. Why does the Chrome UX Report (CrUX) matter?

CrUX contains aggregated performance data collected from real Chrome users.

Core Web Vitals are usually assessed at the 75th percentile of users. So we’re not just looking at the average. We’re aiming for the large majority of users to have a good experience (Chrome for Developers).

This matters. Because the average can sometimes hide the truth. If 80 out of 100 users have a fast experience and 20 have an incredibly slow one, the average can come out acceptable. But some of your real users are still having serious problems.

19. What is the Search Console Core Web Vitals report for?

Search Console helps us see Core Web Vitals problems by grouping URLs that show a similar user experience (Chrome for Developers).

So just entering the homepage in PageSpeed and saying “The site is fast” isn’t right.

The homepage may be fast. Product pages may be slow. The blog may be fast. The filter system on category pages may cause problems.

Especially on large sites, evaluating by template is the better approach.

20. Why can mobile and desktop give different results?

Because user conditions are different. On desktop, there may be:

• A more powerful processor
• Better internet
• A bigger screen
• More resources

On mobile, running JavaScript can become more expensive. Also, if most of your users are on mobile, the real business problem may be on the mobile side too.

So checking the performance report only on desktop isn’t enough.

21. Are HTTPS and SSL a speed issue?

The main purpose of HTTPS isn’t speed, it’s security.

Google recommends that websites use HTTPS, and HTTPS is an important baseline expectation for page experience. Google also prefers HTTPS URLs over HTTP as canonical when possible (Google for Developers).

I don’t think it makes much sense these days to get hung up on the “Does HTTPS slow a site down?” debate. On modern web infrastructure, serving a site securely should be standard.

22. Is speed a ranking factor?

This question comes up often. The more accurate way to put it is this:

Google says it uses Core Web Vitals in its ranking systems. But rankings aren’t determined by a single “Page Experience Score” or “PageSpeed score.” And good Core Web Vitals values don’t guarantee ranking at the top (Google for Developers).

For example, let’s think of two pages.

The first page:

• 100 PageSpeed
• Weak content
• Doesn’t match the user’s intent

The second page:

• 85 PageSpeed
• Very good content
• Gives the answer the user is looking for

We can’t say “The first page will definitely rank higher because it scored 100.”

Google’s ranking systems evaluate hundreds of different signals and systems together (Google for Developers).

23. Is a very fast but bad site possible?

Absolutely.

An empty HTML page is probably incredibly fast. But it offers the user nothing. So the goal of technical optimization can’t just be chasing milliseconds.

I think you need to ask this question with every optimization:

Does this change improve the real user experience?

For example:

• We shrank the image, but the product isn’t visible.
• We removed the font, but the brand identity broke.
• We removed the JavaScript, but the filter doesn’t work.
• We removed the video, but the product can no longer be explained well enough.

The technical score may have gone up. The business result may get worse.

24. What is log analysis good for here?

Server log analysis gives us the ability to examine the record of requests coming to the server.

From there we can investigate questions like:

• Which URLs is Googlebot crawling?
• How often does it come?
• Does it see 5xx errors?
• Does it spend a lot of time on unnecessary URLs?
• Does it come to important pages often enough?
• What are the server response times like?

Especially on large sites, it can be very valuable for understanding speed and crawling problems together. But on a small 50-page corporate site, starting with log analysis usually isn’t necessary.

Again, you need to act according to scale.

25. In what order do I look when fixing site speed?

It changes with every project, but the general approach can be like this:

• First I check whether there’s real user data.
• I look at mobile and desktop separately.
• I identify the Core Web Vitals problem.
• I check which page template the problem is concentrated in.
• I check the server response.
• I look at large images.
• I examine the JavaScript and CSS load.
• I check third-party scripts.
• I look at the cache and CDN configuration.
• I measure again after the changes.

What matters here is avoiding the “PageSpeed gave me 37 suggestions, let’s do them all” approach. You need to prioritize.

26. A 2 MB image and 20 KB of JavaScript are not the same problem

A PageSpeed report can show many suggestions. But they don’t all have the same impact.

For example, if the page’s LCP image is 4 MB, looking at that first can make more sense than cleaning up 8 KB of unused CSS. Or if the problem is TTFB, small optimizations on the frontend may not be enough.

One of the important sides of technical SEO shows up right here:

It’s not about finding the problem, it’s about deciding which problem should be solved first.

27. Speed work isn’t a one-time job

New features get added to the site. New ad tools come in. New tracking code gets added. A new design is made. New images are uploaded. Plugins change.

So a site that’s fast today can slow down again six months later. Especially on large projects, performance needs to be monitored periodically.

So how do I look at site speed in the end?

I think from three different angles:

1. What does the user feel?

Does the page load fast, does it respond quickly to clicks, does the content shift?

2. Technically, where is the problem?

Is it the server, the images, JavaScript or a third-party script?

3. Is it worth solving from a business point of view?

Will this improvement really contribute to the user, to conversion and to SEO?

I think the biggest mistake with site speed isn’t just forgetting the third question; it’s forgetting the first one too.

You need to avoid losing the user while improving the PageSpeed score.

The goal isn’t a score of 100. It’s a website that’s fast, stable, usable and does its job.

Previous: Chapter 23: How Does Google Crawl Sites? · Contents · Next: Chapter 25: How Can Google Understand Your Page Better?

This chapter was first published in Turkish on X (September 28, 2026).