Peakhour.IO - Performance

How Browsers Decide Whether to Use HTTP/3

2026-07-29T00:00:00+10:00

There is no HTTP/3 switch inside the TLS handshake.

HTTP/1.1 and HTTP/2 both run over TCP. A browser can open TCP port 443, start TLS and use ALPN to choose between http/1.1 and h2. HTTP/3 runs over QUIC, which uses UDP. By the time a normal TLS-over-TCP handshake begins, the browser has already chosen the wrong transport for HTTP/3.

It has to learn that a QUIC endpoint exists first. Then it has to decide whether that information is worth acting on.

Those are separate problems. The discovery mechanisms are covered by standards. The exact decision to wait for DNS, start TCP, race QUIC, abandon a slow attempt or remember a failure is not.

That distinction explains why two browsers can visit the same site from the same network and use different HTTP versions without either one being broken.

Two ways to advertise HTTP/3

The older and more common route is an Alt-Svc response header:

Alt-Svc: h3=":443"; ma=86400

RFC 9114, the HTTP/3 specification, says an origin can advertise an equivalent HTTP/3 endpoint this way. The browser receives the header over an existing HTTP/1.1 or HTTP/2 connection, stores the alternative service and may try QUIC.

The catch is in the sequence. On a first visit, the browser needs an HTTP response before it sees the header. That first connection is already on TCP. A later request can use the cached HTTP/3 alternative.

DNS can provide the information earlier. RFC 9460 defines SVCB and HTTPS resource records. An HTTPS record can advertise ALPN protocols, ports, address hints and alternative endpoints:

example.com. 300 IN HTTPS 1 . alpn="h3,h2"

A browser that receives this record in time can attempt HTTP/3 on the first visit. It does not need to make an HTTP/2 request just to discover that HTTP/3 exists.

Neither advertisement proves that QUIC will work. UDP 443 may be blocked by a firewall, filtered by a corporate network or mishandled somewhere between the user and the edge. The certificate and authority still need to check out. The browser eventually has to test the path.

The standard stops before the interesting bit

RFC 9114 permits a client to try an advertised HTTP/3 service. If QUIC cannot be established, it recommends trying a TCP-based HTTP version. It does not set the browser's race timer or say how long a failed endpoint should remain suspect.

RFC 9460 is similarly careful. It gives the client a set of service endpoints and parameters. It allows TCP and QUIC attempts when the advertised ALPN set supports both. It does not prescribe one universal ordering algorithm.

So there is a standard for saying “HTTP/3 is available here”. There is no standard that says every browser must:

wait the same amount of time for an HTTPS DNS answer;
start QUIC before TCP;
race both immediately;
prefer the same IPv4 or IPv6 endpoint; or
retry a failed QUIC path after the same interval.

Those choices belong to the implementation. They also change.

What Chromium currently does

Chromium source shows why a neat flowchart quickly becomes misleading.

In its established connection path, Chromium can create separate jobs for the ordinary TCP route, a cached Alt-Svc alternative and an HTTP/3 endpoint learned through DNS. The HTTP stream job controller starts the alternative jobs and manages their competition with the main job.

The Alt-Svc information is not rediscovered on every request. Chromium reads it from its stored HTTP server properties, ignores alternatives already marked broken and can create a QUIC attempt from the remaining entry.

That last part matters. If the TCP job succeeds while HTTP/3 fails, Chromium can mark the alternative service as broken. Some failures are treated as specific to the current network and reconsidered after the default network changes. A failed QUIC attempt at the office does not have to poison HTTP/3 after the laptop moves to another network.

DNS discovery is conditional too. The legacy path checks that HTTPS-record ALPN support and QUIC are enabled, that the request is HTTPS, that the connection is direct rather than proxied, and that the DNS alternative is not already marked broken. Merely publishing alpn="h3" does not force Chrome to use it.

Current Chromium also contains a separate Happy Eyeballs v3 connection-pool path. When that path is enabled and eligible, the request leaves the older job-controller sequence. This is a useful warning for anyone interpreting packet captures: “Chrome races these three jobs in this order” may accurately describe one build and be wrong for another.

The durable conclusion is narrower. Chromium gathers candidates, uses remembered success and failure, and is prepared to let TCP and QUIC compete. The timings and plumbing are implementation details.

Firefox makes different choices

Firefox also has explicit HTTP/3 fallback policy rather than a simple protocol preference.

Mozilla's current preferences enable HTTP/3 and fallback to HTTP/2 on error. Its networking code can consume Alt-Svc advertisements and use a DNS HTTPS record as an Alt-Svc-like input.

That DNS path has conditions. In nsHttpChannel, HTTPS-record use depends on such things as the DNS strategy, proxy use, Firefox's encrypted-DNS mode and whether the current network has been judged able to resolve HTTPS records. In some circumstances Firefox waits for the record; in others it proceeds without making the request hostage to that answer.

When Firefox chooses an HTTP/3 endpoint learned from DNS, nsHttpTransaction has a fast-fallback path to a backup connection. After a failed HTTP/3 attempt it can also remove H3-capable SVCB candidates before retrying. If Firefox already has a usable HTTP/3 connection, the connection manager tries to dispatch work there before HTTP/2.

That is a real preference, but it is not a promise that every fresh Firefox connection starts with QUIC. Cached state, proxy configuration, DNS-over-HTTPS status and the current network all affect the choice.

What Apple documents, and what it does not

Apple's HTTP/3 technote recommends an HTTPS DNS record with alpn="h3,h2" for service discovery. It also supports Alt-Svc and explains the practical difference: DNS can make HTTP/3 available on the first transaction, while an Alt-Svc-only client may use HTTP/2 first and apply the remembered advertisement on a later request.

Apple also documents fallback to HTTP/2 or HTTP/1.1 when HTTP/3 is unavailable on the server or network.

That is good deployment guidance. It is not a published Safari endpoint-selection algorithm. WebKit is open source, but much of the Apple platform networking behaviour involved here sits below the rendering engine. We should not turn one Safari test on one release and operating system into a claim about every Apple device.

If Safari on macOS and Safari on iPadOS behave differently in a lab, record the versions, resolver, network and cache state. The difference is evidence worth investigating, not a new browser law.

DNS timing can decide the winner

An HTTPS record is useful only if the browser receives and uses it soon enough.

A, AAAA and HTTPS answers may arrive through different resolver paths and at different times. The browser can wait for more complete endpoint information or begin connecting with the address it already has. Waiting can produce a better candidate set. It can also add visible delay when the missing answer never arrives.

This is one reason browser traces vary with the operating system and DNS configuration. Chrome and Firefox both have internal DNS behaviour, but either can be affected by platform resolver choices, encrypted-DNS settings, proxies, caches and experiment flags.

RFC 10029, DNS Multiple QTYPEs, was published in July 2026 to let a DNS client request additional record types alongside its primary query. A client could ask for A, AAAA and HTTPS information and receive a combined response instead of waiting for three independently timed answers.

That removes one possible source of timing skew. Publication does not mean browsers, resolvers and authoritative servers support it yet. It also cannot make a blocked UDP path work.

Happy Eyeballs is growing beyond IPv4 versus IPv6

Happy Eyeballs originally dealt with a familiar failure: an IPv6 address exists, but the IPv6 path is slow or broken. Rather than make the user wait for a timeout, the client tries another candidate.

The active Happy Eyeballs Version 3 Internet-Draft generalises that work. Its candidate model can account for service endpoints, transport protocols and ALPN, not only IPv6 and IPv4 addresses.

That is the right shape for HTTP/3. A browser may be choosing among:

HTTP/3 over QUIC to an IPv6 address;
HTTP/3 over QUIC to an IPv4 address;
HTTP/2 over TLS and TCP to either address; and
endpoints with different priorities or ports from an HTTPS record.

Version 3 is still an Internet-Draft, not a finished standard. Chromium having a feature called Happy Eyeballs v3 does not mean its current behaviour is the final IETF algorithm, and it does not mean other browsers use the same timers.

What operators should do

Advertise HTTP/3 with both DNS HTTPS records and Alt-Svc.

The HTTPS record gives capable clients a chance to use QUIC on the first connection. Alt-Svc reaches clients that learn alternatives through HTTP responses and provides a second discovery path. Keep HTTP/2 working on TCP 443 because HTTP/3 is an additional path, not a safe replacement for fallback.

Then measure the versions separately. At the edge, record the negotiated HTTP version, QUIC handshake success, fallback rate, network and browser family. Test from clean profiles as well as warm ones: cached Alt-Svc and remembered QUIC failures can completely change the result.

When a test surprises you, capture more than the browser name. Record:

browser and operating-system versions;
whether the profile was new or had visited before;
the A, AAAA and HTTPS answers actually returned;
Alt-Svc value and cache lifetime;
whether UDP 443 worked on that network; and
whether a proxy, VPN or encrypted-DNS mode was active.

Cloud Fellows has published its protocol-negotiation and DNS HTTPS versus Alt-Svc test setup. It is useful for reproducing these cases and comparing results across browser versions, operating systems and resolver configurations.

HTTP/3 discovery has standards. Browser connection strategy is still a moving piece of software. For operators, the sensible response is not to predict one universal race. Advertise both paths, preserve fallback and measure what clients actually do.

Cache Tags/Surrogate Keys

2023-06-28T13:00:00+10:00

Caches are a way of storing information so future requests for the same data can be served more quickly. CDNs, including Peakhour, run caches on each of their POPs (Points of Presence). At that level these caches are key/value stores, where the key can be a combination of several request details, as outlined in our previous blog post on cache keys.

An established way to improve website performance is full page caching, where a copy of a full page generated by a CMS is stored in a CDN. For a cache hit compared with a cache miss, this can typically cut 1-4s off a page load.

Main document load before caching: 2.07s

Main document load after caching: 82ms!!

A Simple Cache Example

When a website changes a resource, such as a page or image, it can instruct the CDN to flush the cache entry for that resource's key. For example, say we have a page:

/about-us/

If we're doing full page caching, it will be stored in the CDN with the key "/about-us/". If it changes, we can issue a flush using the key "/about-us/" and the CDN will fetch a fresh version.

A blog example

But consider a blog article with the URL "/caching/caching-explained/". A typical blog has categories, tags, and authors. A link and summary for the article can exist on many pages: the home page if it's recent, the category pages that the article belongs to, the author page, and so on.

When we update the article, flushing only the key "/caching/caching-explained/" is not enough. We also have to find the other pages it appears on and flush them too, because they may have changed. That means issuing database queries to find all the pages that our article appears on, gathering them into a list, and issuing a flush for each of them.

An eCommerce example

Another example is an ecommerce store with lots of products and product categories. A particular product might appear on 100s of pages with its price displayed. When that price changes, the cached site needs to reflect it. You have two choices: do a lot of work on the server to discover the pages the product is on and flush them, or flush everything. Neither option is good. The first can slow your website to a crawl with database queries; the second forces the cache to repopulate.

Enter Cache Tags

Cache tags, also known as surrogate keys, are a mechanism for adding another way to find content in a cache. Unlike the primary cache key, these tags are not unique.

A website utilises cache tags by returning them in an HTTP header with the response. For example, Magento 2 uses the header X-Magento-Tags:

x-magento-tags: cms_b_site_home_main_banner,store,cms_b,cms_b_site_homepage_bar,cms_p_47,cms_b_header_custom_notice,cms_b_porto_custom_block_for_header_home5,cms_b_site_header_social_links,cms_b_site_home_shopby_category,cms_b_site_home_shopby_brand,cat_c_p_2,cat_p_2508,cat_p,cat_p_2483,cat_p_2387,cat_p_2372,cat_p_1412,cat_p_1388,cat_p_2575,cat_p_2560,cat_p_2557,cat_p_2543,cat_p_2520,cat_p_1262,cat_p_2434,cat_p_2423,cat_p_1660,cat_p_1579,cat_p_1276,cat_p_1217,cms_b_site_footer_social_links,cms_b_site_footer_contact_us,cms_b_site_footer_popular_items,cms_b_site_footer_quick_links,cms_b_site_footer_information

Magento returns tags for page elements like the navigation, sidebar, and notice, as well as for product categories and products. Products have tags in the format cat_p_1234, where 1234 is the product id in the database.

When someone updates product 1234, a flush is issued for the tag cat_p_1234 and all pages that have that tag are flushed. Magento doesn't have to do any work trying to determine which page the product might be on. The cache can efficiently find those cached pages and invalidate them.

Cache tags in CMSs

As mentioned, Magento 2 uses a sophisticated cache tag strategy to maximise the performance of its full page cache. Other CMSs, including Drupal 8/9/10 and Typo3, also utilise cache tags. Peakhour adds cache tags to WordPress, Prestashop, Magento 1, and Opencart via our plugins to enable full page caching.

Cache Tag support amongst CDNs

If you're looking for maximum full page cache effectiveness for your website, especially if you're using a CMS with built-in cache tag support, cache tag support matters. The table below outlines support amongst major CDN providers.

CDN/Cache	Cache Tag Support	Custom Header
Peakhour
Cloudflare	Enterprise Plan Only
Fastly
Self Hosted Varnish
Cloudfront

Enterprise or essential?

In our view, cache tags are an essential feature for any CDN trying to maximise cache performance. They make cache invalidation targeted and efficient, which protects hit rates and reduces work on the origin server. They shouldn't be walled off in an Enterprise-level package.

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.

Google AMP

2021-05-19T13:00:00+10:00

Google has announced that its long-maligned Accelerated Mobile Pages (AMP) platform is losing its preferential treatment in search results.

What is Google AMP?

Google introduced AMP as a way to provide optimised loading experiences on mobile devices. Google cached the content and served it from a Google domain name when it appeared in search results. Accelerated Mobile Pages ranked higher, and appeared in search results with a special badge indicating the page was fast loading, even if it didn't necessarily load faster than other sites. AMP was also a requirement for appearing in the Top Stories Carousel at the top of the results, or in Google News.

What is Changing?

Google is removing these advantages in search as part of the 'Page Experience Update', which is scheduled for June 2021. This update includes the much-blogged-about Web Vitals. Here's what Google said:

“The AMP format is no longer required and that any page, irrespective of its Core Web Vitals score or page experience status, will be eligible to appear in the Top Stories carousel. We're also bringing similar updates to the Google News app, a key destination for users around the world to get a comprehensive view of the important news of the day. As part of the page experience update, we're expanding the usage of non-AMP content to power the core experience on news.google.com and in the Google News app. Additionally, we will no longer show the AMP badge icon to indicate AMP content.”

Why is Google doing this?

AMP caused a large backlash from the internet community because many saw it as contrary to the idea of an open web. Google was inserting itself between the user and a website, and AMP introduced a number of headaches for webmasters. The official line is that with the new Web Vitals as ranking signals, Google didn’t want to overburden webmasters. However, given the control Google was exerting over websites with AMP, and the recent antitrust cases putting pressure on Google, it may simply have decided it was prudent to drop it.

What do I do now?

If you are currently using AMP, you can keep using it. If you aren't, you can concentrate on optimising your own website to create a good loading experience without using the Google-mandated way, and without being penalised. That's a good thing.

Conclusion

The imminent arrival of the 'Page Experience Update' means it's worth getting familiar with the Web Vitals and checking how Google views your site performance in the Chrome UX Report. And remember, Peakhour.io can make your website faster, more secure, and more reliable in under 5 minutes.

Website Optimisation

2021-05-17T13:00:00+10:00

We've previously covered ways to find resources that block rendering in a browser. Now we'll cover techniques for loading those resources without letting them block rendering. Before making changes, always run some website performance tests using your favourite testing tool to get a baseline so you can measure any improvements. We recommend testing with webpagetest.org.

Before we get into the techniques, it is worth defining the problem.

What is a Blocking Resource?

When a browser loads a page from a website it reads the HTML markup from top to bottom. If it encounters a CSS or JavaScript file while it's reading, the browser stops while it downloads and parses that file. While the browser is waiting it can’t process the rest of the HTML or display content to the user. Rendering is blocked.

Why is this a problem?

It would not be a problem if every page included only the information required to display it. Most websites do not work that way. They are typically built using prebuilt themes and third-party libraries that can contain lots of CSS and JavaScript. Only a tiny fraction of this code might be used on the current page, or it might only be needed for ‘below the fold’ content, or on another page of the site. Note: Below the fold means the content of a page that doesn't initially fit on the screen. Any unnecessary information keeps the browser blocked for longer than needed, slowing the load experience for the user.

CSS and JavaScript files are usually at the very top of the HTML document before any of the content. This means they have to be downloaded and parsed before the browser can display anything. Even a website that has extremely fast server response times can still seem very slow if it has blocking resources.

Take a simple example: a website that includes a live chat widget. The JavaScript for the widget is included at the very top of the page in the section. The browser has to stop, download, and parse the CSS and JavaScript for the widget (usually downloaded from a third-party domain) before any content is displayed to the user. The chat widget could appear after the rest of the content without affecting the user experience.

Things you should always be doing

Before targeting CSS- or JavaScript-specific techniques, cover the basics for both.

1. Minify all files

Minification is the removal of all non-essential characters in a file, e.g. irrelevant whitespace and code comments. It can make a substantial difference to the file size.

2. Ensure compression is enabled on your server

Make sure your server is configured to use either gzip or Brotli compression when serving CSS and JavaScript.

3. Self host files

If the CSS or JavaScript is on a third-party domain, i.e. not the domain name your website is on, you should strongly consider uploading the file to your website and serving it from your domain. This might not always be possible, but if it is it eliminates the overhead of the browser opening a connection to another domain, and it removes the possibility that the third party is not compressing, minifying, or using HTTP/2.

After the implementation of cache partitioning in the major browsers, there is no longer any potential advantage to using third-party CDNs to serve assets like JavaScript, fonts, or CSS. Make a copy on your server and host them on your domain.

4. If you can't self host then preconnect to third party domains

If external assets are on third-party domains, and you absolutely can't self host them, then you can improve loading by telling the browser to preconnect to the third-party domain.

Using preconnect tells the browser to establish an early connection to the domain before it has discovered the asset while reading the HTML. Use preconnect in the head of the HTML, e.g.:

Establishing early connections can shave 100-500ms off third-party load times, which is worth having. You should only use preconnect on critical third-party resources. For all the others you can use dns-prefetch, e.g.:

This tells the browser to perform DNS resolution of the domain early, which is similar to looking up a phone number in the phone book. Pre-resolving DNS can save 20-120ms. That sounds like small numbers, but remember, differences as small as 100ms can have large measurable impacts on conversion rates.

5. Select only what you need from frameworks

It is common for users of frameworks like Bootstrap or jQuery UI to only use a fraction of the functionality provided. If this is you, then the first step is to cut out what you're not using. Bootstrap and jQuery UI are modular, you can either download everything in one bundle, or you can break it up to take just the bits you are using.

These points will ensure that blocking resources are downloaded as quickly as possible. Now we can discuss some specific techniques that will help minimise blocking and get your page displaying quickly. Please be aware that this is not an exhaustive overview, but these techniques will probably get you 90% of the benefit with 10% of the work. Getting that last 10% requires deeper technical work. If you want to go there, Google’s web.dev website is a good resource.

Techniques for Optimising Blocking Resources

Javascript

There are a few different techniques for optimising the loading of JavaScript. First, let's look at the default loading behaviour. Credit for the images goes to Daniel Imms and his website Growing with the web. As stated earlier, the default behaviour is to stop parsing the HTML document when a script is encountered, download the script and execute it.

Now let's look at how we can change this behaviour.

1. Moving scripts to the very bottom of the page, right before the closing tag.

This is the original optimisation technique, before defer and async were introduced. It works by moving scripts to the very end of the HTML document, where they are downloaded and parsed after everything else.

In our example in the previous section, the chat widget would now load and pop up after the rest of the content has been displayed to the user.

2. Defer and Async

<script> tags that have a src attribute can be marked as either deferred defer, or asynchronous async, or both. For example:

<script src=”https://www.somedomain.com/somescript.js” defer async>

This tells the browser to change the script loading behaviour.

Defer

Defer was the original browser-based support for improved JavaScript loading. It tells the browser to download the script asynchronously while it keeps reading the HTML, and then execute it once it has finished reading the whole HTML document. Here's the loading behaviour with defer enabled.

As you can see the script no longer blocks the browser from doing anything else while downloading. Defer preserves script execution order. This can be very important if a script depends on one declared earlier in the page.

As noted earlier, you can only mark <script> tags that have a src attribute as deferred. Inline scripts, e.g.:

<script type="text/javascript">
    console.log("Hi I'm some inline script!");
</script>

Any attempt to defer that inline block will simply be ignored. This can cause problems if you have inline script scattered through your code and rely on a deferred third-party library, e.g. jQuery. There are two potential solutions if you can't simply move the code to the bottom of the page:

Move each inline code block into its own file and include it using the src attribute so you can defer it.
Or you can try declaring the block as a module. Test this carefully, as browser support may be limited and it also places the script into strict mode, which may break it.

Async

The async attribute tells the browser to download the script now and execute it as soon as it has finished. Like defer, the downloading is done asynchronously. Unlike defer, the script is executed as soon as it is downloaded. Here is the behaviour:

As you can see the browser doesn't stop while downloading, but does pause once downloading is finished so it can execute the script. async doesn't preserve script order, which can potentially cause issues when there are script dependencies.

All three methods have pros and cons. Defer and async result in faster page loads overall as the scripts are downloaded while the browser reads the HTML. Moving the script to the bottom of the page shifts the sequence around.

Your first option should be to defer all scripts. Then, if some above the fold content is taking too long because it has a JavaScript dependency, e.g. a carousel in the hero section, you can try making the necessary scripts async instead.

Optimising CSS

The key to fast CSS loading is to prioritise the CSS needed for the immediate above the fold content and then defer the rest. Many articles advocate extracting the precise CSS and then including it inline in the HTML document in a style block, i.e.:

<style type="text/css">
     .accordion-btn {background-color: #ADD8E6;color: #444;cursor: pointer;padding: 18px;width: 100%;border: none;text-align: left;outline: none;font-size: 15px;transition: 0.4s;}.container {padding: 0 18px;display: none;background-color: white;overflow: hidden;}h1 {word-spacing: 5px;color: blue;font-weight: bold;text-align: center;}
</style>

However, you have to do this on every possible landing page where the critical CSS might be different per page. Inlining CSS also adds to the download size for each page, and forces the browser to reparse the CSS rules for every load rather than being able to use a cached file for repeat views.

We advocate for putting the critical CSS into its own file and loading that normally, and then deferring any other non critical CSS. Identifying the critical CSS is the main task. The first thing to do is to look at the included CSS on your website and see if you can identify any non-core files. You can defer those files using this pattern:

<link as="style" href="/styles.css" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/styles.css"></noscript>

The as="style" lets the browser download the file asynchronously. The onload changes the type to stylesheet, telling the browser to parse the file. Finally, we include a <noscript> to enable the CSS to load normally if JavaScript is turned off.

Once you've deferred non-core CSS files you can still check whether your core ones contain lots of unused rules. Google Chrome's coverage tool can show unused rules, but it doesn’t let you easily export used and unused rules. You have to go through it yourself, programmatically, or use a third-party tool to make two files: the critical CSS, and the non-critical CSS which can be deferred.

Conclusion

Eliminating, or at least minimising, blocking resources can be one of the biggest improvements to user experience you can make to your site. With Google Web Vitals being introduced soon as a search signal, it is important to make sure your website loads as fast as possible so your users stay longer and buy more from your site.

Secure Dynamic Content Caching

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

Last time we covered how slow server performance can have a negative, sometimes very negative, effect on your website load times. The causes of slow server responses are many and varied, and not necessarily tied to the server specification. Diagnosing and dealing with them can be difficult, time-consuming, and costly. One practical way to reduce the impact is to look for opportunities to cache dynamic content.

What is Dynamic Content?

Content delivered by a web server is categorised as either static or dynamic. Static content is the same for every user and is delivered without being generated or processed by the server. Static content is fast to deliver and does not tax a server's resources.

Dynamic content is generated by the server for every request. That can involve querying a database several times and executing a large amount of code. Depending on the work required to generate the result, dynamic content can be resource-heavy.

Traditionally CDNs have only cached and served the static content of websites, usually the images, CSS files, Javascript files, etc. They required the webmaster to upload these resources to the CDN's servers and to modify their website source HTML to access the resources from the CDN. For example,

https://www.yourdomain.com/image1.jpg

would be changed to be something like

https://cdn.yourdomain.com/image1.jpg

Modern CDNs, like Peakhour, act as a reverse proxy{:target="learning"}, which means they sit between the end user and the website's origin server. This enables them to transparently cache a copy of anything cacheable being returned by the origin server. By transparently caching, we mean the caching happens without changes to the original website.

Full Page Caching

Full Page Caching (FPC) is where the actual HTML document of a web page is cached.

Most websites are built using a Content Management System (CMS). Widely used CMS platforms are Wordpress, Drupal, Magento, etc. By default, every time a page is viewed the CMS has to generate the content from its database. Most of the time this generation is unnecessary. The content is either the same for every user, changes very rarely, or only differs by a small amount of personalisation. In each case it is possible to perform Full Page Caching to improve page load times and to cut server load. Let's have a look at the difference full page caching makes to one of our clients, Magento 2 store savvysupporter.com.au.

Main document load before caching: 2.07s

Main document load after caching: 82ms!!

Caching the page has cut nearly 2 whole seconds from the download time. That matters: load differences as small as 100 milliseconds have measurable impacts on website conversion rates. With a Magento 2 website, it's possible to cache all full pages outside the checkout process and the customer/admin area. This can reduce load on the origin in the order of 60-70% and make the customer experience much better.

API (Application Programming Interface) Caching

Many API calls used by web applications are for the retrieval of information to be displayed to the end user. Examples include:

Pricing and product information
Form auto completion
Product catalogue searches

These are all strong candidates for caching, reducing load on your server and making websites faster.

Handling Stale Information

The one potential drawback of caching dynamic content is the possibility of returning out of date information to the end user. There are two strategies to deal with this risk.

Setting a short Time To Live (TTL) with the caching provider. By only keeping content cached for a short time, e.g. 5 minutes, the cache will never be without up to date information for very long. Cached content will expire and the new version fetched from the origin server. The drawback with this method is that, unless your site is very busy, cache hit rates can be low, users can frequently get slow loading pages, and stale content is still possible. However, for very busy sites this can be an effective, low-overhead strategy.
Flushing content when it changes. This strategy sets very long time to live in the cache, months or even years. When content is updated the cache is informed and the new version fetched. This notification of new content could happen manually or, in the case of some CMSs, automatically. For example, Magento 2 and Drupal 8 have a built in framework for integrating caching providers to handle flushing when content/stock changes. This strategy ensures very high hit rates, but unless the flushing is accurate and fast it can result in stale content.

Security-Performance Integration

Modern Application Security platforms like Peakhour combine caching with comprehensive security controls so performance optimisation does not weaken application protection:

Edge Security Processing

WAF/WAAP Integration: Security rules are processed at the edge before content is cached, ensuring malicious requests never reach your origin
Bot Management: Caching adapts based on traffic classification - legitimate users benefit from cached content whilst malicious bots are filtered out
API Protection: Secure caching of API responses with appropriate security headers and access controls

Cache Security Controls

Secure Purging: Authorised cache invalidation through secure API endpoints with proper authentication
Content Classification: Different caching policies for public, authenticated, and sensitive content
Header Security: Automatic injection of security headers (CSP, HSTS, etc.) into cached responses

Conclusion

Secure dynamic content caching works best when performance optimisation and application security are handled together. By implementing caching within an Application Security Platform, organisations can achieve:

Superior Performance: Dramatic improvements in load times and server capacity
Enhanced Security: Protection against threats at the edge before they impact cached content
Operational Efficiency: Reduced origin server load whilst maintaining security posture
Cost Optimisation: Lower infrastructure costs through intelligent caching and edge processing

For modern applications and APIs, secure dynamic caching should form part of the performance and security strategy, improving the user experience whilst maintaining threat protection.

Common Issues That Affect Website Performance

2020-11-30T13:00:00+11:00

Our last three website performance articles covered the why and how of testing website performance, and introduced our two favourite performance testing tools, WebPageTest.org, and Lighthouse. This article covers the common causes of slow loading times, and how to spot them using the same testing tools.

1. Latency

Latency is the time it takes for a request from a client's browser to traverse the internet to reach the website server. A number of factors affect latency, with physical distance usually the main one. Data on the internet travels at the speed of light, so distance may not sound like a major concern. In practice, small delays compound quickly. Here are some realistic examples of request latency:

Sydney to Melbourne: 5ms
Sydney to Perth: 25ms
Sydney to San Francisco: 75ms

NOTE: Common tools used to determine latency between servers are Ping and Traceroute, they will provide you with Request Round Trip (RTT) latency, ie the time it takes for a request to get to the server and back. So 2 times the numbers above.

Here is an example of latency during a webpage load. We'll ignore internet speed and any potential network congestion, and focus only on latency. We'll request a website hosted in San Francisco from a browser located in Sydney.

Browser establishes a TLS (Secure) connection with server, 6 * 75ms = 450ms
Browser sends HTTP Request for the main page = 75ms
Server sends HTTP Response containing page which specifies 10 assets = 75ms
Browser requests the 10 additional assets = 75ms
Server responds with 10 assets 10 * 75 = 750ms

In this example, a website with 10 assets, which is a fairly simple page, has nearly 1.5s added to the page load time through latency alone. If the same site was hosted in Melbourne, the time due to latency would be just 95ms. To solve this problem you would either move your website server closer to your customers, or use Peakhour Edge caching.

How do I check for latency problems?

If there is a long distance between your server and your customers, eg your website is hosted in the US and your customers are in Australia, page load times will be significantly affected by latency. A good tool for indicative RTT times between cities is provided by wonder network. Webpagetest.org also provides a Traceroute tool which can give you indicative RTT times between its testing locations and your website.

2. Old version of HTTP

Browsers communicate with websites using a protocol called HTTP. The protocol formalises the steps needed to connect a browser and server so a webpage can be downloaded. Since the introduction of the web, HTTP has gone through a number of revisions. The currently widely adopted version is HTTP/2.

Even though HTTP/2 was introduced over 5 years ago, over 50% of websites are still only served over HTTP/1.1. Without getting too technical, HTTP/2 has significant advantages over older versions because it reduces the number of connections between a browser and server, and transfers information more efficiently.

Serving your website over HTTP/2 can improve page load times by 10-15%.

How do I identify the version of HTTP my website is served over?

Run a performance test of your website using WebPageTest.org, once complete click on the 'Details' link in the report navigation. You will see the Waterfall View. Click on the first request, circled below in this image:

It will bring up the request details including the Protocol used, circled below:

3. Slow Server Performance

A slow initial response from the server is a common cause of poor page load performance. The majority of websites are built using some sort of Content Management System (CMS), eg Wordpress, Magento, Drupal, Shopify, to name a few. By default, a CMS has to construct a page each time a browser requests it, even when the content has not changed. That process can involve executing a lot of code and querying a database several times before returning the HTML that forms the page.

The specification of your server, the number of CMS plugins, the state of your database, and the number of simultaneous users can all affect the response time. A slow server may take 10s or more to respond, while even a fast server can still take over a second to generate a page. That is enough to pretty much make you fail the new Core Web Vitals guidelines before you even get started.

How do I check for slow server performance?

Server performance can be checked from the waterfall view in WebPageTest.org. The time taken to download the main document indicates whether server performance is affecting your page load. Here's an example:

The total time taken to download the main document here is over 1.3s. That is not too bad, but it has already used up over half the 2.5s required to achieve 'Good' for the Largest Contentful Paint (LCP) metric in web vitals

4. Page Weight

Even though internet speeds are getting faster, they are still a limiting factor to how fast a browser can download a page. If the requested page and the associated resources, eg images, javascript, CSS, are large files, it will take longer for the browser to download all the required information to display a page. Unoptimised images are a common culprit for inflating page weight. Unoptimised CMS themes and third party javascript libraries are another.

How do I check my page weight?

WebPageTest.org reports the page weight in the far right of its summary, circled here:

You should be aiming for 2mb or less. This particular website is more than a little obese, coming in at around 30mb... WebPageTest also has a section called 'Content Breakdown' which shows where the weight is, ie in images, javascript, etc.

Over 27mb in images is what's weighing down this page.

Peakhour also has a pageweight tool that you can run for a page on your website and receive a full optimisation report for the images on the page, along with downloadable optimised images.

5. Blocking Resources

Resources that can block a page include CSS and javascript. When the main HTML page is downloaded and parsed, the browser will not render anything to the screen until the CSS and javascript files that are referenced are downloaded and parsed. If your website includes a lot of CSS and javascript, which is not uncommon for pre built themes for CMS's like Wordpress and Magento, the downloading and parsing of these files can delay the browser from showing any content for several seconds.

How do I identify blocking resources?

The easiest way to check is to use Google Lighthouse) to identify them for you. After running the report, go to the opportunities section and expand the 'Eliminate render-blocking resources' section to see what it finds.

6. Third Party Resources

It is very common for websites to include third party resources. These are files that have to be fetched from a domain/url other than the one that the page is being requested on. Eg if you are requesting www.domain.com.au, it might include a resource from a third party, eg www.anotherdomain.com.au. Common third party resources might be analytics scripts (eg Google analytics), marketing tools (eg Mailchimp)

This forces the browser to open another connection to the third party. The time taken to do this, combined with the possibility that the third party might be slow to respond (see latency and server performance above), can often ruin load times. If the resource in question is also a blocking resource the problem is compounded.

Spotting a problem with third party resources

WebPageTest has a section 'Domains' which displays all the individual domains that the browser connected to when loading the page:

If your website is requesting resources from more than 10 separate domains then you should consider why that is happening and whether they are necessary. If you are using external CDNs to load javascript or CSS then you should probably move them onto your domain.

Social sharing plugins are notorious for pulling in a lot of resources from external domains. You should replace any share buttons using external scripts with simple static buttons. It is simple to do, and your website will be much smaller and faster. By using the javascript shares that social sites prescribe, you are slowing down your website and allowing third parties to track your clients across the internet.

Conclusion

There are many factors that can slow down your website, drive away customers, and cost you money. You have to regularly test your website to check for issues and address them when you find them. Next we'll cover what you can do to fix the issues we've mentioned here.

Are Australian Magento Stores Ready For Web Vitals?

2020-11-19T13:00:00+11:00

Google recently confirmed that the Core Web Vitals will be included as search signals from May 2021. This means that, all else being equal, sites that score well on the Core Web Vitals are likely to rank ahead of those that don't.

A quick refresher of Web Vitals

The Core Web Vitals consist of three metrics, chosen to measure the experience of browsing a website. Here they are, along with the current thresholds for a 'Good', 'Needs Improvement', or 'Poor' rating:

Web Vitals also defines several other metrics, including Time to First Byte (TTFB), and First Contentful Paint (FCP). While these aren't 'core' metrics, they are useful for diagnosing where performance problems come from. The target TTFB in the current version of Google Lighthouse is listed as 100ms, while poor is 600ms. FCP is good under 2s and poor over 4s.

How will Australian sites fare?

We asked a simple question: what percentage of Australian websites are ready for Web Vitals as a search signal, and what percentage could lose ground? To answer it, we ran them through our recently released Website Speed Comparison tool, which gathers Web Vitals metrics as part of its report.

Methodology

There are a lot of Australian websites, so we broke the analysis down by technology platform. We started with online stores running Magento.

We started with an initial list from BuiltWith of around 4000 domains. We then trimmed it down by removing development and demo sites, and sites returning an error, leaving a total of 2998. The list includes some of the largest retailers in Australia, including Harvey Norman, Sportsgirl, Philips and Dyson.

We then ran our competitor report for every one of them. The report was run from our Sydney office over a business-class internet connection. The test throttles the connection to simulate typical 4G mobile phone speeds, and uses a mobile phone user agent/screen size to view the mobile version of the site. We did not throttle CPU performance like Lighthouse does.

NOTE We're excluding First Input Delay in our results as Google defines First Input Delay (FID) as a real user measurement (RUM). FID measures the time taken for the website to respond to the first user interaction, such as clicking a link or button. Technically this interaction can happen any time after the first content appears in the browser; in practice, most people won't click something until after a page is visually complete, and this timing is highly variable. We do measure First Input Delay by simulating a click, but our interaction happens soon after the FCP, while content is still loading. That would cause more sites to fail the metric than would fail in real life, so we're excluding it from our calculations.

On to the results. We did not expect strong numbers, but the results were still worse than expected.

The results

The first check was for the number of websites that achieve a good rating in any of the Web Vitals metrics.

	TTFB (< 0.1s)	FCP (< 1s)	LCP (< 2.5s)	CLS (<.1)
Percentage of sites that are 'Good'
Result	99 (3.3%)	71 (2.37%)	254 (8.47%)	1074 (35.8%)

CLS was the strongest result, which isn't a surprise. The remaining results are not encouraging: only 8.5% pass LCP. Let's see how many need improvement.

	TTFB (< 0.6s)	FCP (< 2s)	LCP (< 4s)	CLS (< .25)
Percentage of sites that 'Needs Improvement'
Result	383 (12.7%)	728 (24.3%)	470 (15.7%)	625 (20.8%)

An additional 15.7% beat the 4s cut-off for LCP. That still means that 3/4 of Australian Magento stores take longer than 4s to visually load on a mobile device. Visualised, the numbers are not pretty.

Australian Magento sites are likely missing potential sales. Recent performance studies show:

The probability of a customer bouncing increases 90% if the page load time increases from 1s to 5s. (source Google)
A 100 millisecond delay in load time can hurt conversion rates by 7%. (source Akamai)

The experience of our own Magento 1 clients and Magento 2 clients backs this up: improving website speed affects conversions and revenue.

Sites that pass all criteria

Of our 2998 websites, we only found 163 that pass Core Web Vital 'good' criteria. That's only 5.5%.

If we again relax to include 'needs improvement' that list grows to 520, or 17.3% of sites tested.

How you can test your site

Google provides online analytics that you can query via BigQuery. If you want to reproduce the report this analysis is based on and compare your website to your competitors, you can use the Peakhour.IO Website Speed Comparison report. We automatically discover your competitors, run them through Web Vitals, and graph the results.

Conclusion

If nothing changes, quite a few Australian Magento stores could lose search visibility in May 2021. The majority of sites don't use Magento 2's ability to cache dynamic pages, and if they do, they're often not serving optimal images.

Core Web Vitals becomes a search signal next year. For Magento teams, it is time to get ready.

Test Your Website Performance With Google Lighthouse

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

Lighthouse is useful when a page feels slow but the cause is still vague. It runs a controlled load, measures performance, accessibility, best practices and SEO, then connects failed audits to the part of the page that needs work.

You can run Lighthouse in Chrome DevTools, PageSpeed Insights, the command line, or a Node module. We use DevTools when the page needs a login or a particular browser state, and PageSpeed Insights when we want a quick public-URL test with CrUX field data beside the lab result. Google's current Lighthouse documentation covers each workflow.

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 several ways to run a Lighthouse report:

In Chrome DevTools;
In PageSpeed Insights;
From the command line or a Node integration;
In Lighthouse CI for repeatable build checks.

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:

The performance score is a weighted combination of lab metrics including Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, First Contentful Paint and Speed Index. Lighthouse changes those weights as its model changes, so read the metric values and failed audits instead of treating an old screenshot's score as a permanent benchmark. Google publishes the current scoring method and weights.

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.

PageSpeed Insights and field data

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.

Use the score to find the work

Run Lighthouse more than once, keep the device and network assumptions visible, and compare the individual metrics before chasing the headline score. Use WebPageTest when you need the waterfall and request-level diagnosis. Use CrUX or your own RUM when the question is what real users experienced over time.

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 was created and open-sourced by Patrick Meenan in 2008. Catchpoint acquired WebPageTest in 2020 and operates the hosted service. The official code remains available for teams that need to run their own instance, with licence terms that differ between its active and Apache branches.

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 scripted multi-step journeys. 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.

Application Performance Optimisation

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

Website performance testing is most useful when it explains where a request lost time. A single score can tell you that a page is slow, but it rarely tells the site team what to change next. The better starting point is the request path: where the visitor is, where the origin is, whether the response was cached, how much the browser had to download, and what work blocked rendering or interaction.

This article is a primer for that diagnosis. Start with a representative page, test it from a location that matches your users, then read the evidence in order.

Start With the First Request

The browser cannot render a page until it receives the main HTML document. That first request includes DNS lookup, TCP connection setup, TLS negotiation, any redirect, cache handling, origin processing, and the first byte coming back. When the origin is far away, latency compounds. Peakhour's performance material uses simple Australian examples: Sydney to Melbourne is about 5 ms one way, Sydney to Perth about 25 ms, and Sydney to San Francisco about 75 ms. Those numbers become larger when a page load needs several round trips.

This is why the main document matters in WebPageTest. In one Peakhour example, the main HTML document took 149 ms, which is fast. Many sites take 2 to 5 seconds before the browser receives that document. If the main response is already slow, the page has little chance of a good Largest Contentful Paint because the browser has not yet discovered the resources needed to paint the largest content.

Cache state is part of the same first request. A cache hit at the edge should look different from a miss that forwards to origin. Headers such as Cache-Status can show hit, miss, TTL, stored state, cache key, and collapsed request behaviour. Without that evidence, teams often guess whether a slow page is caused by the CDN, the origin, the application, or a cache-bypass rule.

Use WebPageTest for the Waterfall

WebPageTest is useful because it loads the page in a real browser and lets you choose test locations and connection profiles. That matters for Australian sites because a test from the wrong continent can make a local problem look worse or hide a regional problem from view.

The waterfall is the main working view. Read the first rows before looking at the rest of the page. A redirect on the first request adds delay before the useful page is even requested. Long DNS, connect, or TLS blocks point to connection setup or third-party domains. A long wait on the main document points to cache miss, origin processing, or backend work. Large downloads point to page weight. Red rows show broken requests, and the domain view shows how many external services the browser had to contact.

The filmstrip is just as important. It shows what the user saw while the waterfall was happening. If the HTML arrived quickly but the filmstrip stayed blank, the issue may be render-blocking CSS, JavaScript, fonts, or a hero image. If the page starts to render quickly but then jumps, you are looking at layout stability, not just network speed.

Use Lighthouse for Browser Work

Lighthouse is good at surfacing work inside the browser. It runs a controlled test, reports Core Web Vitals-related metrics, and lists opportunities such as eliminating render-blocking resources, reducing unused CSS, deferring JavaScript, compressing assets, and reducing main-thread work.

Treat the score as a prompt, not a verdict. Lighthouse scores can vary between runs because the local CPU, network conditions, and server response can vary. The useful part is the diagnostics. If Lighthouse points to a font, a theme stylesheet, or a third-party script that delays rendering, compare that with the WebPageTest waterfall and filmstrip. If both tools point to the same resource, you have a stronger case for change.

Connect Metrics to Causes

Core Web Vitals are easier to act on when each metric is tied to the part of the path it describes.

Symptom	Where to look	Likely next question
High TTFB	WebPageTest first row, cache headers, origin logs	Did the request hit cache, miss to origin, or wait on application work?
Slow FCP	Waterfall, filmstrip, render-blocking resources	Did HTML, CSS, or synchronous JavaScript stop the first paint?
Slow LCP	Main document timing, hero media, image weight	Was the largest element discovered and delivered early enough?
High CLS	Filmstrip, image dimensions, injected banners, fonts	Did content move after the visitor started reading?
Poor INP	Lighthouse main-thread diagnostics, third-party scripts	Is JavaScript delaying the next paint after interaction?
High page weight	WebPageTest content breakdown	Are images, JavaScript, fonts, or unused assets carrying the load?
Too many domains	WebPageTest domains view	Which third-party services are adding connection setup and blocking work?
Unclear cache behaviour	`Cache-Status`, CDN analytics, debug headers	Which paths are hits, misses, bypasses, stale responses, or collapsed misses?

This table is not a checklist to run forever. It is a triage map. Pick the symptom that matches the page, then follow the evidence to the next request-path decision.

Diagnose the Common Failures

Latency is the first failure to rule in or out. If the origin is in the United States and most customers are in Australia, the page can lose time before WordPress, Magento, Drupal, or a custom application has done any work. Edge caching helps when the response is safe to reuse, because the first byte can come from a location closer to the visitor.

Page weight is the next obvious drag. WebPageTest's content breakdown shows whether images, JavaScript, CSS, fonts, or other assets dominate the transfer. Unoptimised images are common, especially on CMS and ecommerce sites. Image variants in AVIF or WebP, responsive sizes, compression, and stable dimensions can improve both download time and LCP.

Render-blocking resources explain why a page can download quickly and still look blank. CSS and synchronous JavaScript in the head can stop the browser from painting. Large theme bundles and plugin scripts often include code that is not needed on the current page. The fix might be removing unused files, deferring non-critical scripts, splitting code by route, self-hosting critical third-party resources, or using preconnect only where the first view depends on a third-party domain.

Third-party domains need a sober review. Analytics, marketing tags, chat widgets, social embeds, payment scripts, and fonts can all be legitimate. They can also add DNS, TCP, TLS, download, parsing, and main-thread cost. If a third-party script is not needed for the first view, it should not block the first view.

Where Peakhour Evidence Fits

Peakhour performance work should show both user experience and origin relief. For caching, that means hit ratio, miss causes, Cache-Status, purge state, cache keys, shielded misses, collapsed requests, and origin fetch volume. For images, it means original size, transformed size, selected format, responsive variant, and cache hit state. For Core Web Vitals, it means LCP, CLS, INP, TTFB, page weight, and the same page tested before and after changes.

Security belongs in the performance review when it changes the request path. Bot filtering, WAF rules, rate limits, and login protection can reduce origin load by stopping abusive or noisy traffic before PHP, database, search, or API work begins. They can also create friction if rules are too broad. Measure the edge decision, the latency, the origin effect, and the false-positive risk. Do not treat "security enabled" as a generic performance story.

Good performance testing ends with a specific change to validate: cache this public route, purge it by tag, move this script later, replace this image variant, reduce these third-party domains, protect this login path, or investigate this slow origin query. Then run the same test again from the same location and compare the evidence.

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.

WordPress Performance Optimisation

2019-05-27T13:00:00+10:00

WordPress speed problems are usually request-path problems. A public article, product page, or campaign landing page should not make PHP, plugins, and the database rebuild the same HTML for every visitor. A login attempt, checkout session, admin request, or private API call should not be treated like public content just because the site is under load.

The job is to separate those paths clearly. Cache what can be reused, protect the routes that are expensive or abused, and keep enough evidence to prove that the change improved the visitor experience without hiding origin risk.

Start With Public Page Caching

Most WordPress sites have a large set of pages that are dynamic only because WordPress generated them. The content itself is public and often identical for many visitors: posts, pages, category archives, product listings, campaign pages, media assets, CSS, and JavaScript. These are the paths where full-page caching and edge delivery can change the result quickly.

When a public page is served from cache, the browser avoids the long trip to origin and the origin avoids running WordPress for a repeat response. That can move Time to First Byte and Largest Contentful Paint in the right direction before anyone touches the theme. Peakhour's older full-page caching examples showed the practical size of this change: a Magento main document fell from 2.07 seconds before caching to 82 ms after caching. WordPress sites have different internals, but the same pattern applies when anonymous pages are safe to reuse.

The cache policy should be route-aware, not blanket. A simple operating model looks like this:

WordPress path	Delivery stance	What to check
Posts, pages, category pages, campaign pages	Cache publicly with tags and purge controls	Confirm logged-out content is shared and fresh after publishing.
Featured images, media library files, theme assets	Cache and optimise variants	Track image weight, format, dimensions, and cache hit state.
WooCommerce product and category pages	Cache when no cart/session dependency changes the response	Keep stock, price, and promotion purges tied to content changes.
Cart, checkout, account, previews, admin	Bypass shared cache	Preserve session privacy and correctness.
`wp-login.php`, `/wp-admin/`, `xmlrpc.php`, sensitive plugin endpoints	Protect and rate-limit before origin	Keep noisy automation away from PHP workers and admin paths.

Publishing Should Not Clear the Whole Site

Caching WordPress is easy until someone edits content. Clearing the whole cache after every post update is safe in the narrow sense, but it damages hit ratio and pushes avoidable traffic back to origin. During a busy publishing period or campaign, that can make the site slower exactly when fresh content is being promoted.

Cache tags are a better fit. Tags label cached responses by the content or template they depend on, so a post update can purge the post, related archives, and affected modules without invalidating unrelated pages. The updated Peakhour WordPress plugin generates cache tags automatically and sends purge requests when content changes in the WordPress admin. That lets teams set longer cache lifetimes for public content while still publishing with confidence.

This is where advanced caching becomes operational rather than theoretical. The site team can review which tags were purged, which routes stayed cached, and whether the next request was a hit, miss, or stored response.

Images and Browser Work Still Matter

Page caching improves the start of the request path. It does not fix a 3 MB hero image, missing image dimensions, unused CSS, or a third-party script that blocks rendering. WordPress themes and plugin stacks often ship CSS and JavaScript for features that are not used on the current page. The browser still has to download and parse that code before it can paint useful content.

Use Lighthouse to find render-blocking resources and main-thread pressure. Use WebPageTest to see whether the main HTML arrived quickly but the filmstrip still stayed blank while CSS, fonts, scripts, or images loaded. Those are different failures, and they need different fixes.

For images, the best results usually come from serving the right variant rather than only compressing the original. Peakhour image optimisation can generate AVIF or WebP outputs, choose responsive sizes, and cache the resulting variants. That helps LCP when the largest visible element is an image, and it helps CLS when dimensions are kept stable.

For CSS and JavaScript, remove unused files where possible, defer non-critical scripts, self-host critical third-party assets when practical, and reserve preconnect for third-party domains that genuinely affect the first view. Moving every script later can break dependencies, so test the actual page type rather than applying a generic rule across the whole theme.

Protect Expensive WordPress Paths

Performance and security meet at origin capacity. Login floods, XML-RPC abuse, aggressive crawlers, scraper traffic, and noisy plugin endpoints can consume PHP workers and database connections that should be serving real visitors. If those requests are filtered only after WordPress has loaded, the site can look like it has a speed problem when it really has an unsorted traffic problem.

For WordPress, protection should be specific. wp-login.php, /wp-admin/, xmlrpc.php, the REST API, and plugin-specific endpoints should have their own bot, WAAP, and rate-limit policy. WooCommerce needs separate handling again: public catalogue pages can often be cached, but cart, checkout, account, and payment paths must stay dynamic and private.

This does not mean putting heavy checks in front of every visitor. It means making edge decisions before origin work: allow clean public page requests, serve cache hits, challenge or rate-limit suspicious login traffic, bypass cache for private sessions, and log what happened.

Measure the Outcome

The evidence should line up across tools. WebPageTest should show a faster main document on cache hits, fewer slow origin fetches, and a waterfall where critical resources are visible early. Lighthouse should show fewer render-blocking opportunities and less main-thread pressure. Core Web Vitals should move where the page had the relevant bottleneck: LCP for slow HTML or heavy hero media, CLS for unstable layout, and INP for JavaScript and interaction work.

Peakhour evidence should add the delivery side: cache hit ratio, miss causes, purge state, Cache-Status, image savings, shielded misses, blocked login or XML-RPC abuse, and origin request volume. That combination tells the site team whether WordPress is faster because visitors received lighter pages from the edge, because abusive traffic stopped draining origin, or because browser work was reduced.

Fast WordPress is not a plugin list. It is a set of clear route decisions backed by before-and-after measurements.