Peakhour.IO - Drupal

HTTP Security Headers

2023-11-28T14:00:00+11:00

Traditionally, web security has focused on the server side: protecting the application itself from attack. That work is necessary, but it often leaves the client side under-specified. Client-side attacks move the exposure point into the user's browser, where the business impact can be serious.

Magecart attacks are a clear example. Attackers inject skimming scripts into websites to steal sensitive customer information, such as credit card details, directly from the user's browser. Session hijacking and Cross-Site Scripting (XSS) attacks also exploit browser vulnerabilities, leading to unauthorised access and data breaches. These attacks don't just risk user data; they can erode trust, damage reputations, and result in significant financial and legal repercussions for businesses.

HTTP security headers are practical controls for these types of attacks. Properly implemented, they instruct browsers on how to handle website content and interactions safely.

Key HTTP Security Headers

Content-Security-Policy (CSP)

Purpose: CSP prevents Cross-Site Scripting (XSS) attacks by specifying which sources browsers should allow when loading scripts, images, and other resources. It can also prevent MageCart-style attacks by restricting the host names that an injected script can communicate with.

Content-Security-Policy: script-src 'self' https://apis.google.com;

This example allows scripts to load only from the site's own domain ('self') and https://apis.google.com.

X-Frame-Options

Purpose: This header protects against clickjacking attacks by controlling whether a browser allows a page to be rendered in a <frame>, <iframe>, <embed>, or <object>.

X-Frame-Options: DENY

This setting prevents any domain from framing the content. Another option is SAMEORIGIN, which only allows framing by the same site.

X-Content-Type-Options

Purpose: This header prevents MIME-sniffing, where a browser might incorrectly interpret the content type of a resource, leading to security vulnerabilities.

X-Content-Type-Options: nosniff

This instructs the browser to follow the content type declared in the HTTP headers.

X-XSS-Protection

Purpose: This enables the browser's inbuilt XSS protection features. However, this header is largely deprecated in favour of CSP.

X-XSS-Protection: 1; mode=block

This configuration enables the protection and tells the browser to block the page if an XSS attack is detected.

Strict-Transport-Security (HSTS)

Purpose: HSTS forces the browser to use HTTPS over HTTP, ensuring encrypted communication and protecting against man-in-the-middle attacks. Alternatively, you can automatically redirect all requests to HTTPS on your web server or at your EDGE provider. For example, Peakhour allows you to set up EDGE redirects to force all traffic to HTTPS.

Strict-Transport-Security: max-age=31536000; includeSubDomains

This example tells the browser to use HTTPS for all subdomains for one year.

Conclusion

Implementing the correct HTTP security headers is a straightforward way to improve web application security. These headers form part of the first line of defence against many common security vulnerabilities. As threats evolve, keeping security headers current and properly configured helps safeguard your users and your brand.

Enterprise-Level Caching for All

2023-11-02T13:00:00+11:00

We've released our Magento 2 plugin for e-commerce stores using Magento. It brings Peakhour's caching features into Magento, including capabilities that other providers often reserve for enterprise plans. With Peakhour, 'Enterprise for Everyone' means making those features available to all customers, regardless of plan.

Why Cache Tags Matter

Cache tags solve a practical website management problem: keeping your cache current when content changes. In Magento 2, a single change, such as updating a product's price, can affect multiple pages. Cache tags ensure that only the relevant cached content is updated, maintaining cache efficiency and reducing server load. That matters for website speed and user experience, which directly affect sales and SEO rankings.

Enterprise for Everyone

While other providers offer cache tags only in expensive enterprise plans, Peakhour makes this feature available to everyone. Our infrastructure and caching algorithms make that possible. We also offer other enterprise-level features, including DDoS protection, real-time analytics, and custom caching rules, so 'Enterprise for Everyone' is reflected in the product rather than just the plan names.

Peakhour vs. Magento and Varnish Caching

Our plugin goes beyond Magento's built-in caching and Varnish cache in several ways:

Custom Cache Tags: Unlike Magento's built-in cache, we offer custom cache tags for more granular cache control.
Advanced Algorithms: Our caching algorithms go beyond Varnish, helping improve cache hit rates and lower server load.
Additional Features: With Peakhour, caching sits alongside real-time analytics, DDoS protection, and custom caching rules, features often missing in standard Magento or Varnish setups.

Expected Performance Improvements

By using Peakhour's Magento 2 plugin, you can expect performance improvements:

Faster Page Loads: Our caching can reduce page load times by up to 50%, giving users a smoother experience.
Reduced Server Load: Efficient caching means fewer requests to your origin server, reducing server load by as much as 70%.
Improved SEO: Faster websites are favoured by search engines, which can improve SEO rankings.
Higher Conversion Rates: A faster website gives users a better experience, which can lead to higher conversion rates and increased sales.

Installation Options

You can install the Magento 2 plugin through Magento Connect, Composer, or a ZIP file. For more detail, see our plugin page.

Useful tips to accelerate your Magento store

2023-11-01T13:00:00+11:00

Out of the box, Magento is not the fastest ecommerce platform. Magento 2 is built with Full Page Cache in mind, so repeat page requests do not always have to hit the application. A slow Magento store can frustrate customers, increase bounce rates, and cost sales. There are several practical ways to accelerate your Magento store and improve the user experience. These are good places to start.

Caching is King

Caching is usually the biggest performance lever for a Magento store. By storing pre-generated versions of pages, you reduce server response times and avoid asking Magento to rebuild the same page for every request.

Full Page Caching (FPC): Magento includes built-in FPC, but it can be extended. Varnish is a common choice for this role. Magento 2 has native support for Varnish, which acts as a web application accelerator.
Redis: Use Redis for session and cache storage. It is an in-memory data structure store that can speed up backend operations by reducing database load.
Edge Caching: Use Peakhour Edge to cache your dynamic pages close to users. This serves content from a nearby delivery path and reduces latency. Peakhour's Magento 1 and Magento 2 plugins make this straightforward to set up.

Optimise Your Images

Images often make up the bulk of a page's weight. Optimising them is one of the simplest ways to improve load times.

Compression: Use image compression tools to reduce file sizes without a noticeable loss in quality.
Next-Gen Formats: Serve images in modern formats like WebP or AVIF, which offer better compression. A CDN can often handle this conversion automatically.
Lazy Loading: Implement lazy loading for images that are "below the fold" (not immediately visible). This means they only load when they are about to enter the user's viewport.

Minify and Merge CSS/JavaScript

Magento has built-in features for merging and minifying CSS and JavaScript files.

Minification: Removes unnecessary characters (like whitespace and comments) from code to reduce file size.
Merging: Combines multiple CSS or JavaScript files into a single file to reduce the number of HTTP requests.

Note: Always test thoroughly after enabling merging, as it can sometimes cause issues with certain themes or extensions.

Keep Your Environment Updated

The environment your Magento store runs in has a direct effect on performance.

Latest PHP Version: Use the latest stable version of PHP supported by your Magento version. Each new release brings performance and security improvements.
Server Resources: Ensure your server has adequate RAM and CPU power to handle your traffic, especially during peak times.
Web Server: Use a high-performance web server like Nginx, which is known for its speed and efficiency.

Use Edge Caching and Delivery

An edge delivery layer is a practical requirement for many ecommerce stores. It caches your static assets (images, CSS, JavaScript) close to users.

Reduced Latency: Users receive content from the server geographically closest to them, which speeds up load times.
Reduced Origin Load: By serving cached content, an edge cache reduces the number of requests that hit your origin server, improving its performance and stability.
Enhanced Security: Peakhour also offers security features like a Web Application Firewall (WAF) and DDoS protection.

Database Optimisation

A slow database can slow the whole store.

Clean Logs: Regularly clean out Magento's log tables (e.g., log_customer, log_visitor). These can grow very large and slow down database queries.
Enable Flat Catalog: For Magento 1 and older versions of Magento 2, enabling the Flat Catalog for products and categories can improve performance by reducing the complexity of database queries.
Re-index Regularly: Keep your Magento indexes up to date. A cron job should be set up to handle this automatically.

Audit Third-Party Extensions

Poorly coded or unnecessary third-party extensions are a common cause of Magento performance issues.

Review Extensions: Audit your installed extensions regularly. If you're not using one, disable or uninstall it.
Use a Profiler: Use Magento's built-in profiler or a tool like New Relic to identify slow-running code, which can often be traced back to a specific extension.

These changes will not fix every Magento performance problem, but they cover the areas that usually matter first: cache behaviour, asset weight, the hosting environment, database maintenance, and extension overhead.

Vary Cache on Cookie Value

2023-08-03T13:00:00+10:00

On most websites, a user requests a page and receives the same response as everyone else. Some websites, however, change the content depending on who is visiting. For example, someone visiting from Australia might get the page in English, while someone visiting from Spain gets it in Spanish.

The Vary Header

The HTTP Vary header is the standard way to tell a cache that the content of a page can change depending on a request header. For example, if a website returns this header:

Vary: Accept-Language

It tells any cache that the content can change depending on the language preference of the user's browser. The cache then stores a separate copy of the page for each language.

That works for standard request headers, but content often changes based on something else. For example, a user might be able to select their currency on an ecommerce store. This preference is usually stored in a cookie.

A common, but problematic, way of handling this is to return:

Vary: Cookie

This tells the cache to store a separate version of the page for every unique Cookie header it sees. The problem is that the Cookie header can contain many different cookies (e.g., for analytics, session tracking, etc.), creating many cached versions and a very low cache hit rate. This effectively makes caching useless.

Varying on a Specific Cookie Value

A better solution is to vary the cache based on the value of a specific cookie. For example, an ecommerce store might use a cookie named currency to store the user's preference. By instructing the CDN to look only at the value of the currency cookie, it can store separate cached versions for AUD, USD, EUR, etc., while ignoring all other cookies.

This means you can serve personalised, dynamic content while still benefiting from a high cache hit rate.

Use Cases

Varying the cache on a cookie value is useful for dynamic websites:

Multi-Currency/Multi-Lingual Stores: Serve cached pages with the correct currency and language for each user.
User Groups: Show different content or pricing to different user groups, like wholesale vs. retail customers, without them needing to log in.
A/B Testing: Serve different versions of a page to different users as part of an A/B test and cache both versions.
Personalisation: Cache pages with personalised content, like recently viewed items or location-based offers.

Enterprise or Essential?

Many major CDN providers restrict this feature to their expensive enterprise plans, putting it out of reach for many businesses. At Peakhour, we see it as an essential feature for modern dynamic websites. That's why we make it available on all our plans. It's a core part of our 'Enterprise for Everyone' philosophy.

The ability to vary the cache on a specific cookie value addresses the limitations of the Vary: Cookie header and allows for efficient caching of personalised content. It is not a luxury feature; it is an essential tool for improving performance and user experience on modern websites.

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.

Headless Commerce Security

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

At Peakhour, we spend a lot of time looking at e-commerce architecture trends. Single Page Applications (SPAs) and headless commerce keep coming up, with tools such as Nuxt.js, Strapi, Hydrogen, and Gatsby leading many builds. These tools can make frontend work faster and more flexible, but they also put more e-commerce data behind APIs that scrapers can target.

Single Page Applications (SPAs) and headless e-commerce have changed how many retailers build their storefronts. Frontend development tools like Nuxt.js and headless CMSs like Strapi are now common parts of that stack.

The trade-off is exposure. Product information is often available as JSON data, which makes it easier for scrapers to collect at scale. That raises a practical question: how do you secure data while still making it available through APIs?

Strategies for Data Protection

Data protection matters, but it is not a single control. These are the usual layers:

Rate Limiting: Controls the number of client requests to your API within a set time frame.
Bot Detection: Distinguishes between humans and bots based on behavioural patterns.
Page Load Authentication: Secures the page load through bot detection and authenticates subsequent API calls.
IP Threat Intelligence: Blocks suspicious IP addresses from accessing your API.
GeoIP Filtering: Regulates requests based on geographical origin.

As bots change, those controls need to change as well.

Facing the Challenge of Headless Scraping

Headless scraping uses browsers without a user interface to imitate normal browsing. It is difficult to detect, but network fingerprinting can help.

Network fingerprinting examines network features like Transport Layer Security (TLS) settings and HTTP/2 (H2) parameters. By analysing these, companies can detect and block bots, adding another security layer.

Client-side Security in SPAs

In SPAs, where much of the processing happens in the user's browser, the security concerns shift:

Data Exposure: Protecting sensitive data from leakage or manipulation is critical.
Injection Attacks: SPAs must guard against attacks like Cross-Site Scripting (XSS).
Authentication and Session Management: Properly handled, these prevent unauthorised access.
Insecure Direct Object References (IDORs): Proper authorisation stops attackers from accessing others' data.

Risks in JavaScript Packages

SPAs usually depend on JavaScript libraries and packages. They are useful, but they also add supply chain risk. Using only essential packages, keeping them updated, and sourcing them from trusted providers reduces that risk. Supply chain audit tools can help automate the work:

Security audits need to be frequent because vulnerabilities can appear quickly. Tools like npm's npm audit or GitHub's Dependabot, along with regular penetration testing, can help uncover potential weaknesses.

Final Thoughts

The move toward SPAs and headless commerce is a trade-off between development flexibility and security exposure. These architectures can improve user experience and speed up delivery, but they also introduce new security issues.

Client-side security in SPAs needs deliberate attention. Data exposure, injection attacks, and insecure direct object references all need to be managed, and the convenience of JavaScript libraries brings its own vulnerabilities.

Peakhour addresses these problems with rate limiting that manages request traffic and helps prevent attacks without harming customer experience. Our Web Application Firewall (WAF) examines all payload data, adding another layer of protection.

Frequent security audits still matter. They help e-commerce managers keep SPAs and headless commerce operations secure without giving up the efficiency these architectures can provide.

Consistent Hash with Bounded Loads

2023-05-15T13:00:00+10:00

A consistent hash with load bounds extends the basic consistent hashing technique. Standard consistent hashing distributes keys across servers in a way that minimises rehashing when servers are added or removed, but it does not guarantee a perfectly even load distribution. Random hash collisions can leave some servers responsible for significantly more keys than others, creating an imbalance in the load distribution.

Consistent hashing with bounded loads, or bounded-load hashing, addresses this issue. It keeps the load (i.e., the number of keys assigned) on any given server within a factor of the average load across all servers.

The approach still uses a hash ring, but with an additional constraint that no server can exceed a certain load limit. When a key is hashed and the corresponding server in the hash ring is already at its load limit, the key is assigned to the next server in the hash ring that isn't at its load limit. This process is repeated until all keys have been assigned.

Here's a rough pseudocode example:

# Function to add a key with bounded loads
def add_key_bounded(key):
    position = hash_function(key)

    # Find the server for this key
    for i in range(position, position+1000):
        i = i % 1000  # To loop back to the beginning of the ring
        if hash_ring[i] is not None and server_loads[hash_ring[i]] < LOAD_LIMIT:
            server_loads[hash_ring[i]] += 1  # Increment the server's load
            return hash_ring[i]  # Return the server that should handle this key

In this example, server_loads is a dictionary that tracks how many keys each server is responsible for, and LOAD_LIMIT is the maximum number of keys any server is allowed to handle.

By bounding the load on each server, this approach can produce a more balanced distribution of keys across servers. However, it's worth noting that this algorithm can result in keys being assigned to servers that are not their nearest neighbours in the hash ring, which can increase latency in some cases. As with any algorithm, there's a trade-off between load balancing and other factors such as latency and computational overhead.

The Google Cloud team, in collaboration with visiting researcher Mikkel Thorup from the University of Copenhagen, devised an efficient allocation algorithm to improve load balancing in large-scale web services such as content hosting. The results of their research were detailed in a paper titled “Consistent Hashing with Bounded Loads” that was published in August 2016.

Load balancing in large-scale web services means distributing client requests evenly across multiple servers to prevent any individual server from becoming overloaded. An ideal load-balancing system distributes the load uniformly and minimises the changes to the system when servers or clients are added or removed. This consistency matters in dynamic environments where servers and clients can change over time.

Traditional consistent hashing techniques, although effective for load balancing in dynamic environments, can still lead to sub-optimal load distribution across servers in certain scenarios. As both servers and clients can be added or removed frequently, the load balancing algorithm needs to stay dynamic and adaptive, maintaining an evenly distributed load while minimising the number of client reassignments whenever a change occurs.

Google's algorithm addresses these challenges. To explain their method, they use an analogy of servers as bins and clients as balls. The goal is for all bins (servers) to have a load (clients) roughly equal to the average density, with a small tolerance factor, ε. The algorithm is designed to ensure that every bin has a capacity within the range of the average load times (1+ε), which helps achieve both uniformity and consistency in client-server allocations.

The algorithm employs two separate hash functions to assign positions to balls (clients) and bins (servers) on a circular continuum. The balls are then allocated in a specific order (say, based on their ID), with each ball being assigned to the first bin it encounters with spare capacity as it moves clockwise on the circle.

The algorithm recomputes the allocation whenever an update occurs (i.e., the addition or removal of a client or server) to maintain the uniform distribution of load. The paper proves that every ball removal or insertion in the system results in O(1/ε²) movements of other balls. Importantly, this upper bound is independent of the total number of balls or bins in the system, which means the algorithm scales well with increasing size.

The algorithm creates a trade-off between uniformity and consistency. A smaller ε value provides better uniformity but compromises consistency, while a larger ε value improves consistency but reduces uniformity. The algorithm performs well even in worst-case scenarios, making it ideal for dynamic, large-scale environments like content hosting services.

Google's algorithm has been used in production. Andrew Rodland from Vimeo implemented it in HAProxy, a popular open-source software package, for their load balancing project, resulting in a substantial decrease in cache bandwidth by almost a factor of 8. This eliminated a significant scaling bottleneck, showing the algorithm's practical effectiveness.

Overall, the work of the Google Cloud team and Mikkel Thorup is a useful contribution to load balancing. By addressing the challenges of uniformity and consistency in dynamic environments, their algorithm provides a robust solution for managing large-scale web services efficiently. The team's research and its open-source availability give the broader community a practical implementation path.

Multi-Origin Load Balancing

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

Websites and applications with global audiences often run into a problem that a standard CDN cannot always hide: not every request can be served from cache. Traditional Content Delivery Networks (CDNs) reduce latency by distributing content across multiple points of presence (POPs) around the world. But when content has to be fetched from a distant origin server, for example dynamic content that cannot be cached, users still wait on that round trip. This post explains the problem multi-origin load balancing solves and how Peakhour handles it.

Understanding the Problem

Web content usually starts from a single server, called the origin server. As a website's audience grows, that server takes more traffic, which can slow response times. CDNs reduce the pressure by caching and delivering content from servers distributed across multiple geographic locations. When the content is already cached, this reduces origin load and lowers latency for users accessing the content.

However, traditional CDNs still have limits when serving global audiences. If a user requests content that is not cached in the CDN, the request has to go back to the origin server. If that origin is far away from the user, latency increases and pages take longer to load.

Multi-origin load balancing addresses that remaining gap in CDN performance and further reduces latency.

Introducing Multi-Origin Load Balancing

Traditional load balancing distributes traffic evenly across two or more servers that are physically hosted in the same location.

Multi-origin load balancing extends that approach across origin servers in different geographical locations. The Peakhour EDGE can select the closest origin server to a user, or choose a different origin based on criteria such as device type, user preferences, or URL. For requests not stored in the CDN, this reduces the time spent crossing long network paths.

Real-Time Performance Monitoring: Peakhour continuously monitors its global network of servers in real time. This allows the system to detect potential issues or bottlenecks and adjust routing. If one origin server experiences high traffic or goes offline, Peakhour can reroute user requests to the next best server to keep the site responsive.

Adaptive Content Caching: Peakhour Edge uses adaptive content caching strategies, which dynamically cache both static and dynamic content based on user behaviour and request patterns. Frequently requested dynamic elements, such as personalised user data or search results, are cached on edge servers, reducing the need to fetch content from the origin servers and further minimising latency.

Load Balancing and Failover: Peakhour's multi-origin load balancing is complemented by load balancing and failover mechanisms. These features keep the system resilient and responsive during periods of high traffic or server outages. By distributing user requests evenly across origin servers and automatically redirecting traffic when a server fails, Peakhour maintains a stable and reliable content delivery experience for users worldwide.

Conclusion

Multi-origin load balancing addresses the limitations of traditional CDNs by optimising content delivery for a global audience. Peakhour Edge reduces latency and improves the experience for users who would otherwise wait on a distant origin server.

As web content and applications grow in complexity and reach, origin placement and routing become part of performance planning. Peakhour implements multi-origin load balancing with clients' origin servers so requests can be sent to the most suitable origin instead of treating a single distant server as the only fallback.

Introducing Automatic Cache Tags in the Updated Peakhour WordPress Plugin

2023-03-20T13:00:00+11:00

We have updated the Peakhour WordPress plugin with automatic cache tag generation. The update is designed to help keep cached WordPress content accurate without forcing full cache clears for routine content changes. We have also checked compatibility with the latest versions of WordPress and PHP.

What are Cache Tags?

Cache tags are labels that CDNs such as Peakhour use to manage cached content more precisely. Instead of clearing the whole cache when one page changes, you can purge only the content associated with the relevant tag. Visitors get the updated content, while the rest of the site can continue to be served from cache.

A Cache Tag Example

Suppose you run a site with a home page, product pages, and blog articles. Without cache tags, updating one product page or article may require clearing the entire cache. With cache tags, each part of the site can use its own tag, such as "homepage," "product," and "blog." When you update content, you only need to purge the cache for the affected tag. That means less unnecessary cache invalidation and a faster site for visitors.

Automatic Cache Tags in the Peakhour WordPress Plugin

The updated Peakhour WordPress plugin generates cache tags automatically for your site's content. When you update content in the WordPress admin, the plugin sends the relevant purge requests to Peakhour. The result is more targeted cache clearing without extra manual work.

How to Get Started with Automatic Cache Tags

Update to the latest version of the Peakhour WordPress plugin.
Follow the instructions to configure cache tags in the Peakhour admin.
Flush your cache.

After that, the plugin generates cache tags and sends purge requests to Peakhour whenever you update content in the WordPress admin.

Final Thoughts

Automatic cache tags in the Peakhour WordPress plugin make cache purging more precise. They help improve performance, give you more flexibility, and reduce unnecessary cache clears. Try the updated plugin and let us know how it works for you.

Layer 7 DDoS Protection

2023-02-07T13:00:00+11:00

In previous blog posts we've covered the benefits that full page caching has on page load performance. We also covered how caching pages lowers origin server utilisation, so the site can handle more customers. A lesser-known side benefit is protection against Layer 7 denial of service (DoS) attacks.

What is a Denial of Service attack?

The goal of a DoS attack is to make a network resource, such as a website or networked service, unavailable to users by overwhelming it with excessive traffic or requests. DoS attacks can be launched from a single source or from multiple sources (known as a distributed denial of service, or DDoS attack).

Typically, an attacker floods the web server with HTTP or API requests to try to overwhelm it. An attacker might also launch a 'slow attack', especially if they find a weak point in the application that consumes a lot of server resources for a single request. One example is repeatedly using a site search function. By slowing down the rate at which requests are sent, the attacker can bypass common rate-limiting and traffic-shaping mechanisms that are designed to block high-volume traffic spikes.

DoS conditions can also be inadvertent. A CMS like Magento or WordPress on an underpowered server can be overwhelmed, or slowed to a crawl, by so-called 'grey' bots. Examples include Semrush, Ahrefs, dotbot, and MJ12Bot. These spiders can crawl a site aggressively enough to bring it to its knees. Even Bing or Google can negatively impact a site.

What is Layer 7?

In networking parlance, Layer 7 refers to the actual application running on a web server. It is part of the OSI (Open Systems Interconnection) model used to describe the various functions in transmitting data over a network. The model is as follows:

Layer 1 -> Physical Layer, responsible for transmitting raw bits of data, e.g., a wire or wireless link
Layer 2 -> Data Link, responsible for transmitting data frames between network devices and detecting transmission errors.
Layer 3 -> Network Layer, responsible for routing data packets between networks and determining the best path for transmission.
Layer 4 -> Transport Layer, responsible for end-to-end communication between applications, providing reliable data transmission and flow control.
Layer 5 -> Session Layer, responsible for establishing, maintaining, and terminating communication sessions between applications.
Layer 6 -> Presentation Layer, responsible for formatting data to be presented to the application layer and for converting data from the application layer into a standardised format for transmission.
Layer 7 -> Application Layer, responsible for providing services to the user, such as file transfer, email, and web access.

How Full Page Caching helps

Full page caching helps by reducing the number of dynamic requests to the server. Caching the entire page allows the server to serve pre-generated content to visitors, rather than generating it dynamically each time a page is requested. This reduces the server's processing load and helps prevent excessive requests from overloading the server or making it unavailable.

A real world example

As part of a series of Peakhour recommendations to 'harden' its website against layer 7 attacks, a Peakhour client (a government site) applied limited full page caching with a time to live of 10 minutes. This means that Peakhour will serve a page from its Edge cache for 10 minutes before hitting the origin again for a new version.

Not long after implementation, that change was tested: a DDoS originating from hundreds of IPs across multiple countries hammered a set of 5 pages. The attack was spread over several days with bursts of activity lasting about 15 minutes. With the first hit, the page was cached and every subsequent hit was served from our high-performance Edge cache. No slowdown was observed and the attackers gave up.

Real attack on a Peakhour client; the spikes formed in 15 minute bursts.

Real page load times measured in the client browser

But my site is dynamic...

Many websites have a small dynamic component on the page. For ecommerce sites this might be the mini cart in the top right showing the number of items in the cart, or it might be some personalisation for a user. Often these dynamic parts of the page can be rendered in the browser using Ajax or local storage, rather than rendered on the server. By moving the dynamic components to the browser, the full page becomes cacheable. Another option is to use Edge Side Includes (ESI), which enables the majority of the page to be cached in the CDN while the dynamic parts are fetched separately before serving the full page to the user.

Peakhour can help move dynamic page components from the server to the browser and cache more at the edge. We also have a range of CMS plugins that do just that. Contact us if you want some help.

Final Thoughts

Layer 7 DoS attacks have become more common than traditional DoS attacks, as they typically require far fewer resources from the attacker. Reducing dynamic requests to the origin using full page caching is a useful but underappreciated way to mitigate them. If you're concerned about website security, resilience, and performance, Peakhour helps you cache more so you can protect, accelerate, and scale your website.

Automatic Image Optimisation

2022-12-06T13:00:00+11:00

Since releasing our automatic image optimisation capability in 2019, Peakhour optimises more than 35 million images each month. On average, clients reduce page download time by 35% and image sizes by 91%.

Automatic image optimisation offers a number of benefits over manual optimisation:

Image formats are dynamically chosen based on the content of the image.
Files are optimised based on client capabilities.
Designer time is saved by offloading image optimisation work.
Page load times can be reduced across an entire website.

What is Image Optimisation?

Image optimisation means delivering high quality images in the right format and resolution for the device viewing them. The aim is to minimise file size without compromising visual quality. Smaller image files generally load faster in a visitor's browser, which can improve website speed, reduce traffic and support higher page visits and conversions.

Why dynamically choose the image format?

Using a one size fits all optimisation process does not account for the different types of images used across a typical website.

Website images can include:

Photographs, such as product images, demonstration photos and title photos.
Logos, which are typically text and can include animation.
Illustrations that incorporate custom graphics to support the quick perception of information.
3D graphics from computer renders including buildings, interior and exterior designs and products.
Combinations of the above!

Any optimisation process needs to account for the end user's device type, supported file formats, resolution and the content of the image. For example, a photograph with text needs different optimisation parameters so the text remains crisp, while images with large areas of colour may need different formats to avoid colours being degraded by lossy compression.

Fine developer control

With the image optimisation API, your developers can enable reactive images by resizing images on the edge. Peakhour serves and caches these optimisations, reducing origin requests and traffic, cutting costs and making image changes faster to ship. You no longer need to wait for a designer to resize, crop or re-orient an image for a page.

How does image optimisation effect web application performance

Large portions of a website are typically built from images. Large images loading over a 4G network in a train can delay image rendering and create a poor user experience. Layout shifts can occur as the browser attempts to render the page, and the user's perceived page load time will be affected.

You can see the benefit of automatic image optimisation with our free tool. It will analyse any website, calculate its optimisation potential and let you download the optimised images.

See how it can help in a real life example below

security.png

Original

2362 x 1266px

PNG

190.2 kb

Optimised

605 x 324px

png

10.8 kb

jpeg

15.4 kb

[webp](/products/image-optimisation-and-transformation/)

10.7 kb

avif

8.2 kb

Benefits of Peakhour Automatic Image Optimisation

Peakhour image optimisation is integrated into your website so you can reduce traffic, speed up page loads and remove manual image preparation from the design workflow.

Transforming images on the Peakhour edge enables agility and offloads origin work.
User experience is improved through faster-loading pages, without a separate workflow for image optimisation.
Take advantage of new image formats, as supported by end users' browsers, to improve the page load experience.

Final Thoughts

Peakhour image optimisation runs on Peakhour Edge. Images are optimised as they pass through the Peakhour network, and optimised versions are cached for reuse. Peakhour image optimisation also works with Origin Shield, with the original and transformed images cached appropriately. This reduces origin hits and bandwidth while speeding up image delivery.

Drupal full page caching module

2022-10-05T13:00:00+11:00

Drupal is an open source content management system (CMS) widely used by Australian government websites. For example, GovCMS is a customised version of Drupal. Peakhour now provides a purge module for Drupal 8/9, extending our existing Drupal support.

The Peakhour Purge module extends the Drupal Purge module. The Purge module provides a standardised way of integrating third party CDNs, like Peakhour, with Drupal's native full page caching support. Drupal's native support is suitable for small websites, but has a number of drawbacks. These drawbacks include:

Doesn't support the Vary header.
Is served by PHP, so it doesn't scale well.
Runs on the same server as Drupal, so geographic latency is still an issue.

Peakhour's edge cache and delivery layer removes these issues before requests reach origin, and also adds image/content optimisation and website security.

Default Caching

Since version 8, Drupal has supported cache tags to provide efficient, targeted invalidation of content for anonymous browser sessions. In this context, anonymous means a user that does not have a Drupal Session cookie. Peakhour supports cache tags for all sites, a feature some competitors reserve for 'Enterprise' plans.

Cache tags are great, but another default setting is not. That setting is to add a:

Vary: Cookie

Header to the page response to make sure that logged-in users don't get cached pages. The Vary header informs a cache that different content may be served from origin based on the value in the Cookie header sent by the browser.

This is fine if you are using Drupal with no third party javascript libraries. If you do use third party libraries, it can render page caching close to useless. For example, drupal.org itself uses perimeterx for bot detection, which results in a unique session cookie being set on the very first request.

The first request to drupal.org results in a unique cookie being set by perimiterx

If you use Google analytics, Facebook, or any of a wide array of popular third party libraries, the same thing can happen.

This means only the very first request from the user could be served from a general page cache. Hit rates would be virtually zero.

Fix the Vary issue with Skip Cache on Cookie

Peakhour gives you a way to work around this. The first step is to disable the Vary: Cookie header. Then, to make sure any user with a Drupal Session bypasses the cache, use Peakhour's Skip Cache on Cookie feature. As soon as Drupal sets a session cookie, eg when someone logs in, Peakhour will pass requests through to the origin. Full instructions on how to do this are provided on our drupal module documentation

eCommerce Drupal sites

If you are running an ecommerce store, or some other type of site that might serve customised information on a page, for example a mini cart with cart count/information, then you will have to do custom development to continue caching pages. A workaround for a mini cart would be to make it load via Ajax or to use local browser storage, and Peakhour assists in making that happen.

Future features

Hopefully in the future Drupal will support setting its own cookie for varying the cache, in a similar manner to Magento 2. eg X-Drupal-Vary, this would allow Peakhour to store multiple versions of a page to serve to different users. For example, a user in Germany might get a version of a page in German with German currency.

Prestashop 1.6/1.7 full page caching plugin released!

2022-08-04T13:00:00+10:00

Prestashop is a popular open source eCommerce platform written in PHP. We're releasing a Prestashop module that enables full page caching through Peakhour. Pages can stay cached at the Peakhour edge for longer, and the plugin refreshes them when the underlying content changes in Prestashop.

Full Page Caching reduces load times by removing the time it takes for a CMS to generate a dynamic page. That is typically around half a second for a quick page, and 3-5 seconds for a slow one. Here is a cache miss and hit from our client fatburnersonly.com.au:

A typical cache miss on a category page. The origin has to generate the page, taking 2.49 seconds

A cache hit: only 35.7 milliseconds to deliver to the client from our edge

Nearly 2.5 seconds removed from Time to First Byte and Largest Contentful Paint. That's without changing the site itself.

Tag Based Flushing

Like all our recent plugins, the Prestashop plugin adds a header with tag metadata for each cacheable page. This header is called X-Prestashop-Tag and contains the IDs of the relevant entities on the page, eg products, categories, brands, pages, etc. This metadata is stored alongside the cached page. When an entity changes in the Prestashop admin, eg a product price is updated, the plugin issues a flush-by-tag request to Peakhour. Peakhour finds the pages with the associated tag and invalidates them in the cache. The next request for the page passes through to origin and is then re-cached.

Headers returned by the [caching plugin](/blog/opencart/opencart-3-caching-plugin/).

Custom TTL

TTL (Time to live) is the time a resource stays in cache before the cache checks for a new version. You can control this within the plugin. The plugin then sets the peakhour-cdn-cache-control header, part of the new cdn-cache-control specification, so only Peakhour responds to the cache directive.

Ajax Mini Cart

Mini carts are dynamic sections of eCommerce websites, and they often stop pages from being cacheable. The Peakhour plugin loads them via Ajax so as many pages as possible remain cacheable.

The mini cart is in the top right; it is usually returned as part of the generated page.

Cache varying

The same page can show different information depending on factors such as whether a user is logged in, or whether a multicurrency store changes currency. The Peakhour Prestashop plugin handles this by changing a cookie value when those factors change, creating separate cache regions for the different possibilities.

The Results

The Peakhour Prestashop plugin can improve store performance measurably. Our client fatburnersonly.com.au improved their 'good' web vitals scores by 20% in the two months they've been using Peakhour.

Full page caching was enabled halfway through May. Note that a significant number of pages, eg checkout and admin, cannot be cached and are included in these stats

Grabbing the plugin

If you have a slow Prestashop store, see our plugin page or contact us for more information.

CDN Cache Keys

2022-05-16T13:00:00+10:00

Content Delivery Networks (CDNs) are common on business websites. CDNs speed up websites by storing website content and assets in caches on servers spread around the world. These caches are typically key/value stores. For example, let's say we are requesting an image found at:

https://www.example.com/someimage.jpg

Depending on how the CDN works internally, it may use /someimage.jpg (the key) to retrieve the image (the value) from its cache. Most CDNs are fairly rigid in what they use as keys, complicated to configure (eg requiring programming skills), or charge more for flexibility.

The Peakhour.io CDN cache keeps configuration flexible while still supporting fine-grained control of caching behaviour for your application.

The Peakhour.IO cache key consists of a primary key, sub key, and secondary key. Both the primary and secondary key must match to constitute a cache hit.

Primary key

The primary key is the key from the client request that uniquely identifies a resource. It consists of the scheme, host, path and query string from the request. Within our cache, the primary key may be augmented from other elements of the request, such as the presence of a particular header, or a header value such as a cookie value. At Peakhour.IO, we call these augmented keys cache subkey vars.

The following options can further manipulate the primary key by specifying how the query string is handled. These options include ignore query string (useful for defeating cache-busting techniques) or stripping certain tags (commonly UTM tags).

Secondary key

The secondary key describes parts of the request message that influenced the content of the response from the origin. This information is stored in the secondary key and the following headers are used:

Vary
Content-Encoding
User-Agent: (browser/mobile)
Accept-Language
Variant-06

Servers are commonly misconfigured and can send back headers that don't match the behaviour of the content. For example, it is very common for a server to send back a Vary header with Vary: user-agent. When you check the behaviour by sending different user agents, though, the content doesn't actually change. This can cause unnecessary cache fragmentation and lower hit rates. Peakhour allows you to override/ignore origin behaviour to correct this.

If you prefer a visual view, the diagram below shows all the elements of a request/response that could make up a cache key.

For more flexibility, Peakhour.io can use specific Cookie values in the secondary key. This is useful for Content Management Systems like Magento, which set a special cookie, X-Magento-Vary, to enable special caching behaviour that wouldn't normally be achievable; for example, whether the user is logged in, is part of a special group, or has chosen a different currency.

How can I see my keys?

Cache keys are generated on the fly based on the client's request and the origin's response. To see a cache key, enable Debug headers in the Peakhour.IO dashboard. As an example, for the given request/response pair:

GET / HTTP/1.1
Accept-Encoding: gzip, deflate, br

HTTP/1.1 200
Vary: accept-encoding
content-encoding: br

Peakhour.IO would generate the following cache-status header:

cache-status: peakhour.io; fwd=uri-miss; key="https://example.com/what-is-new.html"; secondary-key="encoding::br"; stored; ttl=31536000

Here, the key is the scheme://host/path and the secondary-key is the encoding served by the origin.

What's in it for me?

By understanding cache keys and how they are constructed, a web application can tailor its responses to better utilise a cache. The configuration options give you direct control for fine-tuning cache-key handling, improving user experience and cache hit rates.

Request collapsing

2022-05-16T11:00:00+10:00

Request collapsing protects busy origin servers that serve changing content. On a high traffic site, a cache miss after content expires can amplify one expired resource into many simultaneous origin requests. This behaviour is commonly called a cache stampede or dog-piling.

When request collapsing is enabled, only a single request is sent to an origin server for a given resource, then the resulting body is used to satisfy pending requests.

This can stop a popular cached resource from causing a flood of requests to an origin server when it expires. On high traffic sites, enabling the feature for the right resources can smooth request volume and traffic to origin servers.

How it works

Request collapsing is implemented internally using cache keys and queues. Cache keys are used as keys to a map, with client requests tracked using a queue. Secondary response keys are then used to match waiting client requests to origin responses. Matching requests can then be fulfilled using the same response.

Failed requests are retried in the same manner.

If a response to an active request is marked as private with Cache-Control: private or Set-Cookie, then all queued and future matching requests will go directly to the origin without trying to match them.

This implementation allows Peakhour to serialise requests to an origin, so it's important to enable the feature only on resources that you know will be cacheable, either through cache-control headers or Peakhour configuration.

How do you know its working?

Request collapsing can be verified with Debug enabled and the cache-status header in the response. A collapsed request looks like the example below, with 'collapsed' at the end.

cache-status: peakhour.io; fwd=uri-miss; key="https://website.com/home-eco.jpg"; ttl=86400; collapsed

How its used in practice?

Image optimisation

Peakhour.IO uses request collapsing internally for image transforms. The feature ensures we only transform a single image when a resource expires on the edge, reducing latency sensitive image transformation work, client transform costs and avoidable delays for end users.

Dynamic page caching

Request collapsing is a good fit when enabling caching of expensive dynamically written pages. Peakhour.IO can cache server heavy WordPress, Magento, PrestaShop, Drupal and other platforms via our caching plugin. The plugin keeps the CDN in sync by notifying us when content changes.

Content still needs to change during busy periods such as sales or item purchases. During these periods servers can be overwhelmed when pages incur a cache miss. Request collapsing can help smooth out this traffic and maintain response times for users.

Opencart 3 Full Page Caching Plugin Released

2022-03-25T13:00:00+11:00

Peakhour's Opencart plugin includes features that are usually reserved for enterprise plans with other providers. It follows our 'Enterprise for Everyone' approach in a practical way:

Tag-Based Flushing

Peakhour's plugin records metadata for each Opencart page in the cache. When you update a product or category, only the relevant pages are refreshed. That keeps cache flushing targeted instead of clearing more content than necessary.

Headers returned by caching plugin.

Custom TTL

Control how long a resource stays in the cache before it checks for a new version. This gives you a direct way to manage cache freshness.

Ajax Mini Cart and Wishlist

Dynamic sections like mini carts and wishlists usually prevent caching. The plugin loads these sections via Ajax, which makes more pages cacheable.

Cache Vary

The plugin adapts to different user states, currencies, and languages. It changes a cookie value to create separate cache regions for these variables.

Peakhour vs. LiteSpeed and Varnish Cache

LiteSpeed and Varnish Cache are good options, but Peakhour offers a more flexible and efficient caching solution for Opencart. The plugin makes Opencart as cache-friendly as Magento 2 or Drupal 8, if not more so.

The Results Speak for Themselves

Our client saw a clear improvement in their web vitals scores and website scalability. Full page caching was enabled in October, with the gains shown below.

Full page caching was enabled in October. Note a significant amount of pages, eg checkout, admin etc cannot be cached which affects these stats

For more information, visit our plugin page or contact us.

Cdn-Cache-Control

2022-02-28T13:00:00+11:00

Caching headers are easy to get wrong. Public resources may be cached in one layer, while the server configuration prevents an otherwise cacheable resource from being stored where you expect.

Controlling caching without a service like Peakhour usually means working directly with Cache-Control headers. This header has a wide range of fields and directives. Each one tells downstream clients (e.g., proxies, shared caches, and end browsers) how to handle caching for a particular resource.

Getting this right can be complicated, and it can become brittle when web server configuration also affects the response.

Enter CDN-Cache-Control

CDN-Cache-Control is a recently proposed header specified in https://datatracker.ietf.org/doc/html/draft-cdn-control-header-01

The draft RFC states:

This specification defines a convention for HTTP response header
fields that allow directives controlling caching to be targeted at
specific caches or classes of caches.  It also defines one such
header field, targeted at [Content Delivery Network](/learning/cdn/) (CDN) caches.

What does this mean in practice? Imagine a Magento application where pages should be cacheable by a shared cache but not by a browser. A Cache-Control header could look like:

Cache-Control: max-age=0, s-max-age=600

This tells browser caches not to reuse the response, while shared caches may cache it for 600 seconds.

What if the application does not want every shared cache to store the resource, because the application already sends purges to the cache when content changes?

Cache-Control does not give you that separation. The header above enables any shared cache to store the resource for the specified time. With CDN-Cache-Control, the application could instead send:

Cache-Control: max-age=0, s-max-age=60
CDN-Cache-Control: max-age=3600

This tells the browser not to cache the page, allows a shared cache to keep the page for 60s, and allows the CDN to keep it for one hour.

Targeted CDN-Cache-Control

What if you need to target a specific CDN only? Use the provider's targeted CDN-Cache-Control header.

For example, Peakhour-CDN-Cache-Control instructs Peakhour only to cache the resource. Other CDNs in the request path will not honour this header.

Header format

Examples

The following header fields instruct a CDN cache to consider the response fresh for 600 seconds, other shared caches for 120 seconds, and any remaining caches for 60 seconds:

Cache-Control: max-age=60, s-maxage=120
CDN-Cache-Control: max-age=600

These header fields instruct a CDN cache to consider the response fresh for 600 seconds, while all other caches are prevented from storing it:

Cache-Control: no-store
CDN-Cache-Control: max-age=600

Because CDN-Cache-Control is not present, this header field prevent all caches from storing the response:

Cache-Control: no-store

Whereas these prevent all caches except CDN caches from storing the response:

Cache-Control: no-store
CDN-Cache-Control: none

(note that 'none' is not a registered cache directive; it is used here to avoid sending a header field with an empty value, because such a header might not be preserved in all cases).

Cache-Status

2022-02-25T13:00:00+11:00

Diagnosing CDN caching can be complex, with multiple cache layers, Origin Shielding, and local caching. Understanding how these layers interact can mean spending weeks working through RFCs for the finer details of ETag, Cache-Control, and Last-Modified headers - before you even account for advanced controls that override them.

When you have a problem, or are trying to optimise caching, the first thing you need is visibility into how a request was handled.

This is where the new Cache-Status header helps. The new draft RFC, RFC draft-ietf-httpbis-cache-header-08, aims to:

  aide debugging by standardising the format of various non-standard debug headers
  used by major CDN providers. The semantics of these headers are often unclear and vary
  between implementations.

The draft RFC proposes a new header, Cache-Status, with a uniform format for showing how multiple caching providers interact and handle a request. The Cache-Status header forms a list. Each member of the list represents a cache that has handled the request, and the last member belongs to the cache that most recently served the user. The header is only applicable to responses directly generated by an origin server. Each member can add a parameter indicating how it handled the request.

A Cache-Status header looks like this:

  Cache-Status: OriginCache; hit; ttl=1100, "CDN Company Here"; fwd=uri-miss;

It is formatted and labelled, with each cache in the line separated in list format by a ','.

The format of the Cache-Status header is a list comprising of the following possible parameters:

hit = boolean
fwd = (bypass, method, uri-miss, vary-miss, request, stale, partial)
fwd-status = integer
ttl = integer
stored = boolean
collapsed = boolean
key = string
detail = token / string

What the parameters mean

Hit

The hit parameter signifies that a request was satisfied by the cache. It is a boolean parameter meaning that its presence indicates a cache hit.

For example:

  Cache-Status: Peakhour.IO; hit

Fwd

The Fwd parameter indicates when a response was forwarded to an origin server - and why. The Fwd parameter contains one of the following arguments:

bypass - The cache was configured to not handle this request
method - The request method's semantics require the request to be forwarded
uri-miss - The cache did not contain any responses that matched the request URI
vary-miss - The cache contained a response that matched the request URI, but could not select a response based upon this request's headers and stored Vary headers.
miss - The cache did not contain any responses that could be used to satisfy this request (to be used when an implementation cannot distinguish between uri-miss and vary-miss)
request - The cache was able to select a fresh response for the request, but the request's semantics (e.g., Cache-Control request directives) did not allow its use
stale - The cache was able to select a response for the request, but it was stale
partial - The cache was able to select a partial response for the request, but it did not contain all of the requested ranges (or the request was for the complete response)

For example:

  Cache-Status: Peakhour.IO; fwd=uri-miss

Fwd-status

The fwd-status parameter indicates the status code the next hop returned in response to the request. It is only meaningful when "fwd" is present. For example, a complete miss would look like fwd=uri-miss and the HTTP status code of the downstream response would be supplied in the fwd-status:

The following example shows that the cache did not satisfy the request and that the downstream server indicated an HTTP 304 response - HTTP Not Modified.

  Cache-Status: Peakhour.IO; fwd=uri-miss; fwd-status=304

ttl

Each cache item is associated with a lifetime, referred to as the Time To Live (TTL). A TTL is in seconds and indicates the remaining freshness of the resource. This value is calculated by the cache.

For example, a cache hit showing that the resource has a freshness of 376 seconds.

  Cache-Status: ExampleCache; hit; ttl=376

Another example shows a cache hit with negative freshness - a stale resource.

  Cache-Status: ExampleCache; hit; ttl=-412

stored

Indicates whether the received response was stored by the cache. This example shows a cache miss and the cache storing the response for the next hit.

  Cache-Status: ExampleCache; fwd=uri-miss; stored;

collapsed

Indicates whether the received response was collapsed with another request.

key

The key is the lookup index into a cache. Cache keys convey a representation of how the cache will look up the resource used for the response. The cache key is implementation-specific.

This example shows a cache hit, the cache key and secondary key, and the remaining TTL of the resource.

  cache-status: peakhour.io; hit; key="https://example.com/calendar.css"; secondary-key="encoding::gzip"; ttl=30674859

detail

Allows additional implementation-specific information not captured by other parameters.

Multiple layers of caching

The header allows multiple layers of caching. For example, a global CDN may sit in front of a local varnish server. Each cache appends its cache-status to the header, so the last item is the closest cache to the actual application and the first item is the closest cache to the accessing user.

  Cache-Status: OriginCache; hit; ttl=1100, "CDN Company Here"; hit; ttl=545

Security

There are security implications to consider with this header. Making it public gives an attacker insight into how the cache is configured, which may help them bypass a cache entirely and access an origin server directly. Cache header security is provider-specific, but could involve enabling it only when required, restricting access to specific IP addresses, or requiring a custom request header to trigger the cache-status header.

Peakhour.IO regularly sees automated scans sending other providers' headers to trigger a cache-status header response.

Conclusion

The Cache-Status header gives clear insight into how cache layers interact on a website. It provides a standardised format for showing how a cache handled a request and allows multiple caches to report their part of the request path.

Peakhour fully supports this new header, and it can be enabled/disabled and secured in the dashboard.

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.

The CDN is Dead, Long Live the CDN!

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

It has long been conventional wisdom that if your website uses a third-party library, such as jQuery or Bootstrap, you should load it from the library's high-performance CDN. For example, jQuery has

code.jquery.com

from which you can include any version of jQuery on your website, e.g.:

<script src="https://code.jquery.com/jquery-3.3.1.min.js"
          integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8="
          crossorigin="anonymous"></script>

This was meant to give you two performance benefits: the browser could load jQuery from a global CDN, AND if another site the visitor had already opened included the same jQuery file in the same way, the file might already be in their browser cache. In that case the browser could reuse the cached copy and the page would load faster.

In practice, website visitors rarely see much benefit. The browser still has to open a separate connection to the third-party CDN, which can cancel out any latency advantage the CDN provides. There are also so many versions of major libraries in use that the chance of two websites using the same version, AND both loading it from the CDN in the same way, is small.

Cache Partitioning in Chrome and Firefox

Until recently, Chrome and Firefox used a shared browser cache for all websites that a user visited. This means that if you visited a website and it loaded this resource:

https://www.somesite.com/foo.js

and you then visited a second website that included the same resource, the resource would be loaded from the shared cache rather than being downloaded from the internet a second time. Cookies set by these resources would also be shared.

As of Firefox v85 and Chrome v86, the browser cache will be partitioned. This means that the same resource included on two sites will have to be downloaded from the internet twice and stored separately.

Why are they doing this?

The main reason is privacy. Shared browser caches have been used by unscrupulous operators to track users across different websites without consent. They do this by utilising cache side-channel attacks.

What Are Side Channel Attacks?

In computer systems, a program or algorithm can be correct and secure in itself, while its interaction with the computer still leaves information that an attacker can exploit. A useful analogy from the spy world is using a laser beam to measure the vibrations on a pane of glass, so you can hear a conversation inside a room that you otherwise could not hear.

Side-channel attacks can be ingenious, utilising techniques such as:

observing power consumption/electromagnetic radiation;
timing data moving in and out of memory;
timing how long a CPU takes to execute an instruction;
measuring sounds emitted by a hard drive.

For the browser cache, a simple attack starts with the user opening a malicious website. That website then requests resources (e.g., an image) from another site. By timing how long the browser takes to load that image, it can determine whether it was fetched from the browser cache or had to be downloaded over the internet. According to Google, this technique can be used to:

Detect if a user has visited a specific site.
Detect if an arbitrary string is in the user's search results by checking for 'no search result' images used by particular sites.
Track users across sites using the cache.

GitHub user terjanq has published a cache side channel attack that can gather all sorts of information from Google services. He states that a regular Google user could have the following information leaked:

search history
videos watched
the exact URLs visited
time frames of the activities
private book collection
books read / purchased / bookmarked / favourite / etc.
private emails
tokens / credit card numbers / phone numbers / etc.
contacts (including email addresses, names, phone numbers)
bookmarked websites
and more.

Perhaps it was simpler to implement cache partitioning in Chrome than to keep patching these vulnerabilities...

What you should do

Google estimates that the changes in browser caching will have minimal impact, as little as a 0.3% difference in FCP (First Contentful Paint). However, since there will no longer be any shared-cache benefit from hosting on a third-party CDN, you should:

Host all third-party libraries on your own domain to eliminate the need for the browser to establish a second connection.
Use a delivery layer such as Peakhour Edge, which transparently caches and serves your website assets close to users.

Conclusion

Some third-party resources really are shared across millions of websites. Google Fonts is the obvious example. Under the new cache partitioning implementations, these fonts will have to be downloaded for every site that uses them. That has a cost for site speed and data usage. It also has the side effect of improving Google's ability to track users, because each font request tells Google another site the user has visited.

Safari has been partitioning the HTTP cache since 2013, leaving Microsoft's Edge as the last major browser with global HTTP caches. However, future versions will be based on Chromium (the open-source version of Chrome) so should get cache partitioning by default.

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.

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.

Website Performance testing with WebPageTest.org

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

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

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

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

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

Running a Simple Test

To run a simple test:

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

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

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

Interpreting the results.

A,B,C's

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

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

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

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

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

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

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

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

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

Performance Metrics (The Important Stuff)

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

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

The Detail Section

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

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

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

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

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

The Waterfall View

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

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

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

The Performance Review Section

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

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

Summary

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

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.

Boost Your Website Speed with Full Page Caching

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

Full page caching is not a cosmetic optimisation. Users expect quick load times, and search engines reward fast websites with higher rankings. Full page caching supports both by storing fully rendered HTML pages, so the server does not have to rebuild the page from scratch for each visitor.

How Full Page Caching Enhances Performance and Capability

By caching full HTML pages, you create a snapshot of a page at a particular moment. When a user requests that page, the server can deliver the snapshot instead of generating the page again. This saves compute and database resources, allowing your server to handle more users simultaneously. The result is straightforward: faster load times for users and less strain on the server.

Real-World Impact

Our early adopters have reported clear improvements in website speed and server performance. One client saw a 40% reduction in server load and a 20% increase in page load speed. Those results point to a better user experience and potentially higher conversion rates.

Challenges with Magento 1 and How We Solved Them

Magento 1 presents specific challenges for full page caching, and our plugin handles them directly.

Mini Cart Issue

The mini cart needs to show real-time data, which makes it a barrier to full page caching. Our plugin uses targeted AJAX calls to fetch this data only when required, reducing unnecessary load on the server.

Form Key Problem

Magento 1 uses form keys to prevent CSRF attacks, but those keys make caching difficult. Our plugin replaces form keys with a strict referrer check, which is secure and cache-friendly.

Additional Features

Automatic Expires Headers: You do not need to manually set expiration times for your cache; our plugin does it for you.
Cache Tagging: This allows for precise cache management. When you update a product, only the relevant cached pages are flushed, keeping the process efficient.

The plugin is available for download, with the aim of improving performance and increasing server capability on Magento 1 stores.

Boost Your Website Speed with Peakhour's Full Page Caching

2019-04-02T13:00:00+11:00

Why Full Page Caching Matters

Site speed affects user experience, conversion, and server load. Slow pages can increase bounce rates and cost revenue. Full Page Caching improves response times by storing and serving static versions of dynamic pages. This reduces load on your server and gives visitors quicker page loads.

How Peakhour Optimises Your Site

Peakhour helps speed up and secure your website with a DNS change. Unlike basic caching solutions, Peakhour serves these static pages from its global ANYCast network. Your site's visitors download content from a server close to them, reducing latency and speeding up downloads.

Peakhour's Transparent Caching and Delivery

In addition to Full Page Caching, Peakhour can act as a transparent delivery and cache layer. It caches and optimises static assets like CSS, JavaScript, and images. You don't need to make any other changes to your site; a DNS change is all it takes.

Wordpress Plugin for Easy Integration

During our beta phase, many clients used early versions of our WordPress plugin. The plugin integrates with Peakhour's API to automate content flushing when you make edits in the WordPress admin panel. This simplifies publishing and allows you to set longer lifetimes for your dynamic content in our global cache.

Improved Performance Metrics

With Peakhour, sites can see faster download times, a higher cache hit rate, and reduced load on the origin server. Site owners get lower origin demand; visitors get faster pages.