Skip to Main Content

Why Is My Website So Slow?

CodeGeek's mascot monkey Randall is sitting on top of a snail and moving very, very slowly.

If you have a website, you may have asked yourself, “Is it fast enough?”

But before you go down the speedster rabbit hole, it’s important to ask yourself a few questions first:

  1. Do you know what “fast enough” is?
  2. How will you know when your site gets there?
  3. What if you could make your site even faster than “fast enough”? That would be better, right?

In the recent past, we’ve had clients ask themselves these same questions because they received an email from their hosting provider.

This email suggested that their website could be X times faster if they simply installed a magical site optimization plugin.

So, should they do it? (If you can’t wait for the answer, skip to the end.)


Why does site speed matter?

An adult cheetah has its ears pulled back and is running at top speed while a cub looks on
Image credit: Sammy Wong

Site speed is critical for the success of almost every part of a user’s web journey.

–> From search to retention to conversion, sites that load quickly and are responsive to user actions will engage and retain users better than sites that are slow and laggy.

1. Search

Site speed is important for search engine optimization (SEO) and user acquisition. Google has modified their search-results-ranking algorithm to favor sites that perform well—and penalize sites that are slow.

So if you want potential customers to find your website, it needs to perform well. Really well.

2. Retention and conversion

Once potential customers find your website, however, you want them to stay.

–> Site speed (or lack thereof) can have an impact on keeping visitors on your website and, hopefully, turning them into actual customers.

The BBC did a study on their own website back in 2016 and discovered that for every additional second a page takes to load, 10% of users leave.

And now that it’s 2024, load-time stats have gotten even more clear that we all have the need for (more and more) speed.

  • 25% of visitors would abandon a website if it takes more than four seconds to load.
  • 74% of mobile users in the U.S. would leave a site if it didn’t load within five seconds.
  • 82% of consumers say slow page speeds impact their purchasing decisions.

What can make a website slow?

A tab snail with a darker brown shell moves ever so slowly on a reddish rock
Image credit: Zdeněk Macháček

There are myriad factors that contribute to a website’s performance—some you can control and some you can’t.

Some things you can control:

  • content (images, video, text, etc.)
  • platform (WordPress, Squarespace, other CMSs)
  • plugins and theme code

Some things you can’t control (at least not much):

  • user’s internet speed
  • server load
  • database and site complexity

–> When it comes to loading a single webpage, all these factors can impact the speed at which you see your desired page load onto your screen.

At this point, you may want to jump right to fixing the things you can control (which we dive into in part 2 of this blog post series).

However, it’s important to first talk about the steps involved in delivering a webpage to your computer—all 10 of them.


How does a single webpage load—and why can it take so long?

Looking down at an open game board for Chutes and Ladders
Image credit: Mercari

To understand why it might take so long to load a single page, let’s look at what happens when you click a link or enter a URL into your browser.

A webpage’s journey from point A (its origin) to point B (your screen) can feel very much like a game of Chutes and Ladders.

Depending on your network environment and available caching, the steps can either be straightforward or somewhat maze-like.


A webpage’s journey

Step 1 – Local cache check

Before anything else, your browser will check its local cache.

Have you visited the site before? If so, your browser will know. And if you’re lucky, it will have saved a copy of the page from your last visit.

If so, jump to step 9! Otherwise, continue on to step 2.

Step 2 – DNS lookup

The browser will send the request to your computer, which will examine the link to see if it’s a website that it knows about already (one that you or another user has visited in the past).

If so, huzzah! you can skip ahead to step 4. Otherwise, it’s on to step 3.

Step 3 – DNS resolution

Too bad—you haven’t been to this website before. For those old enough to get the reference, your computer now pulls out the Yellow Pages and looks up the number you’re trying to reach (a.k.a. the IP address).

This requires one or more requests sent out to the web just to see if anyone knows where the site is (specifically, a domain name server or DNS).

If a DNS resolution fails, a message will pop up that may say “DNS server not available” or “Server DNS Address could not be found.” It’s like dialing a phone number and getting back a busy signal.

If a DNS resolution succeeds, yippee! You’re on to step 4.

Step 4 – Website contacted

Your computer now knows how to contact the site (via its IP address), so it sends out an HTTP request packet to the IP address and waits for a response.

Move on to step 5 and/or 6.

Step 5 – Network cache check (optional)

If you’re in a managed IT environment with network-level caching, then your outgoing request is next checked against the network cache. (If that’s not you, move on to step 6.)

If the network has stored the page, it will serve it up for you and you can jump to step 9. Otherwise, continue on to step 6.

Step 6 – CDN cache check

Your request finally hits the network and is routed to the machine that is expected to service the request.

If the website is using a CDN (Content Delivery Network) like Cloudflare, then the CDN receives this request and will reply with its cached version of the page (assuming it has it cached).

A gray and teal line illustration of a CDN
Image credit: WP Engine

Keep in mind that some pages are not cacheable, such as dynamically generated pages including user profiles, shopping carts, gated content that requires a login, etc.

If the page is cached, skip to step 9. If the page is not cached or not cacheable, then continue on to step 7.

Step 7 – Server side cache check

The website’s host has finally received the request! (Remember step 4: Website contacted?)

If your host has server side caching enabled, then it will be checked to see if the page can be served from that cache.

The purpose of the server cache is to reduce load and latency by remembering recent page fetches and serving them again rather than having to go through the effort of rebuilding the page from scratch (or, technically, from the database).

Illustration demonstrating the path a server can take to serve up content, with and without a server side cache
Image credit: WP Engine

Server side caching can be included in a hosting plan (such as WP Engine) or can be added as a plugin (more on those in part 2 of this blog post).

If the server gets a hit, then skip to step 9. If it doesn’t, then on to step 8 we go.

Step 8 – Page building from scratch via the CMS (part 1)

This is the step where the CMS that is running the site finally gets to do its thing—and the step that all those previous caches were trying to avoid.

Some CMSs are lean while others try to be everything to all people. (WordPress falls into that latter category.)

Building a page from the database requires the execution of tens of thousands of lines of code (or more if you have lots of plugins installed) and hundreds or thousands of database fetches.

It’s eye-opening (or eye-watering) when you see how many requests there really are. All this code, execution and data is just to generate the HTML which is sent back to the browser that made the request.

–> Extra credit: For your enjoyment, try installing the query monitor plugin on a site sometime. It will track each and every database request for a single page load and allow you to see where the request is coming from and what data is being returned.

Move on to step 9.

Step 9 – Page building from scratch via the CMS (part 2)

Your browser has received the HTML, and now it can render the page. We’re almost there!

But wait: The HTML doesn’t contain code, images, styling or any other external resources. It just contains URLs that point to those things. Before we can render the page, we need all those other things.

–> For each external item in your HTML, jump back to step 1 and start over again.

And by “each external item,” we mean every tracking or analytics script, every stylesheet, every image, and every font.

A single page load can result in hundreds of additional requests, each of which has to go through all these steps.

Once each external item is fetched, it’s on to step 10.

Step 10 – Page loads (ta-da!)

After all the resources are loaded, then the page scripts finally get to start running in the browser.

–> It’s important to remember that if you load lots of scripts (tracking tags, CRM trackers, widgets, plugins, etc.), then each one will take additional time to run, which will slow down the page rendering.

Considering all these steps, it’s amazing that a page can load in under a minute, let alone just a few seconds.

Hopefully, this helps explain just how much work your computer has to do to load a web page—and how quick it actually is!


Let’s test it out.

So, are you ready to play your own game of “Chutes and Ladders: Site Speed Edition”?

  1. Select a link or URL you want to visit.
  2. Place that link into your browser and hit “return.”
  3. Count the seconds it takes for the page to appear on your screen.

How did it do?

  • If it took more than four seconds to fetch the (potentially) hundreds of resources and get them to run and render on your screen, then the site is considered slow.
  • More than six seconds and the site is very slow—and it needs work.
  • 10 seconds = Game over.

Is there a silver bullet to improving your site speed?

A silver bullet shoots through the air as blue and purple flames follow from behind
Image credit: Heather Hall

So, let’s go back to that magical site optimization plugin that our clients were offered at the beginning of this post.

Should they install it?

If you put your own website through the test above and it didn’t pass, it’s very tempting to install a plugin that promises to solve all your performance problems.

But as web professionals, we beg you not to install plugins willy-nilly.

  • Plugins are created by third-party developers, and not everyone (or everything) talks to each other.
  • This means that there is always the potential for a plugin to break something, which could mean taking down your website. (True story.)
  • If you do decide you want to go the plugin route (this is a good one), it’s best to chat with a web developer first so you know what your options—and risks—are.

Instead, we recommend a different approach first, which is to address the things you can control when it comes to improving your site speed.

What does that mean?

–> Essentially, the silver bullet to helping make your website load faster is you.

And with that, let’s head on over to part two of our blog post for 5 things you can do on your own to improve your website’s load time.


Want to learn about 5 ways to make your website load faster?