Measure website loading time and evaluate it correctly

How fast is my website? The question sounds simple, but cannot be fully answered with a single number.

A website does not just have a single moment in time when it is „loaded.“ The browser begins connecting to the server, receives HTML, loads additional resources, and progressively builds the visible and interactive page from them.

Therefore, different performance tools for the same website can display different metrics—without necessarily any of them being wrong.

In this guide, we explain how to effectively measure a website's loading time, which metrics are important, and how to properly evaluate measurement results.

Briefly explained: Do not judge the speed of a website based on a single loading time or a single test. More meaningful is the combination of multiple measurements, various performance metrics, and—if available—real user data.

Why isn't there just one loading time? #

When a website is accessed, numerous processes take place sequentially and sometimes simultaneously.

Simplified:

Open URL
    ↓
Establish connection
    ↓
Server processes request
    ↓
HTML is transferred
    ↓
Browser processes HTML
    ↓
CSS, JavaScript, images, and fonts load
    ↓
First content becomes visible
    ↓
Important main content appears
    ↓
Further resources are loaded
    ↓
Page responds to user interactions

Depending on which part of this process a tool looks at, a different measured value is produced.

What affects the measured charging time? #

A measurement does not depend solely on the website itself.

The conditions of the test also influence the result. These include, for example:

• Location of the test system,
• Network speed and latency,
• device used or simulated hardware,
• Browser,
• Cache state,
• Server load,
• external services and resources.

That is why the same website can produce different results in two measurements.

What does TTFB mean? #

TTFB stands for Time to First Byte.

Simply put, the metric describes the time between the start of a request and the arrival of the first byte of the HTTP response.

Request starts
      ↓
Connection / Request / Processing
      ↓
First byte of the response
      ↑
     TTFB

TTFB can provide insights into the early part of the request, but it is not a complete measurement of website load time.

For example, a good TTFB does not automatically mean that large images, extensive JavaScript, or external resources will be processed quickly afterwards.

TTFB is not just server speed„ #

TTFB is often simplified as the pure response time of the web server. That is inaccurate.

The measured value can include multiple components, including network and connection times as well as the processing of the request on the server side.

Therefore, the location of the measuring system relative to the server can also have an influence.

Important: Use TTFB as a diagnostic value, but not as the sole evaluation of a website's or hosting server's speed.

What does FCP mean? #

FCP stands for First Contentful Paint.

The value describes the point in time when the browser first renders content from the document, such as text, an image, or other visible elements.

FCP thus looks at a different aspect than TTFB.

Server responds
      ↓
Browser processes page
      ↓
First relevant content is displayed
      ↑
     FCP

What does LCP mean? #

LCP stands for Largest Contentful Paint.

The metric considers when the largest relevant content element was rendered in the visible area.

Depending on the page, this can be, for example, a large image, a headline, or another content block.

A large hero image can therefore have a significant impact on the LCP.

We explain the exact meaning of LCP as well as INP and CLS at Core Web Vitals Explained: LCP, INP and CLS.

What does „fully charged“ mean? #

Even the term „fully charged“ is not as unambiguous as it sounds at first.

A website can already appear fully usable to the visitor while further resources or requests are still being processed in the background.

Conversely, a technical charging event may have already taken place even though an important external function is not yet ready.

Therefore, a single metric like „Load Time: 2.1 seconds“ should not be viewed in isolation.

What is lab data? #

Lab data is generated under controlled or simulated test conditions.

A performance tool loads the website under defined conditions and measures various metrics.

This has a major advantage: tests can be repeated under similar conditions and compared with one another.

Lab data is therefore particularly well-suited for technical diagnosis and for comparison before and after a modification.

What is field data? #

Field data is based on measurements under real-world usage conditions.

They show how a website was actually experienced by real visitors, or rather on real devices and under actual network conditions, provided there is sufficient corresponding data available for the website or URL in question.

As a result, field data can provide a different perspective than a single lab test.

Briefly explained: Lab data shows how a website performs under specific test conditions. Field data shows how it was actually experienced under real-world usage conditions.

Why can lab and field data be different? #

A lab test uses defined conditions. Real visitors, on the other hand, use different devices, browsers, network connections, and locations.

For example, a high-performance desktop with a fast connection may experience a website differently than an older smartphone on a cellular network.

Different results are therefore not automatically a contradiction.

What are Core Web Vitals? #

Core Web Vitals are metrics used to measure certain aspects of a website's user experience.

Currently, this includes:

LCP → Largest Contentful Paint
      Loading experience

INP → Interaction to Next Paint
      Responsiveness

CLS → Cumulative Layout Shift
      Visual stability

These three metrics look at different aspects of a website and should therefore not be combined into a single general „loading time“.

Which measured values are important for me? #

That depends on what you want to investigate.

If you want to know whether the server responds quickly to a request, TTFB can be interesting.

If you want to know when important visible content appears, rendering metrics like FCP and LCP are more helpful.

If users report delayed reactions to interactions, interactivity is relevant in turn.

Therefore, a good performance analysis begins with the question:

What problem do I actually want to measure?

Test website with Google PageSpeed Insights #

Google PageSpeed Insights is a well-known tool for analyzing website performance.

It can display lab data from Lighthouse and—provided sufficient data is available for the page or origin in question—real-world usage data from the Chrome User Experience Report.

This makes PageSpeed Insights suitable both for an initial technical analysis and for reviewing the Core Web Vitals.

We explain the individual areas and recommendations in the next article at How to use Google PageSpeed Insights correctly.

View mobile and desktop separately #

Performance results for mobile devices and desktop systems can differ significantly.

This is not surprising: A smartphone has different performance characteristics and can access a website via a different network connection than a desktop PC.

Therefore, do not judge solely by the desktop test just because a higher performance score is achieved there.

If a significant portion of your visitors uses mobile devices, mobile usage is at least as relevant.

Why is the location of the test important? #

Data must be transferred between the test system and the involved servers.

The greater or more unfavorable the network distance and route, the higher the latency can be.

Therefore, a website with a primary target audience in Switzerland or Central Europe should not be evaluated solely based on a single test from a distant location.

For comparable measurements, you should use test locations that are as similar as possible.

What does latency mean? #

Latency simply describes the delay in data transmission between two points.

She is not the same as bandwidth.

A connection can have a high maximum data rate and still exhibit a relatively high latency.

Numerous network operations can take place on websites, which is why latency can be relevant to perceived speed.

Cache influences measurement results #

When a website is visited for the first time, resources may need to be loaded that will already be present in the browser cache during a subsequent visit.

Server-side cache systems can also ensure that an already prepared or cached response is provided faster than a request that has to be generated completely from scratch.

That is why you should know whether you are measuring a so-called cold or already warmed-up state.

What do cold cache and warm cache mean? #

Simplified:

Cold Cache
→ required data is not yet available in the relevant cache

Warm Cache
→ required data can already be provided from a cache

Which caches are involved depends on the website and infrastructure.

When comparing performance, you should measure under comparable conditions whenever possible.

A single test is not enough #

Networks and servers do not operate under completely constant conditions.

For example, a measurement can be affected by a short-term network delay or an external service.

Therefore, perform multiple measurements and look out for recurring patterns.

Example:

Test 1 → 1.8 s
Test 2 → 2.0 s
Test 3 → 1.9 s

other test:

Test 1 → 1.7 s
Test 2 → 8.4 s
Test 3 → 1.8 s

In the second example, it should first be investigated why a measurement clearly stands out before a general statement about the website is derived from it.

Always compare the same URL #

The homepage is not automatically representative of the entire website.

A simple contact page, for example, can require significantly fewer resources than an extensive product page or an online store.

Therefore, when comparing optimizations, use the same URL before and after the change.

Before:
/produkt/beispiel/

After:
/produkt/beispiel/

That's the only way to compare the same page type.

Test several important page types #

For a more comprehensive evaluation, you should not measure solely the homepage.

Depending on the website, the following page types, for example, can be useful:

Homepage
important service page
blog post
landing page
product page
shop category page
checkout

A single fast page does not prove that all other areas have the same performance.

Document tests before and after changes #

If you want to assess a performance measure, you should document the initial and final states.

Example:

URL:
https://example.com/beispiel/

Test:
mobile

Test Location:
same

Date:
same test window

BEFORE change:
Note metrics

Change:
Optimized hero image

AFTER change:
Collect metrics again

This allows you to better assess whether the specific change has actually brought about a measurable improvement.

Do not change ten things at once #

If you compress images, change caching, deactivate plugins, remove JavaScript, and switch the PHP version all at the same time, the website might be faster afterwards—but you will barely know which measure had which effect.

For a clean diagnosis, controlled changes are better.

Practical Tip: Measure → make a traceable change → measure again. This is a much better way to see which optimization actually works.

Performance score and loading time are not the same thing #

Many analysis tools calculate a score from several measured values.

Such a score is practical for quickly categorizing results, but it is not identical to a directly measured loading time.

A value like:

Performance: 92

does not mean:

The website is 92 % fast.

The score is calculated from various measured values using a specific methodology.

Do not optimize exclusively for 100 points #

A perfect score can be a motivating goal, but it should not become an end in itself.

A measure can theoretically improve a metric while simultaneously worsening the actual website – for example, if an important image is visibly overcompressed or a required feature is removed.

Performance optimization should therefore always consider technical metrics and the actual user experience together.

Why can two performance tools deliver different results? #

Different tools may use different test locations, device profiles, network conditions, browsers, or calculation methods.

That is why you should not uncritically play the absolute numbers of different services off against each other.

For before-and-after comparisons, it is advisable to use the exact same tool with comparable settings whenever possible.

What does waterfall analysis mean? #

A waterfall view shows which resources a page loads and when the respective requests begin and end.

Simplified:

HTML       ███████
CSS           ████
Font           █████
Image 1          █████████
Image 2             ███████
JavaScript       ███████████
API                      █████

This allows you to see, for example, whether a large image file, an external service, or another resource is taking a particularly long time.

The number of requests alone is not a measure of quality #

A page with more HTTP requests is not automatically slower than a page with fewer requests.

Size, priority, caching, protocol, dependencies, and processing of the resources also play a role.

A purely quantitative target such as „under 50 requests“ is therefore not a universal performance rule.

Accurately assessing the total size of a page #

The amount of data transferred is a useful indicator, especially for image-heavy websites.

However, it should also be viewed in context.

A photo gallery naturally requires more image data than a simple text page.

The goal is not to force every website to the same total size, but to avoid unnecessary data transfer.

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

External resources can affect performance #

Websites often load content from other services.

This may include, for example:

Web fonts
Analysis services
Videos
Maps
Social media content
Advertising or tracking services
External JavaScript libraries

You do not fully control the response time of these resources yourself.

If an external service responds slowly, this can therefore affect certain aspects of your website.

A slow website does not automatically mean slow hosting #

When a website feels slow, the hosting server is often immediately blamed.

That can be a possible cause, but by far not the only one.

For example, a website can be slowed down by large images, complex database queries, plugins, themes, JavaScript, or external services.

Conversely, an inefficient application can remain slow even on high-performance infrastructure.

How we systematically narrow down such causes is covered under Slow website: systematically finding the causes.

Distinguish between server time and frontend time #

For the diagnosis, it is helpful to roughly distinguish between the generation or provision of a response and the subsequent processing in the browser.

Server / Backend
→ Process request
→ Provide HTML

Browser / Frontend
→ Parse HTML
→ Process CSS
→ Execute JavaScript
→ Load images
→ Render page

If the server responds quickly, but the browser then has to process very large resources, the page can still feel slow.

Conversely, a lean frontend can be slowed down by very slow server-side processing.

Why fast internet can be deceptive for developers #

Anyone testing a website over a fast fiber optic connection and a powerful computer may experience hardly any delays.

However, visitors may have different conditions.

That is why simulated mobile test conditions and real usage data are helpful. They reveal aspects that are hardly noticeable when accessing the site yourself on a fast workstation.

Test performance on a smartphone yourself #

In addition to automated tools, a real-world practical test is worth it.

Open important pages on a smartphone and pay attention to how the website actually behaves.

For example, observe:

When does the main content appear?

Does the layout shift during loading?

Can I interact with the page quickly?

Do images appear on time?

Is operation blocked by a cookie banner?

Does the navigation respond immediately?

Such observations do not replace a technical measurement, but they complement it in a meaningful way.

Test the website not only when logged in #

Content management systems can behave differently for logged-in administrators than for regular visitors.

Caches can be bypassed, for example, for logged-in users.

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

Avoid measurements during maintenance work #

If backups, imports, updates, or other intensive tasks are currently running, measurements may not be representative under certain circumstances.

The same applies to a freshly emptied cache structure if you actually want to assess the normal visitor state.

Therefore, document the test conditions for important comparisons.

What is a good loading time? #

The question of a single „good loading time“ is too general.

Google defines specific thresholds for the Core Web Vitals. For LCP, for example, a score of up to 2.5 seconds at the 75th percentile is considered „good“.

However, that does not mean that every other conceivable loading time metric must also generally be under 2.5 seconds.

Different key figures measure different things.

Important: Do not simply apply a threshold for one specific performance metric to all other load time values.

What does 75th percentile mean? #

With real usage data, it's not just a matter of looking at individual best or average values.

Simply put, the 75th percentile means that 75 percent of the observed experiences achieve a value that is equal to or better than this threshold.

This means that not only particularly fast individual calls are considered.

Performance and SEO #

Website performance can also be relevant in the context of Google Search. The Core Web Vitals are part of the page experience signals considered by Google.

However, this does not mean that a better performance score automatically leads to a specific ranking improvement.

Technical performance should be optimized primarily because a fast and stable website provides a better user experience for visitors.

Performance measurement is diagnosis, not a competition #

It makes little sense to compare just a score with a completely different website.

A simple blog, a complex online store, and a web application have different requirements.

More meaningful is the question:

Where are the specific bottlenecks on my website and which of them can I sensibly improve?

Regularly re-evaluate performance #

A website is changing.

New plugins, images, tracking scripts, fonts, videos, or features can affect performance.

Therefore, a measurement is not valid forever.

Especially after major changes, another check is worthwhile.

When should I measure again? #

A new performance measurement is particularly useful after:

Website relaunch
Theme change
major plugin changes
new tracking or marketing scripts
integration of large images or videos
caching changes
server or PHP changes
major shop extensions

Website availability is different from performance #

A website can be accessible and still respond slowly.

Conversely, a performance test does not automatically measure reliably whether a website is available around the clock.

Monitoring systems are used for the continuous monitoring of accessibility.

We cover this topic under Website Monitoring: Monitor Availability and Outages.

Practical procedure for a performance measurement #

select representative URL
↓
define test conditions
↓
check mobile and desktop
↓
perform multiple measurements
↓
document measured values
↓
identify conspicuous resources
↓
investigate a specific cause
↓
implement targeted change
↓
measure again under comparable conditions
↓
evaluate result

What values should I document? #

Which data makes sense depends on the tool used. For a reproducible comparison, the following information can be helpful, for example:

tested URL
date and time
testing tool
mobile or desktop
test location, if selectable
TTFB
FCP
LCP
other Core Web Vitals
transferred data volume
noticeable resources
implemented change

This will allow you to put later measurements into a much better perspective.

Common mistakes when measuring website speed #

run only a single test
test only the homepage
look at desktop only
compare different tools directly
ignore different test locations
do not consider cache state
confuse performance score with seconds
optimize for 100 points only
make multiple changes at once
blame hosting immediately for any slow website
evaluate metrics without actual user experience

Checklist for a meaningful measurement #

Which URL do I want to analyze?
        ↓
Which problem do I want to measure?
        ↓
Are the test conditions comparable?
        ↓
Mobile AND desktop considered?
        ↓
Multiple tests performed?
        ↓
Lab and field data differentiated?
        ↓
TTFB and rendering viewed separately?
        ↓
Suspicious resources checked?
        ↓
Only one targeted change made?
        ↓
Measured again under the same conditions?
        ↓
Actual website also tested myself?

Summary #

The speed of a website cannot be meaningfully described by a single number. When loading a page, server response, network, browser, images, CSS, JavaScript, external services, and many other factors interact.

Metrics such as TTFB, FCP, and LCP examine different sections of this process. Lab data is generated under controlled test conditions, while field data reflects real-world usage experiences.

For meaningful comparisons, you should test the same URL multiple times under as comparable conditions as possible and consider both mobile and desktop scenarios.

A performance score serves as a helpful guide in this regard, but is not an end in itself. The crucial thing is to identify specific bottlenecks and then check whether targeted optimization actually brings about an improvement.

Good performance analysis does not mean collecting as many numbers as possible. It means measuring under comparable conditions, understanding the right metrics, and deriving the right technical action from them.