Peakhour.IO - Analytics

The Hidden Cost of Click Fraud

2025-01-14T13:00:00+11:00

Marketing organisations are losing money to automated clicks and fake impressions. These attacks drain advertising budgets and corrupt the data CMOs rely on for strategic decisions. The lost money cannot be recovered, but understanding the scale and mechanics of click fraud helps marketing teams protect future investment and optimise campaigns.

The Scale of Click Fraud

Click fraud now consumes 40% of digital advertising budgets through fake clicks and impressions that never reach real customers. It affects every digital marketing channel, from pay-per-click and display advertising to social media campaigns, retargeting, and video advertising. The damage goes beyond direct financial loss, because it also corrupts the metrics teams use for decision-making.

Our research on bot traffic shows the percentage of fraudulent clicks continues to rise each quarter. Marketing teams that ignore this threat base their strategies on flawed data, which leads to misallocated resources and weaker campaign performance.

How Bots Generate Fake Clicks

Automated bots generate clicks and impressions at scale across digital advertising platforms. These programs target competitor advertisements to drain marketing budgets through fake clicks. They create artificial impressions that inflate metrics and send false engagement signals. Bots also manipulate bidding algorithms and skew attribution data, leading to misallocated advertising resources.

Modern bots use more advanced techniques to evade standard security controls. They mimic human behaviour patterns and rotate through different IP addresses to avoid detection and blocking.

The Residential Proxy Challenge

Residential proxies create a significant obstacle for click fraud detection systems. These proxy services route bot traffic through IP addresses assigned to real consumers' homes and devices, making fraudulent traffic look legitimate to traditional anti-bot tools.

Residential proxy networks build their IP pools through multiple channels. They partner with consumer VPN services, distribute browser extensions, embed code in mobile applications, and in some cases exploit compromised devices. This mix gives proxy operators access to millions of residential IP addresses.

Traditional IP reputation services fail to identify this proxy traffic. Our research demonstrates these services miss up to 96% of residential proxy traffic, leaving advertising campaigns exposed to fraud through these channels.

Impact on Marketing Strategy

Click fraud undermines three core areas of marketing decision-making. First, it distorts campaign performance metrics through false click-through rates and inflated impression counts. The fraud creates skewed conversion data and engagement metrics that mask true campaign performance.

In budget allocation, click fraud wastes marketing spend on non-existent users while reducing campaign ROI. Artificially inflated acquisition costs lead marketing teams to misallocate resources across channels and campaigns.

Strategic planning suffers when data is contaminated across multiple dimensions. A/B testing results become invalid when bots generate fake interactions. Geographic and demographic data lose accuracy due to proxy traffic. Competitive intelligence becomes unreliable as bot activity masks true market dynamics.

Marketing teams that base decisions on corrupted data take on significant risk. Their optimisation efforts target bot behaviour instead of real users. Campaign budgets flow to channels dominated by fraud. Strategic initiatives fail because decisions are based on artificial metrics rather than genuine customer behaviour.

Protecting Your Marketing Investment

Lost money from click fraud cannot be recovered, so marketing teams need protection measures for future investment. Detection forms the first line of defence through continuous monitoring of traffic patterns and IP reputation analysis. Teams track user behaviour to identify suspicious patterns that indicate fraud.

Prevention requires a multi-layered security approach. Marketing teams need systems that block known bot networks and detect residential proxies attempting to generate fake clicks. These controls validate real user traffic and filter out fraudulent clicks before they affect campaigns.

Campaign optimisation becomes more useful once fraud protection is in place. Teams can adjust targeting parameters based on genuine user data and reallocate budgets to channels with verified traffic. This supports updates to bidding strategies and refinement of audience segments based on real engagement.

Our Ad Fraud Protection solution protects marketing investment by blocking bot traffic, detecting residential proxies, and validating real users. This helps ensure ad spend reaches genuine customers rather than fraudulent clicks.

Making Informed Decisions

Understanding click fraud changes how marketing teams analyse data and plan campaigns. Data analysis starts with identifying corrupted metrics in campaign reports. Teams must filter bot traffic from their analytics to measure real user engagement. This enables tracking of true campaign performance based on human interactions.

Budget planning improves once teams understand the scale of click fraud. Marketing teams can allocate resources to channels with verified human traffic. This focus on real users optimises campaign spend and improves return on investment across marketing initiatives.

Strategy development depends on clean, accurate data. Teams make decisions based on genuine user behaviour rather than bot interactions. Campaign planning targets real audience segments with messages that resonate. Performance measurement reflects actual results rather than artificial engagement.

Taking Action

Marketing teams need protection measures across three key areas to secure their investments. First, bot protection forms the foundation through deployment of bot management systems. These systems block automated traffic while validating real users and monitoring for suspicious patterns.

The second protection layer focuses on residential proxy detection. Teams implement proxy detection to identify and block proxy networks. This helps ensure traffic comes from real IP addresses and prevents fraud through residential proxies.

The third component centres on protecting ad spend through traffic monitoring. Teams implement systems to block fraudulent clicks and validate impressions. This enables tracking of real engagement from genuine users.

Our Traffic Control solution combines these protection measures to help marketing teams secure their investments and base decisions on real user data.

Conclusion

Click fraud threatens marketing budgets and corrupts campaign data. Lost money cannot be recovered, but understanding and preventing fraud helps marketing teams protect future investment and make better decisions.

Interaction to Next Paint (INP)

2023-09-11T13:00:00+10:00

Google has announced that Interaction to Next Paint (INP) will replace First Input Delay (FID) as a Core Web Vital as of March 2024. Introduced as a metric in 2022, INP covers gaps in FID by measuring more of what happens after a user interacts with a page.

To help site owners prepare for its introduction as a Core Web Vital, INP is already included in the Chrome User Experience Report (CrUX). By analysing the CrUX data, website owners can see their current INP performance and make targeted optimisations ahead of the March 2024 change.

A better metric than First Input Delay

First Input Delay, as its name suggests, only measures the delay between an input, such as a keypress or mouse click, and the point where the browser begins to handle that event. It does not include the time spent processing the input. It only measures how long the browser was blocked before it could start handling it.

That leaves two issues: it only considers the FIRST event, and it does not measure how long it takes for the user to see the result of their input.

INP is designed to cover both issues. It measures the latency of ALL 'interactions' through to the visual response for that interaction. As explained by Google, an interaction like a tap on a touch screen device can consist of several input events.

"An interaction's latency consists of the single longest duration of a group of event handlers that drives the interaction, from the time the user begins the interaction to the moment the next frame is presented with visual feedback."

After measuring all interactions, the final INP score is the longest interaction observed, ignoring any outliers.

What Constitutes a Good Score

INP is measured in milliseconds (ms), with lower scores indicating better performance:

Good: < 200 ms
Needs Improvement: 200-500 ms
Poor: > 500 ms

How to ensure you have a good INP score

Minimise Main-Thread Work

Long-running JavaScript can block the main thread and increase INP times. Break these tasks into smaller parts and run them asynchronously to reduce delays.

Efficiently Use Browser APIs

APIs that trigger layout recalculations can be expensive. Use them sparingly and look for alternatives that put less pressure on the browser.

Defer Non-Essential CSS and Scripts

Postpone the loading of non-critical CSS and JavaScript. Use techniques like asynchronous loading to improve INP scores.

Monitor Third-Party Scripts

Heavy third-party scripts can degrade INP performance. Use asynchronous or deferred loading for these scripts to limit their impact.

Conclusion

Google estimates that 90% of a user's time on a page is after it has finished loading. FID focused on first impressions, with the assumption that a fast start meant the page would stay responsive. Interaction to Next Paint addresses that gap and gives a more accurate view of user experience. If you want to know your current INP score, you can use our free website speed comparison tool to view it alongside your other Web Vitals, and see how your website compares to your competitors.

Maximising Website Speed

2023-06-07T12:31:00+10:00

As businesses prepare for a global economic downturn, every source of friction matters. One of the most controllable is website speed.

For many customers, the website is where they first test whether a business is worth their time. They learn about the company, compare products, read content, and, if the experience holds up, buy. Loading time shapes that first impression, affects engagement, and can change whether a visitor becomes a customer.

This article looks at why speed deserves attention when trading conditions tighten. It covers search rankings, conversion impact, and published case studies where faster sites produced measurable gains.

The Need for Speed

Website speed is not an abstract technical score. It is how quickly users can see and interact with content. A delay measured in milliseconds can affect engagement, conversion rates, and customer retention.

Speed matters because user expectations are set by fast services and fast networks. When a page feels slow, people leave and are less likely to return.

Speed also affects how search engines, including Google, rank your website. For businesses trying to remain visible in a crowded market, especially during an economic downturn, performance is a practical lever.

Correlation with Search Rankings

The relationship between website speed and search rankings is supported by research and by statements from Google. A few years ago, Google announced that page speed would be a ranking factor. The change reflected Google's focus on relevant, usable pages.

Websites that meet all of Google's requirements receive a slight advantage, ranking one percentage point higher than the average. These requirements cover several areas, from content relevance and quality to mobile-friendliness and page speed.

By contrast, websites that fail to meet at least one of Google's requirements can sit at a measurable disadvantage, ranking 3.7 percentage points lower. That matters when search visibility is already under pressure.

Google's Core Web Vitals have also become a measurable factor in search rankings. These vitals measure aspects of page speed and user experience, showing how speed and SEO (Search Engine Optimisation) now overlap.

A study by Crystallize also found a correlation between speed and SEO. In their page speed score experiment, a page with a high score ranked #1 in Google with a featured snippet for the optimised item. Unoptimised pages with lower speed scores did not appear in search results.

The practical point is straightforward: website speed can improve search visibility. In an economic downturn, that extra visibility can matter.

Conversion Impact of Speed

Speed also affects conversion rates. Deloitte's 'Milliseconds Make Millions' report shows how small improvements in loading time can change commercial outcomes.

The study examined a 0.1 second decrease in loading time across different market sectors. In retail, a quicker page loading time led to an 8.4% rise in conversion rates and a 9.2% improvement in average shopping basket size. The travel sector saw a 10.1% increase in conversion rates and a 1.9% rise in average basket size. For luxury brands, faster loading times resulted in an 8.6% increase in page views per session and an 8.3% decrease in form bounce rates.

Peakhour clients have seen the same pattern. Pharmacy Direct reported a 30% increase in conversions and order value after reducing page load time by 90%. Kitchen Warehouse saw a 150% increase in revenue after decreasing page load times by 70%.

These numbers show that page speed is tied to business metrics, not just technical scores. The scale varies by site and sector, but the direction is consistent across the cited examples.

Real-Life Success Stories

The effects of website speed optimisation are visible in published case studies:

French linen brand Carré Blanc saw a 25% increase in conversion rates after improving web page loading speed.
Renault optimised the Largest Contentful Paint (LCP), leading to a 14 percentage point decrease in bounce rate and a 13% rise in conversions.
E-commerce platform eBay found that every 100ms improvement in search page loading time resulted in a 0.5% increase in additions to the shopping cart.
SnipesUSA.com doubled their average conversion rate from about 1% to about 2% by decreasing load times by 30%.
French toy retailer King Jouet enjoyed a 5% increase in conversion rates within a month through page speed optimisation.
AliExpress, a global online retail marketplace, experienced a 10.5% increase in orders and a 27% increase in conversions for new customers by reducing loading time by 36%.
Boutique designer brand Revelry saw 43% faster page loading, an 8% decrease in bounce rates, and a 30% increase in conversions after optimising images on their eCommerce site.
Zalando, an online fashion platform, reported a revenue increase of 0.7% per session by reducing web page loading time by 100ms.
Pinterest observed a 15% increase in platform registrations following an improvement in loading speed.
Telecommunications company Vodafone saw an 8% sales increase with a 31% improvement in Largest Contentful Paint ( LCP).
Mobile marketplace Swappie achieved a 42% increase in mobile revenue by focusing on Core Web Vitals.

These examples show how improving loading speed can lift conversion rates and revenue.

Optimising for Search Performance

Speed also affects search performance beyond organic ranking. Several examples point to paid search impact:

Lever Interactive Agency reported that one of their clients improved their Quality Score, resulting in a 17% decrease in Cost Per Click (CPC), a 31% decrease in Cost Per Acquisition (CPA), and a 20% increase in conversion rate on faster landing pages.
Crystallize Headless Commerce noted that scoring high in the Quality Score can lead to significant benefits, including up to a 50% discount on CPC prices. Conversely, a low Quality Score can result in paying up to 400% extra, severely impacting your marketing budget.

Core Web Vitals have also become a priority for eCommerce platform Shopify. The company continues to optimise speed performance to improve search rankings.

These cases show why performance work needs to be ongoing, especially where search traffic and paid acquisition costs are material to the business.

Enhancing Engagement

Engagement is not separate from speed. A fast, well-optimised site gives users less reason to leave and more opportunity to browse, compare, and interact. The data supports this in several ways.

Take eCommerce for instance. Customers are 10% more likely to recommend an eCommerce website when pages load in 10 seconds instead of 13 seconds. The likelihood of recommendation rises to 26% if loading time is reduced to 3 seconds. That shows how quickly performance changes user perception.

Other companies have also seen measurable effects from speed optimisation. Netflix implemented Gzip compression for resource optimisation, resulting in a 43% reduction in outbound traffic. Yahoo Japan News saw increases in both page views per session and session times (15% and 13% respectively), as well as a 1.72% decrease in bounce rate, by improving their Cumulative Layout Shift (CLS) by 0.2 points.

Google has also published data linking Core Web Vitals to engagement. Their data showed that favourable Core Web Vitals scores can reduce the likelihood of users abandoning a page before it loads by up to 24%. Meeting Core Web Vitals thresholds also led to an overall 43% improvement in bounce rate for The Economic Times.

The agriculture e-commerce platform, Agrofy, improved their Core Web Vitals scores by 70% for LCP and 72% for CLS, resulting in a 76% reduction in abandonment rate. Again, the useful lesson is not just that the site became faster. It is that users behaved differently once it did.

Key Speed Metrics

Website speed is about more than full-page load time. Several metrics help assess how fast and stable a page feels to a user. Google's Pagespeed Insights lists the following important metrics:

Largest Contentful Paint (LCP) measures the time taken to load the largest visible content on the page. The ideal target for this is less than 2.5 seconds. This metric matters because it provides a clear indicator of perceived load speed for the user.
Cumulative Layout Shift (CLS) evaluates the visual stability of a page during loading. The target here is less than 0.1. This helps limit content jumping or shifting while the page loads, providing a smoother user experience.
First Input Delay determines how quickly a page responds to user input, with the target being less than 0.1 seconds. This metric measures the interactivity and responsiveness of a website.

Together, these metrics show whether a website delivers a fast, smooth user experience.

User Expectations and Impact on Business

Users expect pages to respond quickly. When they do not, speed becomes a business issue rather than only an engineering issue.

According to Think with Google, slow-loading pages can affect user experience, resulting in higher bounce rates, negative brand perception, and an impact on conversions and revenue. When users have to wait too long for a webpage to load, they are likely to leave and look for a faster experience elsewhere.

Digital marketing expert Neil Patel highlights that a 1-second delay in page response can lead to a 7% reduction in conversions. To put that into perspective, if an e-commerce site is making $100,000 per day, a 1-second page delay could cost $2.5 million in lost sales every year.

Akamai also found that 53% of mobile site visitors will leave a page that takes longer than three seconds to load. This shows the standards modern users have for website performance and the revenue risk for businesses that fail to meet them.

Common Culprits

If your website is running slowly, a few common issues could be to blame. The usual causes are technical and operational:

Time to First Byte (TTFB) is the time it takes for the first byte of data to be received from the server. High TTFB can affect loading times and should be minimised.
Large Page Size and Resources can also contribute to slow loading times. This includes heavy content, such as images, videos, or large files. Optimising these resources can materially improve loading speed.
Third-Party Resources like ads, plugins, or widgets can require additional loading time. While these are often necessary, they need to be managed carefully to avoid excessive loading delays.
JavaScript can be a double-edged sword. While it enables advanced functionality, complex or poorly optimised JavaScript code can also hinder performance.
Single-Page Applications (SPAs) may experience slower initial loading due to their extensive scripting requirements, but they often offer faster navigation once loaded.
Busy Servers Handling Bot Traffic can also cause slowdowns. Bot traffic, in some instances, can account for over 40% of server load. Managing this effectively can help improve website speed.

Understanding which of these factors applies to your site helps you focus performance work where it will matter.

Continuous Monitoring and Performance Optimisation

Getting a site fast once is not enough. Speed can regress as content, third-party tags, releases, and traffic patterns change, so monitoring and performance optimisation need to be continuous.

Tools such as Google's Pagespeed Insights can help track website performance. Regular checks of key metrics can show which issues are slowing the site down and which changes need attention.

It is also important to test improvements on a staging website before deploying them to production. That reduces the risk of disrupting live performance or user experience. Regular diagnostic testing and iterative improvements help keep the site aligned with current performance expectations.

As SEO consulting company Moz highlights, focusing on continuous performance optimisation can have significant benefits. It can help maintain a fast, usable site and support higher search rankings, better engagement, and increased conversions and revenue.

Preparing for the Coming Recession

With an economic downturn on the horizon, a fast, well-optimised website becomes more important. Consumers are likely to be more selective with their spending, and businesses will need to compete harder for each sale.

A fast website can be a useful differentiator in this environment. It can boost your search rankings, making the site more visible to potential customers. It can improve engagement by giving visitors fewer reasons to leave. It can also increase conversion rates, which has a direct effect on sales.

In this context, website speed is not cosmetic. It is an operating requirement. The work is to measure the current experience, fix the main bottlenecks, and keep monitoring performance as the site changes.

The data and case studies point in the same direction: speed optimisation is a practical investment. It helps align the website with user expectations and makes the site a more effective part of the business.

Website speed is measurable, improvable, and commercially relevant. For businesses preparing for tighter conditions, it deserves active management rather than occasional clean-up.

What is the Chrome UX Report (CrUX), and why should you care?

2021-02-26T13:00:00+11:00

A faster website is better for clients: they buy more, and they engage more with your content. However there's someone else that rewards fast websites: Google. Fast websites rank higher in organic search results than slower websites. They will also achieve higher quality scores in Google Ads, resulting in lower ad spend.

We've previously written about Google's Web Vitals. The practical question is where the real-world data comes from. It is not gathered by Googlebot. Google uses field data from the Chrome User Experience Report, usually shortened to CrUX, to show how eligible Chrome users actually experienced a page or origin.

That matters because a fast lab score is not the same thing as a fast customer experience. WebPageTest and Lighthouse help diagnose a controlled test run. CrUX shows the field data behind PageSpeed Insights, Search Console's Core Web Vitals report, and Peakhour's website speed comparison tool.

Introducing the Chrome UX Report (CRuX)

The CrUX report is a public data set of real-user measurements (RUM) of website performance across millions of sites. The report has been around since 2017 and is updated regularly, but the value is still often missed: it shows what real users experienced, not what a synthetic test predicted.

The data is collected from real Chrome browser users who have opted in to send browsing information back to Google. This opt-in requires that the user has:

Opted in to syncing browser history
Not set up a sync passphrase
Usage statistic reporting enabled

Despite these conditions, millions of Chrome users still report statistics back to Google. A given website still needs to be fairly busy before there are useful statistics in the report.

Gathered Metrics

The current Core Web Vitals are:

Largest Contentful Paint (LCP): how quickly the main content appears.
Interaction to Next Paint (INP): how responsive the page is to real user interactions.
Cumulative Layout Shift (CLS): how visually stable the page is while it loads.

CrUX also exposes supporting performance metrics and dimensions that help explain those headline scores. Older metrics such as First Input Delay (FID) still appear in older reports and tools, but INP is now the responsiveness metric to watch.

Dimensions

Because performance can vary widely, the metrics are divided into the following dimensions to help segment and understand the user experience.

Country
Device Type: Tablet, Phone, Desktop
Connection Speed: slow 2g, 2g, 3g, 4g, or offline

Viewing data in the report

There are several ways to see how your website performs in the report. These include:

Pagespeed insights

Google's website analysis tool provides summary CRuX data for the analysed URL and, if data is available, for the entire site.

Page Speed Insights Field Data" style="max-width: 100%;margin-bottom: 20px"/>

Google BigQuery

The most flexible option is to access it directly via BigQuery. You query it with SQL (database query language).

The downside is that you need to understand SQL and have a Google account.

Google's Search Console (formerly Webmaster Tools)

The search console now has a section 'Core Web Vitals' that shows whether URLs pass the Core Web Vitals, as well as a historical graph of performance for both mobile and desktop.

Looker Studio

Looker Studio, formerly Google Data Studio, can be used to build dashboards on top of CrUX data and other sources. It lets you visualise the performance of your website, or a competitor's website, over time.

Third party tools

Like our own website speed comparison tool. It uses the Chrome UX API to retrieve the information.

CrUX vs lab tools vs RUM

CrUX is field data. It is useful because it reflects real Chrome users, but it only reports where there is enough eligible traffic. It can also be slower to reveal the cause of a problem because it is aggregated.

Lab tools such as WebPageTest are better for diagnosis. They show waterfalls, redirects, blocked resources, caching issues, image weight, and third-party requests. Your own real user monitoring can go further again, because it can include business context that CrUX does not know: customer type, template, campaign, cache state, bot pressure, origin load, and release timing.

Conclusion - Why you should care

The data in the Chrome UX Report is one of the clearest public views of how Google sees the performance of your website. It is also a free source of real-world user measurements that helps you understand how visitors experience your pages.

Use CrUX to see whether your site is passing Core Web Vitals, use lab tools to find the technical cause, and use traffic visibility to understand whether bots, crawlers, bursts, cache misses, or expensive requests are putting the experience under pressure. If the first question is "how do we compare?", start with the website speed comparison tool. If the question is "what is slowing us down?", start with Traffic Management.

Test Your Website Performance With Google Lighthouse

2020-09-14T13:00:00+10:00

Today we're introducing our other favourite tool for testing website performance: Google Lighthouse (from here we'll just call it Lighthouse). Lighthouse measures page experience across accessibility, performance, SEO, and Progressive Web Apps for desktop and mobile devices.

Lighthouse is the engine behind web.dev/measure and PageSpeed Insights. It is also available in Chrome DevTools, via npm, or as a browser extension in Chrome and Firefox. At time of writing Lighthouse is up to version 6, which introduced Web Vitals as the basis for scoring. If you are unsure which version of the tool you are using, then scroll right to the bottom of the report it generates where it will state the version.

Lighthouse generates its report by simulating a specific device and network speed, rather than running at the full speed of your computer. That matters because speed issues are more noticeable on slower devices, and users are not all on newer devices or fast internet connections. You should test for a good load experience across that range. The current simulated mobile device is a Moto G4 on a ~1.5 megabit connection. For reference, it would take over 5s to download 1mb of data at this speed. If your page weight is typical, ie over 2.5mb, you should not expect a strong score.

How to use Google Lighthouse

There are two ways you can run a Google Lighthouse report:

In your local browser;
Online via web.dev/measure or PageSpeed Insights.

We recommend running Google Lighthouse in your local browser because the online versions operate out of the US. If your website and customers are elsewhere, that extra network latency can pull the score down.

Here we'll focus on running Lighthouse from within Chrome DevTools. To do this, click on the three vertical dots in the top right-hand corner, then select 'More Tools', then 'Developer Tools'.

The developer tools will then be displayed. Along the top of the tools window are a number of tabs. Select the 'Lighthouse' tab.

Since we're only interested in performance, make sure only the Performance category is ticked. You also want to make sure 'Clear storage' is ticked (in the top left) to simulate a first load of your site. Finally, choose the device you want to report on, mobile or desktop, and click 'Generate report'.

While the report is being generated, avoid doing anything else on your computer, and don't leave it busy with background tasks. Otherwise, the score can be affected.

Understanding the Score

Once the report has finished you'll see a performance summary, like this mobile one we ran on Peakhour.io while we were developing the website:

Scoring in version 6 is based on Google's web vitals, which are metrics that indicate a good user experience, and Webpagetest's speed index, which measures visual loading performance. Each metric is colour coded as good, ok, or bad. If the measurement is good you get a green circle to the left, if it's ok you get an orange square, if it is bad you get a red triangle.

Each raw metric (the number listed in the report) is compared to real website performance data sourced from the HTTP archive and converted into a score out of 100. This is done by grading the reference data on a curve, so if your website performs in the top 8% of websites, it gets a score of 90. Similarly, if it scores in the top 25%, it gets a score of 50. If you are interested in the technical details, Google has in-depth explanations of the scoring at web.dev

Each metric is assigned a weight, and the scores are tallied into one overall number based on the weighting. Here is a breakdown of the test we just ran (in the screen shot above), obtained by clicking on the 'See Calculator' link between the Metrics section and the screen shots:

Score Variability

79 is a good result for a mobile device. However, we ran it several times and obtained scores between 60 on the low end and 85 on the high end. Scores can fluctuate widely, even when testing on the same device repeatedly. Reasons for this include:

Small differences in internet performance.
Your computer CPU load when performing the test.
Web server variability.

Again, Google has in-depth documentation around what might be causing this.

Opportunities

If your site loads slowly then Lighthouse will list addressable reasons in the opportunities section of the report.

This is the part we generally find most useful. It identifies items that slow the initial load and items that affect the rendering of a website once it is downloaded. A page can be downloaded very quickly, but the end user still sees a slow site because CSS and Javascript are blocking rendering. This is a common problem in Wordpress and Magento themes. These themes include large amounts of third party code that ultimately never gets used for a particular site, but which the browser still has to download and parse before it can display anything.

In this case, the main bottleneck appears to be a font loaded from Google Fonts. This is delaying the rendering of our page by 1.3s.

Diagnostics

The diagnostics section provides additional information you can use to improve load times.

Here we have a few small problems, mainly associated with the development status of our site.

web.dev and PageSpeed Insights

If you do choose to run your report online, we recommend using PageSpeed Insights.

In addition to the generated report, PageSpeed Insights also shows you Field Data for the page you are testing, and an Origin Summary for all pages on the website.

This is real-world data gathered from Chrome users who have opted in to allowing Google to gather their data. If your site isn't very busy then Google might not have any data to share. It is not truly representative, but it is useful information and can often tell a very different story to your Lighthouse score.

Summary

Regular measurement matters because performance issues are often specific and easy to miss. Lighthouse is useful for identifying issues that affect website performance, and when used in conjunction with Webpagetest.org, you'll be in a better position to provide a good experience for your users. Next we'll cover common issues that can impact site speed, so read on.

Website Performance testing with WebPageTest.org

2020-09-13T13:00:00+10:00

WebPageTest is one of our favourite tools for measuring website performance: webpagetest.org

WebPageTest is a web page performance testing tool developed by AOL and open-sourced in 2008. It produces its metrics using real-world browsers to load the web page being tested. It's actively maintained by Google on GitHub, so you can download and install it on your own server if you prefer. It is also free.

The key advantage of WebPageTest is that tests can be run from locations around the world, using real browsers at actual connection speeds. That lets you test performance where your users are, and see real load times rather than arbitrary scores out of 100. You can run simple tests, advanced multi-step tests, video capture, content blocking, multi-site visual comparisons, and traceroute testing. While this is still a synthetic test, it is about as close to real-world performance measurement as you can get without using RUM.

Use WebPageTest when you need to understand why a page is slow. Use the Chrome UX Report when you need to know how real Chrome users experienced the page over time. Use Peakhour's website speed comparison tool when you want a fast comparison between your domain and competitor domains using CrUX field data.

Running a Simple Test

To run a simple test:

Visit webpagetest.org
Enter the URL of the page that you want to test in the 'Enter a Website URL' field. We usually enter only the domain name, with no www and no https:// at the front. This simulates someone typing your domain into a browser address bar and captures how much time any redirects add to the page load. Sometimes redirects can be very slow.
Select the location of the test from the 'Test Location' drop down. Choose locations that reflect where your users are. Note Australian locations are at the very bottom.
Choose the browser to run the test from. Chrome is the default.
Press 'Start Test'

Note there are advanced options but for simple testing you don't need to change these.

The test will perform three visits to the specified page, with the browser cache cleared in between each visit. This simulates someone visiting your site for the first time, including the parts of the page load that only happen on an uncached visit.

Interpreting the results.

A,B,C's

The results page has a summary section at the top giving you summary grades for several categories. Here's a sample report using our website, peakhour.io. Take note of the sections at the bottom, because we'll refer to them later.

While this section isn't representative of performance it can still give you actionable information. Here's a summary of the information (ignoring security since we're concerned with speed):

First Byte Time: How long it takes the server to respond to the browser request with the first byte of information. This is the same as the Web Vital Time To First Byte (TTFB).

Keep Alive Enabled: A server option that leaves the connection from the browser to the server open for a short time, usually a few seconds, after the server has finished transmitting a request. This allows the browser to reuse a connection and saves time because it does not need to reconnect as often.

Compress Transfer: When files are transferred from the server they are compressed, usually via gzip, to make sure transfer sizes are as small as possible. It looks like we have a problem here.

Compress Images: Images are usually the largest part of a web page by transfer size. Making sure they're well compressed is important for fast sites.

Cache Static Content: Checks that static files, e.g. JavaScript, CSS, and images, have appropriate cache headers so your browser doesn't re-fetch them every time it views a page. We're developing our site so have caching turned off at the moment, hence the bad score

Effective Use of CDN: Detects whether your website is using a CDN known by WebPageTest.

This report points to problems with transfer compression and static content caching.

Performance Metrics (The Important Stuff)

The next section summarises the key performance metrics of the page load. Google's web vitals are represented alongside lab metrics such as speed index, total blocking time, and page weight.

Despite some poor marks in the grading section, the peakhour.io website loads very quickly. Its Largest Contentful Paint (LCP) is less than 1s, well below Google's 2.5s target for a good result. We've already covered them in our web vitals, which also defines ideal values for each metric, so we won't cover them again here. One detail worth noting is that Total Blocking Time is still a useful lab signal for main-thread blocking. It is not the same as Interaction to Next Paint, because INP is measured from real user interactions in the field, but it helps identify JavaScript and third-party work that can harm responsiveness.

The Detail Section

Remember the sections immediately below the grade summaries? Now we're going to click on the 'Details' section. The part we want to highlight here is the Waterfall.

At the top of the waterfall chart is a colour key for reading the diagram. The key concepts are:

dns (Dark Green): This measures the time it takes for the browser to look up the location of your server.

connect (Orange): This measures the time taken to establish the TCP connection to download a resource. It should only appear on the first resource for a given host. Remember the keep-alives grade: if that is turned off, there will be more connections here.

ssl (Dark Purple): Any resources that are loading from a secure website will need to be processed as such – the purple will signify how long it is taking to connect to that SSL item.

The Waterfall View

The waterfall is an easy-to-read view of how your website loads, with all the resources listed in the order they're requested, along with the time taken to load each resource. You can click on any resource to view the request/response headers, file size, protocol and more.

In the example above the first line has a yellow background, which signifies a redirect. The three lines towards the bottom with red backgrounds signify 404 not found errors, which need to be fixed. The colourful vertical lines indicate where major load events, like first paint and document loaded, happen.

The other thing to look for is any resource that takes a long time to load. In our example the 2nd row, which is the main HTML document, only took 149ms, which is fast. A lot of websites take 2-5s to load the main document, putting the user experience under pressure before the rest of the page has started. The main concerns here are rows 27 and 28: two SVG images that took around three quarters of a second to load.

The Performance Review Section

The final section we're going to cover is the Performance Review section.

This section gives more detail for the performance grades at the top of the report. In the earlier example Peakhour.io scored poorly for Compress Transfer and now we can see why: we're not compressing SVG images, something that can save 234kb of file downloads.

Summary

WebPageTest gives you enough detail to see where a page is losing time, not just whether it passed a headline score. There is more in the tool than we've covered here, but this is enough to test a website, read the main report sections, and identify practical issues to fix. If you are starting with a market view rather than a single waterfall, compare your field data first with the website speed comparison tool, then come back to WebPageTest for the diagnostic pass.

Core Web Vitals Optimisation

2020-09-11T13:00:00+10:00

A good user experience matters for any website. It matters to users, and Google also measures aspects of the user experience when ranking your website in its organic results.

Google ranks websites and pages in its search results using 'search signals'. These signals include the quality of content on a page, the number of sites linking to that page, and the experience of the user browsing the site. Factors that make up a great experience include ease of use, accessibility, speed and responsiveness.

The set of search signals that Google uses to measure user experience beyond a page's content value is called 'Page experience'. Google updated the Page Experience signals with metrics called Web Vitals.

For years, performance testing used different proxies to determine whether a website was fast. Browser events like 'Page Load' or 'Dom Load' were used before it was realised that these do not necessarily reflect what an end user experiences. Testing then fragmented, with different teams focusing on the measures they considered important. Web Vitals is Google's performance testing initiative to provide "unified guidance for quality signals that they believe are essential to delivering a great user experience on the web."

The 'Core' Web Vitals join the existing search signals: mobile-friendliness, safe-browsing, HTTPS, and no intrusive interstitials as seen in the graphic below from Google.

Understanding the Core Web Vitals

Before diving in, it is worth noting that the metrics that make up Core Web Vitals are expected to evolve over time. Google states that "these signals are not perfect and future improvements or additions should be expected."

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) measures when the "largest", or "main" piece of content has completely loaded and is visible, usually a hero image. Content refers to text, foreground images, background images, and elements. LCP complements First Contentful Paint (FCP), a metric that marks the initial web page loading experience. LCP calculates how quickly a user can see page content. Scores below 2.5 seconds are considered in the 'Good' range.

First Input Delay (FID) (Due to be replaced March 2024 by Interaction to Next Paint (INP))

First Input Delay (FID) measures page interactivity: how long it takes for a page to respond to input from the user, such as a key press or a mouse click. Low FID scores ensure pages are usable. FID is a real-world metric that cannot be measured in the lab. The Total Blocking Time (TBT) metric found in Lighthouse is lab-measurable and correlates with FID to simulate real-world interactivity.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) measures visual stability while the page is loading. This means that once displayed, a piece of content stays where it is; it does not jump around the screen as other content loads. Lower CLS scores mean that users are not experiencing unnecessary content shifts. CLS scores below 0.10 are 'Good'.

Understanding the rest of the Web Vitals

The Web Vitals metrics that are not part of the Core Web Vitals are Time to First Byte (TTFB), and First Contentful Paint (FCP). They provide additional ways to improve a web user’s experience, and help diagnose specific issues, either in the lab or in the field.

Time to First Byte (TTFB)

Time to First Byte is the time it takes for a user's browser to receive the first byte of page content.

First Contentful Paint (FCP)

First Contentful Paint (FCP) "measures the point from when a web page starts loading to when ANY content starts rendering on screen." The term 'Content' means text, images, <svg> elements, or non-white <canvas> elements. Just remember that FCP can be triggered very early in the page load, but may not necessarily deliver any visible content or information to the user.

Conclusion

Web Vitals are Google's attempt to unify the metrics webmasters use to measure the Page Experience of their site. With Core Vitals included in the ranking signals, site owners can see which performance measures Google treats as important. Measuring performance is the topic of our next few posts.