Slow website: systematically finding the causes

A slow website can have many causes. Large images, complex JavaScript, slow database queries, external services, a lack of caching, or delayed server-side processing can all manifest in a similar way.

Therefore, it rarely makes sense to blindly change settings or install various optimization plugins without a diagnosis.

The better way is systematic troubleshooting: first, it is determined, I the delay occurs. Subsequently, the technical cause is narrowed down, and only then is a targeted change implemented.

In this guide, we will show you step by step how to handle a slow website and how to differentiate between typical causes.

Briefly explained: „The website is slow is initially just a symptom. For meaningful optimization, you need to find out whether the delay originates at the server, in the browser, with individual resources, in the application, or with an external service.

What does „slow website“ actually mean? #

Visitors can perceive speed in different ways.

For example, one page might remain blank for a long time before anything appears at all. On another website, the content becomes visible quickly, but a large image appears much later. Yet another page loads visually fast, but responds with a delay to clicks.

These situations can have completely different technical causes.

Case A
→ Server responds late

Case B
→ Main content appears late

Case C
→ Large resources load slowly

Case D
→ Page reacts slowly to interactions

Case E
→ External function is delayed

Case F
→ Problem occurs only occasionally

Therefore, before you optimize, you should be able to describe as accurately as possible, what is actually slow.

First measure, then optimize #

The first step is a reproducible initial measurement.

If you only work by intuition, you can hardly judge later whether a change actually helped.

Therefore, test a specific URL multiple times and document the most important results.

We explain how to carry out such measurements sensibly at Measure website loading time and evaluate it correctly.

Practical Tip: Before making a change, note down at least the tested URL, device type, measuring tool used, and the noticeable metrics. After that, you can repeat the same test.

Not only test the homepage #

A fast home page does not automatically mean that the entire website is fast.

Therefore, test the page where the problem actually occurs.

For example, in an online shop, the product page, shopping cart, and checkout can work very differently from a technical standpoint.

Home page fast
Product page slow

→ Problem likely not across the entire website

That is already a valuable hint for further diagnosis.

Is the entire website slow, or just one page? #

Open multiple different pages of the same website.

If all pages are similarly slow, overarching causes are more likely. If, on the other hand, only a specific URL or a particular type of page is affected, you should first examine its specific characteristics.

Examples:

all pages slow
→ server-side processing?
→ global scripts?
→ theme?
→ external services?
→ general configuration?

only product pages slow
→ shop functions?
→ product images?
→ variants?
→ database queries?
→ additional scripts?

only a single page slow
→ specific content?
→ embedded video?
→ slider?
→ external API?
→ unusually large resources?

Is the website always slow or only sometimes? #

The chronological progression is also important.

A permanently slow website may have a different cause than a page that is normally fast and only occasionally responds very slowly.

For sporadic issues, external services, background processes, load spikes, or temporary network problems can play a role, for example.

Therefore, perform multiple measurements at different times if the problem does not occur constantly.

Distinguish between frontend and backend #

For troubleshooting, a rough separation between server-side processing and browser-side processing is helpful.

BACKEND / SERVER

Request
   ↓
Web server
   ↓
PHP / Application
   ↓
Database
   ↓
HTML response


FRONTEND / BROWSER

HTML
   ↓
CSS
   ↓
JavaScript
   ↓
Fonts
   ↓
Images
   ↓
Rendering and interaction

A website can be generated quickly on the server side and still appear slow in the browser afterwards.

Conversely, a very thin frontend can wait for a server-side response that takes a long time.

TTFB as the first clue #

The Time to First Byte, or TTFB for short, can provide a first indication of how long it takes for the first byte of the response to arrive.

However, a high TTFB does not automatically mean that only the web server is slow.

The value can be influenced by the network, connection establishment, server-side processing, and other factors, among other things.

We discuss the meaning of such measured values in more detail under Measure website loading time and evaluate it correctly.

If even the HTML response takes a long time #

If the browser waits a long time for the actual document response, you should first investigate the server-side or application-side area.

Possible causes can be:

• complex PHP processing,
• slow database queries,
• external API queries,
• missing or ineffective caching,
• faulty extensions,
• resource-intensive background processes.

Only when it is clear which area actually requires time can meaningful further work be done.

A high TTFB does not automatically mean bad hosting #

The cause of a slow server-side response can lie within the website application.

For example, a WordPress plugin can perform complex database operations or wait for an external service on every page load.

More server performance can sometimes mitigate inefficient behavior, but it does not automatically eliminate its cause.

Important: Do not judge hosting performance based on a single TTFB value. First, it must be clarified which part of the request is causing the delay.

Examine PHP and the application #

Dynamic websites often generate content using PHP or a comparable server-side application.

In WordPress, for example, WordPress itself, the theme, plugins, and database are involved.

Slow PHP processing can have various causes:

complex plugin code
too many or inefficient database queries
external HTTP requests
large amounts of data
faulty processes
unsuitable configuration
outdated software
resource-intensive functions

The sheer number of installed plugins is not a reliable measure of quality.

Many plugins do not automatically mean a slow website #

The statement „too many plugins make WordPress slow“ is too general.

A single poorly coded or resource-heavy plugin can cause more performance issues than several lightweight extensions.

Therefore, what matters is not only:

How many plugins are installed?

Rather:

What do these plugins do on a page view?

Do not disable plugins randomly on the live website #

If a plugin is suspected to be the cause, the inspection should be carried out in a controlled manner.

Indiscriminately disabling extensions on a production website can impair functionality or render an online shop unusable.

For more extensive testing, a staging or test environment is therefore often the better choice.

Attention: Create a current backup before major changes. For shops, member sites, or other dynamic websites, it must also be taken into account that new data can be generated between the backup and the restoration.

Database as a potential cause #

Many dynamic websites access a database on every page view.

For example, very complex queries, large amounts of data, or poorly optimized extensions can be problematic.

In WordPress, plugins, themes, or custom functions, among other things, can trigger database queries.

However, a database problem should be diagnosed and not assumed solely based on the size of the database.

A large database is not automatically slow #

The file size or amount of data in a database alone says little about the actual query performance.

Crucial factors include which data is queried and how efficiently this is done.

That is why:

Large database → Slow database

no reliable conclusion.

External API requests on the server #

A website can contact other systems during server-side processing.

Examples are:

payment services
external APIs
license server
CRM systems
shipping services
external data sources

If such a request has to be awaited synchronously and the external service responds slowly, this can also delay your website's response.

The problem then does not have to be on your own web server.

Check caching #

Caching can significantly reduce server-side work if already generated content or results can be reused.

Which cache types make sense depends on the respective website and application.

Simplified, different levels can be involved:

Browser Cache
Page Cache
Object Cache
Opcode Cache
CDN / Edge Cache

These systems perform different tasks and should not simply be regarded as a single „cache.“.

Caches are not equally suited for all content #

A public static content page can be treated differently than a personalized customer area or a shopping cart.

For dynamic ranges, it must therefore be precisely defined which content may be cached.

An aggressive cache can improve performance, but if misconfigured, it can also deliver outdated content or content intended for the wrong user.

Clearing the cache is not a permanent optimization #

„Clearing the cache is often recommended as a universal troubleshooting solution.

Clearing a cache can be useful in the case of outdated or faulty cache contents. However, it does not automatically eliminate the cause of a slow website.

After emptying, certain cache contents must also be rebuilt first.

When the server responds quickly, but the page still feels slow #

Then you should examine the browser-side part more closely.

Typical candidates are:

large images
too much transferred data
JavaScript
CSS
web fonts
videos
external services
third-party widgets
unfavorable loading priorities

Google PageSpeed Insights can help identify such issues. We explain how to use and interpret it at How to use Google PageSpeed Insights correctly.

Images as a performance cause #

On many websites, images are among the largest resources transferred.

A typical mistake, for example, is uploading a photo that is several thousand pixels wide, even though it is displayed much smaller on the website.

Inappropriate compression or an unsuitable file format can also cause unnecessarily large files.

We explain how to prepare images effectively at Optimizing images for the web: file size, format and SEO.

Distinguish between pixel dimensions and file size #

An image has both dimensions and a file size.

Example:

Dimensions:
4000 × 2667 pixels

File size:
5.8 MB

Both properties can be relevant for performance.

Therefore, simply using a modern file format without reducing unnecessarily large dimensions is not always sufficient.

Use the correct image format #

WebP and AVIF can enable significantly more efficient compression than older formats for suitable images.

PNG, on the other hand, remains useful, for example, when specific features such as lossless graphic rendering or transparency are required.

We explain which format makes sense for which application at WebP, AVIF, JPG and PNG: Which image format to use?.

Using Lazy Loading correctly #

Lazy loading can prevent images far outside the viewport from loading immediately.

This may reduce unnecessary data transfer on the first page load under certain circumstances.

For an important image in the above-the-fold area, however, inappropriate lazy loading can delay the time at which this image is rendered.

Especially in the case of an LCP image, it should therefore be checked whether its loading behavior is configured sensibly.

You can find more about this at Core Web Vitals Explained: LCP, INP and CLS.

JavaScript as a possible cause #

JavaScript enables interactive and dynamic functions, but must be loaded, processed, and executed by the browser.

For example, very extensive code or long-running work on the main thread can be problematic.

Possible sources are:

Themes
Plugins
Page Builder
Tracking
Animations
Slider
Chat
External Widgets
Marketing Scripts

The correct solution is not automatically to completely remove JavaScript. First, it must be clarified which code is actually relevant.

Properly interpreting unused JavaScript #

Performance tools may report that parts of a JavaScript file were not used during the analyzed page load.

This does not automatically mean that the complete file may be deleted.

For example, a script might only be needed after user interaction or on another subpage.

Such indications are starting points for an analysis, not automatic deletion instructions.

Delaying JavaScript: Caution with automatic optimizations #

Certain performance solutions can load or execute JavaScript with a delay.

This can help in appropriate cases, but it can also impair important functions.

Therefore, after such changes, you should specifically test:

Navigation
Forms
Cookie banner
Slider
Search
Login
Shopping cart
Checkout
Payment functions
Mobile menus

CSS can delay rendering #

CSS determines the visual appearance of a website.

Certain stylesheets may be required for rendering before the browser can display the page correctly.

Performance tools can therefore point out render-blocking CSS resources.

The same applies here: A displayed file must not simply be removed. Without the required CSS, the website may be displayed incorrectly or initially unformatted.

Unused CSS does not automatically mean an unnecessary file #

A global stylesheet can contain rules for numerous page types.

On a single tested URL, only some of these may be needed.

Therefore, the analysis tool may report unused CSS even though the corresponding rules are needed on other pages.

Therefore, optimization should always be done in the context of the entire website.

Inspect webfonts #

Webfonts can cause additional network requests and rendering effects.

A website often does not need every conceivable font weight and font style.

For example, if numerous font files are loaded even though only a few variants are actually used, unnecessary overhead is created.

Therefore, check which fonts and font weights are really needed.

External fonts #

If fonts are loaded from an external provider, an additional external connection is added.

Locally hosted fonts can offer advantages in certain configurations, but they must also be correctly integrated and optimized.

The decision should not be made solely on the basis of the number of requests.

Videos can generate significant amounts of data #

Directly embedded or auto-playing videos can cause large amounts of data.

Even embedded video platforms can load additional scripts, frames, and external connections.

If videos slow down a page, it should be checked whether they are needed completely on the initial page load or if a lighter preview solution is possible.

Investigate third-party services #

Many modern websites load resources from other providers.

This includes, for example:

Analytics
Tag Manager
Social Media Feeds
Maps
Videos
Chat Systems
Review Services
Advertising Systems
Marketing Tools

These resources are partially outside your direct control.

If a third party is slow to respond or executes extensive code, it can impact website performance.

Consider the business value of external services #

Technical optimization must not be viewed in isolation from the website's functionality.

For example, a necessary payment service cannot be removed just because it requires additional resources.

In the case of a rarely used social media widget, the trade-off may look different.

A meaningful question is:

Is the benefit of this feature large enough for the additional technical costs?

Use browser developer tools #

The developer tools of modern browsers can show which resources a website loads and how long individual requests take.

The network view is especially helpful.

There, for example, you can see:

HTML document
CSS files
JavaScript
Images
Fonts
API requests
external resources
HTTP status codes
transferred data volumes
load times of individual requests

Read a waterfall view #

A waterfall view shows the chronological sequence of the loaded resources.

Simplified:

HTML        ███████
CSS            █████
JavaScript      █████████
Font              ██████
Hero Image            ███████████
API                       █████████

This allows you to see, for example, if an important resource is discovered late or if an external request takes an unusually long time.

Do not just look at the number of requests #

A page with 100 HTTP requests is not automatically slower than one with 50.

Crucial factors include, among others:

Resource size
Caching
Loading priority
Dependencies
Transmission protocol
Browser processing
Source response time

Therefore, the number of requests is only part of the analysis.

Check total page size #

The amount of data transferred can be relevant, especially with mobile connections.

If, for example, a simple content page transfers many megabytes, it is worth investigating the largest resources.

Often images, videos, fonts, or large JavaScript files are involved.

However, the overall size should be evaluated in the context of the page type. Naturally, an image gallery requires more data than a pure text page.

Use Core Web Vitals as a diagnostic indicator #

Core Web Vitals can help narrow down the type of performance issue.

Abnormal value	First question
LCP	Why does the important main content appear so late?
INP	Why is the page reacting slowly to interactions?
CLS	Why do page elements shift unexpectedly?

We will cover the exact meaning and diagnosis of these values under Core Web Vitals Explained: LCP, INP and CLS.

Desktop fast, mobile slow #

If a website works well on desktop but performs significantly worse on mobile devices, you should not automatically assume it is a measurement error.

Mobile devices may have less processing power and access via slower or more unstable network connections.

Particularly extensive JavaScript and large amounts of data can become more noticeable under such conditions.

Test the website on a real smartphone #

Therefore, alongside synthetic measurements, a practical test is always worthwhile.

Open important pages on a smartphone and actually use them.

Pay attention to, for example:

Does the main content appear quickly?

Does the menu work immediately?

Do buttons respond?

Does the layout shift?

Do images load noticeably late?

Do forms respond quickly?

Does the checkout work?

A technical score does not replace the actual usage of the website.

Distinguish between logged-in and logged-out visitors #

With content management systems, the website can behave differently for a logged-in administrator than for regular visitors.

Certain caching mechanisms are not used for logged-in users, for example.

Therefore, also test the public website in a private browser window where you are not logged in.

Is only the WordPress admin area slow? #

If the public website is fast, but the administration area responds slowly, it is a different error pattern.

Then you shouldn't primarily investigate images or frontend caching.

Possible causes may include, for example, plugins, external API calls, database operations, or background processes within the application.

In this case, the diagnosis should focus on the administration area.

WooCommerce and dynamic pages #

Online stores have areas that cannot be treated like regular public content pages.

Shopping cart, customer account, and checkout contain dynamic or user-specific information.

A cache configuration that works for a blog post may be unsuitable for such pages.

Attention: Only make controlled changes to cache and JavaScript settings in a live online shop. Afterwards, fully test the shopping cart, login, checkout, and payment process.

Consider background processes #

Backups, imports, exports, cron jobs, image processing, or other background tasks can consume resources.

If performance issues always occur at specific times, you should therefore check whether recurring processes are running in parallel.

A single test during a large-scale import may not be representative of normal operation.

Check error logs #

In case of unusual behavior, error logs can provide important clues.

Recurring PHP errors, timeouts, or other messages can indicate a specific problem.

However, a log should not be judged solely by the number of entries. The decisive factors are the timing, type, and connection to the observed performance problem.

HTTP errors are not the same as slow performance #

When a resource responds with an error status, it is no longer exclusively a performance issue.

Examples:

403 → Access denied
404 → Resource not found
500 → Internal server error

We explain the most important status codes at HTTP status codes explained: 200, 301, 404, 403, and 500.

Distinguishing between DNS problems and performance problems #

If a domain does not resolve correctly at all, it is initially a DNS or reachability problem and not an ordinary slow website.

Such errors can also seem subjectively to visitors like „the website is not loading“.

Therefore, an accurate error description is important.

HTTPS issues can also look different #

Faulty certificates, mixed content, or other HTTPS issues must also be distinguished from a purely performance-related disruption.

We will cover the corresponding diagnosis later under Check SSL Certificate and HTTPS: Identify Common Errors.

Server resources and limits #

Web applications require computing time, memory, and other resources.

If available resources or defined limits are reached, this can affect processing.

However, the cause should be investigated here as well.

For example, if a faulty plugin consumes an extreme amount of resources, simply increasing the limit may only be a short-term treatment of the symptoms.

More power is not always the solution #

A more powerful plan or server can make sense in the event of an actual resource bottleneck.

However, it should not be used as the first standard response to every performance issue.

Website slow
      ↓
Determine cause
      ↓
Actual resource bottleneck?
      ↓
YES → Evaluate resource requirements

NO → Fix technical cause

CDN: useful, but no panacea #

A content delivery network can deliver certain static resources via geographically distributed systems and thus offer advantages, in particular for spatially widely distributed target audiences.

However, a CDN does not fix inefficient PHP code or slow database queries.

Here, too, the measure must be appropriate for the actual bottleneck.

Consider visitor location #

Network latency depends, among other things, on the distance and route over which data is transmitted.

If the target audience of a website is predominantly in Switzerland and Central Europe, performance should not be assessed solely on the basis of a test location on another continent.

To ensure reproducible comparisons, test conditions that are as similar as possible should be used.

Is the website really slow or just your connection? #

Your local Internet connection, a VPN, Wi-Fi issues, browser extensions, or even a single device can also affect the results.

If only you notice a problem, you should therefore double-check.

For example:

different browser
private browser window
different device
mobile data instead of Wi-Fi
disable VPN for testing
different internet connection

If the behavior changes significantly, it may not be a general website issue.

Differentiate performance and availability #

A website that is occasionally completely inaccessible doesn't just have a loading time problem.

If an error occurs sporadically, continuous monitoring can help determine when and how often the website was actually unavailable.

We will cover that under Website Monitoring: Monitor Availability and Outages.

Don't use five optimization plugins at the same time #

Multiple performance plugins with overlapping functions can lead to interactions that are difficult to trace.

For example, if multiple systems handle caching, minification, lazy loading, and JavaScript optimization simultaneously, troubleshooting becomes unnecessarily complicated.

A clearly documented configuration is better than having as many optimizations active at the same time as possible.

Do not change ten things at the same time #

For a systematic diagnosis, you should make changes in a traceable manner.

If you disable plugins, replace images, change caching, alter PHP, and defer JavaScript all at once, you won't know afterward which measure had which effect.

Better:

measure
  ↓
formulate a hypothesis
  ↓
make a specific change
  ↓
test
  ↓
measure again
  ↓
document the results

Test functions after performance changes #

A website is not optimized if it loads faster, but important functions no longer work correctly.

After technical changes, you should therefore check not only the measured values but also the actual function.

Take a typical company website, for example:

Navigation
Contact Form
Search
Mobile View
Cookie Banner
Interactive Elements

Additionally in a shop:

Product Variants
Shopping Cart
Gift Certificates
Customer Account
Checkout
Payment

When should you involve professional help? #

If the cause cannot be clearly identified using standard measurement tools, a more in-depth technical analysis may be necessary.

This is especially true for:

sporadic, extremely long response times
recurring timeouts
>500 errors
high database load
complex store issues
external API dependencies
issues that occur only under high load
errors that are difficult to reproduce

In such cases, server and application logs, profiling, or other diagnostic tools may be required.

A Sensible Diagnostic Approach #

Website seems slow
        ↓
Reproduce the problem
        ↓
Determine affected URL
        ↓
Only one or all pages?
        ↓
Permanent or sporadic?
        ↓
Measure multiple times
        ↓
Server-side response noticeable?
        ↓
YES
→ PHP / Application / Database
→ External APIs
→ Cache
→ Background processes
→ Check resources

NO
→ Examine browser / frontend
→ Images
→ CSS
→ JavaScript
→ Fonts
→ External resources
        ↓
Check Core Web Vitals
        ↓
Identify specific bottleneck
        ↓
Make one targeted change
        ↓
Test website functionality
        ↓
Measure again under comparable conditions

Diagnosis Based on Symptoms #

Symptom	First test area
The page remains blank for a long time at first	HTML response, TTFB, server-side processing
The main content appears very late	LCP element, images, fonts, blocking resources
Clicks are delayed	INP, JavaScript, Main Thread
Elements jump while loading	CLS, images, fonts, dynamic content
Only one page is slow	site-specific resources and functions
Only shop pages are slow	dynamic shop processes, database, plugins
Only occasionally slow	Monitoring, external services, background processes, load
Only for you, slowly	Device, browser, network, VPN

Common mistakes in performance troubleshooting #

immediately blame the hosting
run only a single test
test only the homepage
equate performance score with load time
disable all plugins at once
install multiple caching systems on top of each other
treat clearing the cache as a permanent solution
blindly implement every PageSpeed recommendation
delay JavaScript without checking
lazy load all images across the board
equate database size with database speed
test desktop only
ignore external services
make multiple changes at once
check only the score after making changes and not the website itself

Checklist: Systematically investigate a slow website #

Which URL is slow?
        ↓
Are other pages affected?
        ↓
Is the problem permanent or sporadic?
        ↓
Tested on mobile and desktop?
        ↓
Multiple measurements taken?
        ↓
HTML response / TTFB anomalous?
        ↓
Check PHP / application
        ↓
Check database
        ↓
Check external APIs
        ↓
Check caching
        ↓
Check images and data volume
        ↓
Check JavaScript
        ↓
Check CSS
        ↓
Check fonts
        ↓
Check third-party resources
        ↓
Analyze Core Web Vitals
        ↓
Narrow down the specific cause
        ↓
Make one change
        ↓
Test the website completely
        ↓
Measure again
        ↓
Document the result

Summary #

A slow website can have many different causes. Therefore, „making a website faster“ is not a single technical measure, but rather a diagnostic task first.

First, determine whether the problem affects the entire website or only specific pages, and whether it occurs permanently or only sporadically. Afterwards, you should distinguish between server-side processing and browser-side performance.

If a server response is slow, potential causes include PHP, the application, the database, external APIs, caching, and background processes, among others. If the server responds quickly, you should focus your investigation more on images, JavaScript, CSS, fonts, and external resources.

Measurement tools like PageSpeed Insights, browser developer tools, and Core Web Vitals help narrow down a bottleneck. However, their advice should not be blindly interpreted as automatic optimization instructions.

Perform changes in a controlled manner, then test the actual functionality of the website and measure again under comparable conditions.

Therefore, the most important rule for a slow website is not „optimize more,“ but rather: first reproduce the problem, then identify the bottleneck, and finally fix the exact cause that is actually responsible for the delay.