How to Check Website Speed and What Affects Loading?

The performance of a web resource depends on dozens of factors – from image sizes and the amount of JavaScript to web server configuration, database performance and the location of the server infrastructure. Therefore, a situation where one page opens almost instantly while another takes several seconds to load is entirely possible even within the same website. To find the cause, simply opening the page in a browser and assessing it visually is not enough. A systematic website loading speed check is required using tools that show individual loading stages and help identify bottlenecks.

It is also important to distinguish between the overall page loading time, server-side performance and user metrics. A page may start displaying quickly but respond slowly to interactions, shift elements during loading or block the browser’s main thread with heavy JavaScript. That is why modern performance assessment covers not one figure but a set of metrics, among which Core Web Vitals are particularly important.

In this article, we will look at how to check website speed, which tools to use, how to interpret their results correctly and what to do if the problem is related not to the interface but to the server side, caching or infrastructure.

Why Is Website Loading Speed Important?

Website loading speed directly affects how comfortable it is for a user to interact with a web resource. People expect the page to display its main content quickly, buttons and menus to respond without noticeable delays, and interface elements not to change position after the user has already started reading the text or tried to click a link. When this does not happen, the website is subjectively perceived as slow even when secondary resources finish loading only after the main content has already appeared.

Performance becomes particularly critical for mobile traffic. A smartphone may have a weaker processor than a desktop computer, while the user may access the website through a mobile network with unstable bandwidth and high latency. Heavy JavaScript files, large images or an excessive number of third-party resources create a much more noticeable problem under such conditions. That is why testing should not be based solely on how quickly the website opens on a powerful work computer over a fast connection.

Performance is also related to SEO, but this relationship needs to be interpreted correctly. Google uses Core Web Vitals in its ranking systems, but good metrics alone do not guarantee high positions in search results. Content relevance and quality, the ability for it to be crawled and indexed correctly, the overall user experience and other signals also matter. Speed optimisation helps eliminate technical barriers and improve interaction with the website, but it does not replace comprehensive SEO work.

Particular attention should be paid to the server side. If the server or application takes a long time to generate a response, the database is slow or the CMS performs too many operations for every page request, front-end optimisation will not solve the problem completely. In such cases, web server configuration, available resources and server-side caching become important.

How to Check Website Speed?

To check website loading speed correctly, it is worth avoiding testing only one URL. The homepage often has a unique structure and may differ significantly from product pages, category pages, articles, user accounts or other functional parts of the resource. For example, a catalogue may contain considerably more images and JavaScript, while a product page may include external widgets, recommendations, reviews and analytics scripts.

A practical testing process can be structured as follows:

1. Select representative pages. Test the homepage, several important landing pages, typical product or service pages, articles and other templates that receive a significant share of traffic.
2. Run tests using several tools. One service does not provide the complete picture. PageSpeed Insights is convenient for analysing Lighthouse laboratory metrics and available Core Web Vitals data, GTmetrix for detailed examination of resources and network requests, and Search Console for monitoring field Core Web Vitals.
3. Separate laboratory and field data. A laboratory test simulates specific conditions at a particular moment, while field metrics are generated from aggregated real-world usage data.
4. Identify the bottleneck. You need to determine exactly what causes the delay: the server response, LCP resource, JavaScript, CSS, a third-party service, font, image, a large number of network requests or another component.
5. Make changes and repeat the test. After optimisation, it is important to use the same pages and conditions that are as similar as possible in order to compare the results before and after the changes correctly.

This approach makes it possible not merely to obtain a score but to understand the cause of the problem. A website speed check is particularly useful before optimisation, immediately after changes and again after some time. Laboratory metrics make it possible to see the technical effect quickly, while field data help assess how the experience of the real audience has changed.

When diagnosing the server side, it is useful to look separately at TTFB – Time to First Byte. It shows how much time passes before the browser receives the first byte of the response. A high TTFB may be related to lengthy page generation, database operations, caching, the network or connection establishment, so it should be analysed together with other metrics rather than interpreted as a pure measure of server processor performance.

If a website periodically becomes slow or unavailable but a standard test does not show a consistent problem, it is worth analysing more than just the front end. In such situations, separate website availability and server performance monitoring is useful, as the problem may appear only under load or at certain times.

Tools for Checking Website Speed

Performance analysis tools use different methodologies, so their results should not be expected to match completely. One service simulates page loading under controlled conditions, another uses aggregated real-world usage data, while a third allows you to examine the sequence of network requests in detail. For this reason, a score of 90 in one tool and a different result in another does not mean that one of the services is working incorrectly.

It is best to use the tools together. PageSpeed Insights helps assess the laboratory performance of a page and, where sufficient data are available, Core Web Vitals from the Chrome User Experience Report. GTmetrix allows the loading process to be broken down into individual resources, while Google Search Console shows the Core Web Vitals status for groups of URLs based on field data.

Google PageSpeed Insights

Google PageSpeed Insights is one of the basic tools when you need to perform a website speed check. You simply enter a URL, after which the service displays results for mobile and desktop scenarios. The report includes Lighthouse laboratory data, the Performance score, individual performance metrics and diagnostic recommendations.

For URLs or domains with sufficient statistics available, PageSpeed Insights also displays field data from the Chrome User Experience Report – CrUX. These are generated from anonymised data from real Chrome users who meet the criteria for inclusion in the sample. This is a fundamentally different type of information. A laboratory test reflects the result of a particular run under simulated conditions, while field data characterise the experience of users across different devices and networks. That is why, after technical optimisation, Lighthouse may immediately show an improvement, while field Core Web Vitals change gradually.

The Performance Score should not be treated as the sole objective of optimisation. Two pages with the same score may have different problems: on one, the largest content element may appear slowly, while on the other, the browser may remain busy executing JavaScript for a long time. Therefore, after the overall score, you need to move on to specific metrics, resources and diagnostic recommendations.

GTmetrix

GTmetrix is useful when you need a more detailed view of which resources make up the page loading process. One of the most valuable parts of the report is the Waterfall Chart. It shows resource loading by individual requests and makes it possible to assess when the browser began receiving a particular file, how long the request took, which domain the resource came from and how much data was transferred.

This helps identify problems that are difficult to notice from the overall speed score alone. For example, a page may be waiting for a response from a third-party service, loading a large JavaScript file from an external domain, performing unnecessary redirects or transferring excessively heavy images. The Waterfall Chart allows you to see the sequence of such requests and identify resources that delay subsequent loading stages.

GTmetrix uses Lighthouse for laboratory analysis. At the same time, INP is not measured as a field metric in the standard GTmetrix laboratory test because it requires real or specially simulated interactions. Total Blocking Time – TBT is used for laboratory diagnosis of main-thread blocking and can serve as a proxy for identifying responsiveness-related problems. This is another reason not to equate metrics from different types of testing.

Google Search Console

Google Search Console uses the Core Web Vitals report to analyse user experience. It displays data separately for mobile and desktop devices and groups URLs by status – good, needs improvement and poor.

The main difference between Search Console and a one-off laboratory test lies in the source of the information. The report is based on CrUX field data, meaning aggregated measurements of real-world usage. It is therefore particularly important after technical work has been completed. A laboratory website loading speed check helps assess the result of changes quickly, while Search Console helps determine whether Core Web Vitals have improved under real-world conditions.

Search Console should not be used as a tool for instantly testing one specific URL. The system groups similar pages, and some URLs may not have sufficient field data. For diagnosing an individual page, it is more convenient to use PageSpeed Insights, DevTools or another laboratory tool, while Search Console should be used to monitor the overall Core Web Vitals status of the website.

What Are Core Web Vitals?

Core Web Vitals are a set of Google’s key metrics that characterise three important aspects of user experience: the loading speed of the main visible content, page responsiveness and visual stability. As of 2026, Core Web Vitals include LCP, INP and CLS.

LCP, or Largest Contentful Paint, shows the time taken to display the largest content element visible within the viewport. This may be a large image, a text block or another supported type of content. For a good user experience, the recommended benchmark is an LCP of up to 2.5 seconds.

INP, or Interaction to Next Paint, characterises the overall responsiveness of a page to user interactions throughout its lifecycle. The metric takes into account input delay, execution of associated handlers and the time until the next frame is displayed. A good benchmark is an INP of up to 200 ms. A high value is often associated with long JavaScript tasks, complex DOM operations, heavy event handlers or browser main-thread overload.

CLS, or Cumulative Layout Shift, evaluates the visual stability of a page. If text, buttons, banners or other elements unexpectedly shift during use without an expected user action, the metric may increase. A CLS of up to 0.1 is considered good. Typical causes of problems include images without reserved space, advertising blocks, dynamically inserted content and certain web font loading scenarios.

The 75th percentile is used to assess compliance with the recommended Core Web Vitals thresholds, separately for mobile and desktop devices. In practical terms, this means that at least 75% of measured visits must meet the relevant thresholds for a good result. Therefore, a single successful laboratory test does not automatically mean that the page consistently passes Core Web Vitals under real-world conditions.

What Affects Website Loading Speed?

The cause of slow performance needs to be identified step by step because the same outward symptom may result from different components. For example, a high LCP may be caused by a heavy hero image, but sometimes the file itself is optimised and the delay occurs before it even begins loading because HTML generation is slow or the browser discovers the resource too late.

One of the most common causes is excessively large images. If the browser receives a file several thousand pixels wide for display in a small block, more data are transferred than are actually required. Modern image formats, responsive sizes and appropriate compression help reduce the amount of transferred data. At the same time, lazy loading should not automatically be applied to the main LCP image: deferred loading of a critical visual resource may worsen LCP.

The second major group of problems is CSS and JavaScript. Style resources required for initial rendering may delay page display, while a large amount of JavaScript may occupy the browser’s main thread and reduce interface responsiveness. Particular attention should be paid to code that loads or runs on every page regardless of whether it is required by the specific template.

Web fonts also affect loading. A large number of typefaces, font weights and character sets increases the volume of resources. If a font is required for the initial display of text, the way it is loaded can affect both the speed at which content appears and visual stability.

Another component is third-party scripts. Analytics systems, advertising platforms, live chats, maps, video players, social media widgets, personalisation systems and marketing services add their own JavaScript and network requests. Each component may create only a small load individually, but their combined impact can sometimes become significant.

The server environment determines how quickly the application can generate a response to a request. If a CMS takes a long time to execute PHP code, the database processes complex queries slowly, or the available CPU and RAM are insufficient for the current load, the browser may have to wait longer for the initial HTML. For PHP projects, caching, database optimisation, an up-to-date PHP version, web server configuration and application architecture can all be important.

The storage subsystem also matters, particularly for systems with a large number of input/output operations or intensive database activity. More information about modern storage devices in server infrastructure can be found in the article about NVMe drives. At the same time, simply switching to faster storage will not fix heavy JavaScript, unoptimised images or poor website architecture.

Server performance is also affected by the software environment. Apache and Nginx have different architectural approaches and configuration methods, so the specific setup depends on the application, load and infrastructure requirements. The characteristics of the two solutions are examined in detail in the article Apache vs Nginx.

For an international audience, the physical and network distance between the user and the server matters. A longer route may increase latency. In appropriate scenarios, some static content can be delivered through a CDN by placing copies of resources closer to users. The operating principle of this technology is described in more detail in the article about a CDN for websites.

How to Speed Up Website Loading?

Optimisation should begin not with randomly installing plugins or minifying every available file, but with diagnosis. If a website loading speed check reveals a specific bottleneck, changes should primarily target that issue. This reduces the risk of making numerous technical changes while achieving almost no improvement in the actual result.

The work most commonly covers the following areas:

• Image optimisation. Appropriate dimensions, compression, modern formats and responsive file variants for different screens should be used.
• Working with CSS and JavaScript. Unused code should be reduced, critical resources controlled and, where technically appropriate, loading or execution of secondary scripts deferred.
• Configuring caching. Browser, page, object and server caching solve different tasks and can be combined according to the project’s architecture.
• Server-side optimisation. This may include work with PHP, the database, web server, CPU, RAM, storage subsystem and other infrastructure components.
• Deferred loading of secondary resources. Images and other content below the fold do not always need to load immediately, while resources critical to the initial display require a separate approach.
• Controlling third-party services. The actual value of each marketing, analytics or functional script and its impact on the main thread and network requests should be assessed.
• Using a CDN where appropriate. For a geographically distributed audience, a CDN can shorten the delivery path for cached content and reduce some requests to the origin server.

It is particularly important to work with caching correctly. For a simple informational website, page and browser caching may be sufficient, while an online shop, user account or dynamic web application requires more complex logic. Redis and Memcached can be used for data caching or object cache depending on the application, while OPCache stores compiled PHP bytecode. Therefore, these technologies are not direct substitutes for one another.

A resource should not be optimised solely for the sake of achieving the highest possible test score. If a change reduces functionality, disrupts analytics, creates problems with caching personalised pages or significantly complicates website maintenance, its suitability needs to be assessed separately. The aim of optimisation is stable and predictable performance for the real audience.

Why Can a Website Still Load Slowly After Optimisation?

Even after technically correct optimisation, test results may vary. This is normal because web page performance is not a constant value. It depends on the device, network, user location, current server load, cache state and the behaviour of external services.

A laboratory test runs in a defined environment, but even its results may fluctuate. Measurements are affected by network conditions, server state, caching, availability of third-party resources and other factors. Therefore, small differences in metrics between repeated tests do not necessarily indicate a problem. It is much more important to look at trends and recurring bottlenecks.

A real user may have an older smartphone, a slower network or may be located far from the main server. That is why a website that opens quickly for a developer on a powerful computer may show weaker field results for some of the mobile audience.

Another cause is server load. If a test was conducted when there were very few visitors but most traffic arrives at a different time, response generation speed may vary. For resources with pronounced traffic peaks, CPU, RAM, database performance, PHP processes, queues and other server metrics should be analysed specifically during periods of high load.

Performance is also affected by third-party services that the website owner does not fully control. If an advertising, analytics or functional script is loaded from an external server, problems with that service may affect the page even when the main infrastructure is operating consistently.

Another source of misunderstanding is the difference between laboratory and field data. If, after optimisation, you check website speed and see a better Lighthouse result, this does not mean that Search Console will immediately show a different Core Web Vitals status. Field metrics are generated from accumulated real-world measurements, so changes are reflected gradually.

What Website Loading Speed Is Considered Normal?

There is no universal figure for total loading time that applies equally to all websites. An article page, a complex online shop, a SaaS application and a media service have different structures, functionality and numbers of resources. In addition, the full loading metric may include secondary resources that do not prevent a user from already reading the page or interacting with the main interface.

It is more practical to focus on Core Web Vitals. For LCP, a value of up to 2.5 seconds is considered good; for INP, up to 200 ms; and for CLS, up to 0.1. The recommended thresholds are assessed at the 75th percentile, so what matters is not one successful test but stable performance for the majority of users.

For LCP, a range above 2.5 seconds and up to 4 seconds means improvement is needed, while above 4 seconds is a poor result. For INP, a value above 200 and up to 500 ms needs improvement, while above 500 ms is considered poor. For CLS, a value above 0.1 and up to 0.25 needs improvement, while above 0.25 indicates poor visual stability.

At the same time, good Core Web Vitals do not mean that other parameters can be ignored. A slow TTFB, excessive transferred data volume, a large number of network requests or high main-thread load may remain important problems even when the three primary metrics are within the recommended limits.

Therefore, a proper website speed check should answer several questions at once: how quickly the user sees the key content, whether it is possible to interact with the page without significant delays, whether the interface remains stable and which resources create the main load.

How to Monitor Website Speed After Optimisation?

Performance cannot be optimised once and then considered permanently resolved. A website is constantly changing: new materials are published, images are added, plugins are installed, the theme or frontend framework changes, and analytics systems, advertising pixels, live chats and other services are connected. Every such change can potentially affect speed.

Performance degradation particularly often happens gradually. One new script may barely change the overall picture, and several additional resources may not immediately create a critical problem either, but after several months the page may contain significantly more JavaScript, fonts, images and third-party requests than it did after the initial optimisation. Without regular monitoring, it is difficult to determine exactly when performance began to deteriorate.

After major updates, it is advisable to check website loading speed again using the same typical URLs that were previously used as control pages. This makes it possible to compare metrics before and after the change. Particular attention should be paid to installing new plugins, changing templates, adding large interactive blocks, personalisation systems and advertising technologies.

For laboratory diagnosis, PageSpeed Insights, GTmetrix or browser tools can be used regularly, while Search Console and other CrUX sources can be used to assess field Core Web Vitals. The server side should be monitored separately because a good front-end score does not reveal every possible problem with load, the database or availability.

It is important to retain baseline results after optimisation. Then, after subsequent releases, it becomes possible to determine quickly whether LCP has changed, JavaScript volume has increased, the number of resources has grown or TTFB has worsened. This approach turns performance from a one-off technical task into a controlled website quality parameter.

Conclusion

To understand why a website is running slowly, assessing only the overall time it takes to open the page is not enough. Modern website loading speed checks cover the speed at which the main visible content appears, interface responsiveness, visual stability, JavaScript execution, resource volume and server-side performance.

PageSpeed Insights helps analyse the laboratory performance of an individual page and available field Core Web Vitals, GTmetrix allows detailed examination of the resource loading process, and Google Search Console monitors Core Web Vitals for the real audience at the URL-group level. These tools complement one another, so optimisation should not be built around a single score or one test.

After changes, several typical pages should be tested under conditions that are as similar as possible, with specific metrics compared. If the problem is related to lengthy response generation, the database, caching or insufficient server resources, it is necessary to move from front-end diagnosis to infrastructure analysis.

Image compression, CSS and JavaScript optimisation, proper caching, control of third-party scripts, server optimisation and the use of a CDN where appropriate can improve performance, but the specific set of actions always depends on the cause of the problem. That is why high-quality diagnosis should precede optimisation, while performance monitoring should continue after it is completed.

If diagnosis shows that the current server environment is limiting project performance, the required amount of CPU, RAM, storage resources and level of control over the configuration should be assessed separately. For websites and web applications that require their own server environment with the ability to configure the web server, PHP and caching independently, one of the options available from Hostpark is SSD VDS in Poland. Moving to different infrastructure is appropriate when measurements confirm that the bottleneck really is on the server side rather than in the front end or third-party resources.