When a Drupal page takes more than a minute to load, it is easy to assume that Drupal itself is slow.

Sometimes it is.

But a slow Drupal page can also be a perfectly reasonable HTML response surrounded by tens of megabytes of images, JavaScript, CSS, fonts, maps and third-party resources.

We recently looked at a Drupal page where the browser reported approximately:

• 21.5 MB transferred
• 42.5 MB of resources
• 15 seconds to DOMContentLoaded
• more than a minute before the load event
• around 1 minute 40 seconds before all network activity finished

Those numbers immediately tell you something important.

This is not simply a question of making Drupal render the HTML a little faster.

The page is far too heavy.

Start with the browser, not Drupal

When a Drupal page feels slow, one of the quickest mistakes is to start changing Drupal:

• clearing caches
• disabling modules
• rebuilding CSS and JavaScript
• changing PHP settings
• tuning the database

Those things may eventually matter.

But first, open the browser developer tools and look at the Network panel.

You want to know:

What is the browser actually downloading?

A page that transfers 20 MB has a completely different problem from a page that transfers 800 KB but takes ten seconds before Drupal produces the first byte.

Both pages feel slow.

The causes are very different.

"Transferred" and "resources" are not the same thing

Browser developer tools often show more than one size.

In our example, about 21.5 MB was transferred, while the total resource size was approximately 42.5 MB.

That difference is normal.

Transferred size reflects what travelled over the network, often after compression.

Resource size is closer to the amount of data represented once resources are decompressed or otherwise processed.

The important point is not the exact relationship between the two numbers.

It is that both were enormous for a normal web page.

Even on a fast connection, downloading and processing that much material takes time.

On a mobile connection it can be substantially worse.

Find out what is actually large

Sort the Network panel by Size.

This often identifies the problem immediately.

Typical large resources include:

• photographs
• background images
• image sliders
• video
• PDF previews
• maps
• large JavaScript bundles
• third-party widgets
• externally hosted fonts
• tracking and marketing scripts

Images are particularly common.

A page may visually display an image at 600 pixels wide while the browser is downloading a 4,000-pixel original photograph weighing several megabytes.

Do that ten times on one page and you can easily create a 20 MB page without Drupal itself doing anything particularly unusual.

Drupal can serve the wrong image very efficiently

Caching does not fix an oversized image.

If Drupal serves a 5 MB photograph from cache in 20 milliseconds, it is still a 5 MB photograph that has to travel across the network and be decoded by the browser.

That distinction matters.

Server performance answers:

How quickly can we produce the resource?

Page weight answers:

How much are we asking the visitor to download?

A site can perform well according to the first measure and badly according to the second.

Check whether responsive images are actually responsive

Drupal has strong support for image styles and responsive images.

But those features only help if they are configured and used correctly.

An image uploaded at 5,000 × 3,000 pixels should not normally be sent unchanged to a small content card.

Ideally, Drupal should generate appropriately sized derivatives and the browser should receive a version suited to the display size and device.

Things worth checking include:

• whether image styles are being used
• whether templates output original files directly
• whether srcset is present where appropriate
• whether mobile devices receive unnecessarily large desktop images
• whether uploaded images are being compressed sensibly
• whether modern image formats are available

A single badly implemented hero image can account for several megabytes.

A page full of them becomes painful very quickly.

Lazy loading only helps if it is used in the right places

Not every image needs to be downloaded when the page first opens.

Images well below the visible part of the page can often be lazy-loaded.

That means the browser waits until the visitor approaches them before requesting the files.

This can significantly reduce the amount of data required for the initial page view.

But lazy loading is not an excuse for oversized images.

Loading a 4 MB image later is better than loading it immediately, but it is still a 4 MB image.

The strongest solution is usually:

correct dimensions + compression + responsive delivery + appropriate lazy loading

rather than relying on any one technique.

Look for things being loaded twice

Large pages sometimes contain duplication rather than one obviously enormous resource.

Drupal themes, modules and third-party integrations can each attach their own libraries.

It is worth checking whether the page is loading:

• multiple versions of the same library
• the same font in several weights that are never used
• JavaScript for components that do not exist on that page
• several analytics or tracking packages
• duplicate CSS
• multiple mapping libraries
• scripts from modules that have been disabled visually but are still attached

A few hundred kilobytes here and there can add up.

More importantly, each additional script may need to be parsed and executed.

So network size is only part of the performance cost.

A page can finish downloading and still feel slow

The Network panel gives several different timings.

They mean different things.

Initial server response

How long did it take the server to start returning the page?

If this is very slow, Drupal, PHP, the database or the server may be responsible.

DOMContentLoaded

This occurs after the initial HTML has been downloaded and parsed sufficiently for the document structure to be ready.

In our example, this was taking around 15 seconds.

That is already far too long for an ordinary page.

Load

This waits for additional page resources such as images and other dependencies.

The affected page took more than a minute to reach this point.

Finish

The Network panel can continue showing activity after the page's load event.

Our example was still making requests roughly 1 minute 40 seconds after navigation began.

That strongly suggests the browser is doing a lot more than simply waiting for Drupal to return HTML.

Third-party services deserve suspicion

Drupal sites often become progressively heavier as services are added over time.

A site may accumulate:

• Google Analytics
• Tag Manager
• embedded maps
• social media feeds
• cookie consent tools
• accessibility widgets
• live chat
• advertising scripts
• booking systems
• CRM forms
• external video players
• tracking pixels

Each addition may look insignificant in isolation.

Together they can create a large chain of additional HTTP requests and JavaScript execution.

Third-party scripts are also outside your direct control.

One slow external service can delay part of the page even if your Drupal server is performing perfectly.

The Network panel's Domain column can be very revealing here.

If much of the page is being loaded from domains you do not control, Drupal optimisation alone is unlikely to solve the problem.

Don't overlook fonts

Web fonts are rarely responsible for a 20 MB page by themselves, but poorly configured fonts can still contribute unnecessary weight and delay text rendering.

Common problems include:

• loading many unused font weights
• loading both variable and static versions
• requesting the same font from more than one service
• loading fonts for icon libraries that are barely used

If the design uses two font families with five weights each, ask whether all ten files are really necessary.

Usually they are not.

Maps can be unexpectedly expensive

Interactive maps can generate substantial network activity.

The JavaScript library itself may be small, but the map can then request:

• map tiles
• marker images
• clustering resources
• data feeds
• geolocation services
• external APIs

If the map appears far down the page, it may not make sense to initialise and download everything immediately.

For some pages, loading the map only when the user reaches it can materially improve the initial experience.

Again, the Network panel will show whether this is actually a problem rather than leaving you to guess.

Check the number of requests as well as their size

A page does not have to contain one giant file to perform badly.

It may instead contain hundreds of smaller ones.

Look at both:

Total transferred size

and:

Number of requests

A site making several hundred requests may suffer from:

• excessive module libraries
• third-party integrations
• numerous images
• font variants
• icon packs
• AJAX calls
• external APIs

Modern browsers are good at parallel downloads, but there is still a cost to creating, scheduling, parsing and processing all of those resources.

Then check Drupal's response time

Once you understand the front-end weight, look separately at how quickly Drupal generates the initial document.

The HTML document request in the Network panel is particularly useful.

If the HTML response itself takes several seconds before anything arrives, there is probably a server-side problem as well.

That investigation might involve:

• PHP execution
• database queries
• Drupal Views
• cache configuration
• external API calls
• modules performing expensive work
• server CPU or memory contention

This is where tools such as Drupal's performance logging, database query analysis and server monitoring become relevant.

But that is a different problem from downloading 20 MB of page assets.

A page can suffer from both at the same time.

Don't optimise the wrong number

Suppose Drupal currently takes 1.5 seconds to generate a page.

You spend considerable time tuning it and reduce that to 800 milliseconds.

That is a useful improvement.

But if the visitor then downloads 20 MB of assets for another 40 seconds, you have not solved the experience that prompted the investigation.

Performance optimisation works best when you identify the biggest constraint first.

On an exceptionally heavy page, that is often the front end.

A practical way to investigate a huge Drupal page

When we encounter a page of this size, the first pass is relatively simple.

1. Open the browser Network panel

Reload the page with the panel recording.

2. Record the headline numbers

Look at:

• transferred size
• total resource size
• request count
• DOMContentLoaded
• load
• finish

3. Sort by file size

Identify the largest resources.

4. Group them by type

Are they primarily images, JavaScript, fonts, maps or third-party resources?

5. Check the HTML document separately

Determine whether Drupal itself is slow to begin responding.

6. Look at external domains

Establish how much of the load comes from services outside your Drupal installation.

7. Fix the largest problems first

Reducing a 5 MB image to 300 KB is usually more valuable than spending an hour removing a 12 KB stylesheet.

8. Test again

Performance work should be measurable.

Reload the page and compare the same numbers.

Don't start by blaming Drupal

When a Drupal page transfers more than 20 MB and takes a minute to load, something is unquestionably wrong.

But "Drupal is slow" is not enough of a diagnosis.

The problem might be Drupal.

It might be the theme.

It might be image handling.

It might be third-party JavaScript.

It might be an interactive map.

It might be all of them.

The useful question is:

What is the browser spending that minute doing?

Once you answer that, the problem usually becomes much easier to solve.

Because a 20 MB Drupal page is not primarily a Drupal problem.

It is a web page performance problem — and the browser will normally show you where to start looking.