Peakhour.IO - CDN

Cloudflare outage proves Plan B depends on controlling DNS

2025-11-18T21:00:00+11:00

On Tuesday, 18 November 2025, Cloudflare’s own status page marked every major service—CDN, Firewall, WARP, Workers, and the dashboard—as degraded for most of the day while engineers worked through an internal control-plane failure. The timeline moved from “Investigating” at 11:48 UTC to “Monitoring” after 14:42 UTC, and the incident wasn’t officially resolved until 19:28 UTC. During the worst of it, Cloudflare disabled WARP in London, bot scores seesawed, and customers were told to wait while remediation continued.

Waiting was the only option for many teams because their Plan B lived behind the same dashboard that was timing out. The top comment on the Hacker News thread was a set of curl commands for moving domains off Cloudflare’s proxy edge. Admins were stuck in 2FA flows trying to fetch an API token, or searching for Terraform credentials so they could toggle a proxied flag. That is not a resilience strategy.

We learned this lesson the hard way—and wrote about it after the 2021 Fastly outage in How to have a Plan B. The rule still stands: the platform you are trying to leave cannot be the only place that can change where your DNS points.

Detect: understand what’s actually broken

Incidents like Tuesday’s change shape quickly. Cloudflare’s own feed showed different failure domains every 30 minutes: bot management, dashboard auth, Access, WARP. The first mile is impartial telemetry that tells you what your users feel, not what the provider thinks. At Peakhour we stream real user monitoring, synthetic checks, and control-plane health from multiple CDNs and DNS partners. That lets us distinguish “cache errors in Hong Kong” from “global auth outage” and choose the right lever.

Decide: keep DNS authority in neutral territory

When your domain delegation lives with agnostic providers—Route 53, NS1, Azure DNS, or the enterprise registrar your legal team already approved—you can make failover decisions without pleading with a failing control plane. Peakhour doesn’t replace those vendors; we orchestrate them. We set short-but-safe TTLs, keep secondary answers staged, and continuously audit API access so we can flip traffic with one signed request. The minute you outsource DNS authority to a proxy CDN, you have given up the control that makes Plan B possible.

Divert: run the playbook in minutes, not hours

A workable Plan B has three moves:

Pre-stage alternate edges. Your secondary CDN, origin, or transit provider must be in sync with the active one—certificates, cache rules, WAF policies, everything. We keep them hot by replaying production configs across vendors.
Wire DNS automation. We integrate with multiple third-party DNS APIs at once so we can update apex A/AAAA, flattened CNAMEs, and geo/latency rules in a single workflow. Because the automation lives off the impacted platform, we can execute even while Cloudflare’s dashboard is returning 500s.
Drill humans on the handoff. Our SOC sits in Sydney and Melbourne, but we cover global hours. During an incident we line up Slack/Teams bridges with your SREs, confirm business impact, and keep execs in the loop while traffic drains to the healthy provider.

With that in place we routinely hit sub-five-minute diversion times, including DNS propagation, because the decision, the tooling, and the people are ready before the outage hits.

What Peakhour brings to your Plan B

Independent authority, familiar vendors. We leverage multiple established DNS providers instead of locking you into ours. You keep your contracts; we bring the automation and guardrails.
Unified multi-CDN config. Cache rules, image optimisation, WAF, and routing policies stay aligned across providers so you don’t lose capabilities when you switch.
Real drills, not just runbooks. Quarterly failover exercises prove that certificates, APIs, and humans are ready. We share the post-mortems so your execs see clear RTO/RPO numbers.
People you can phone. 24×7 Australian-based engineers who know your stack and can execute the play while your own team communicates with customers.

Book a resilience review

If Tuesday exposed that your failover path still depends on your primary provider’s dashboard, book a 30-minute Resilience Review with Peakhour and we’ll:

Map who really controls your DNS today.
Identify the gaps between your primary and standby CDNs.
Outline the automations we can layer on top of your existing DNS and hosting vendors.

The output is a concrete Plan B, a drill schedule, and a team that can execute it the next time a global provider blinks.

Did Residential Proxies enable a $600 Billion loss?

2025-01-31T00:00:00+11:00

The DeepSeek story puts residential proxy networks under scrutiny as a possible factor in AI's latest market disruption. In January 2025, the Chinese startup's emergence erased $600 billion from Nvidia's market value by demonstrating AI capabilities that match industry leaders at a fraction of the cost.

The path to this capability raises a practical security question for AI platforms. Leading platforms protect their APIs with multiple security layers - rate limiting to prevent mass data extraction, bot detection to block automated requests, and geoblocking to restrict access from certain regions. These measures are meant to prevent the systematic collection of training data.

Residential proxy networks create a route around those protections. These networks route traffic through household IP addresses, so requests appear to originate from homes in permitted regions. A request from a restricted location could look like legitimate traffic from Sydney, Melbourne, or Perth.

The circumstances suggest this approach is plausible. By distributing requests across millions of residential IPs worldwide, each IP could maintain human-like patterns while staying below rate limits. The aggregate data could form a substantial training set without triggering security alerts.

Meta's lawsuit against Bright Data strengthens this possibility. The case exposed how proxy providers monetise residential IPs, often without homeowners' knowledge. That model creates a global network capable of bypassing traditional security measures - exactly the type of infrastructure needed for large-scale data collection.

The residential proxy industry threatens $600 billion in business value through data theft and security bypasses. DeepSeek's impact on Nvidia's market capitalisation highlights the real-world impact of residential proxies.

For AI platforms, the question is operational. How can platforms distinguish between legitimate users and well-crafted requests through residential proxies? When geographical restrictions lose meaning, what security measures remain effective? Traditional IP Intelligence based proxy detection based on historical usage is no longer effective; per-connection proxy detection is essential.

DeepSeek's emergence suggests AI security teams need to revisit their assumptions. The potential use of residential proxy networks to dissolve digital borders challenges current approaches to platform protection.

Addressing Key Cloud Security Categories

2024-05-01T10:00:00+10:00

A recent Scale Venture Partners analysis sets out emerging opportunities in cloud security after Wiz. Peakhour is a reverse proxy rather than a cloud control-plane product, but it addresses several of these categories and covers related security needs at the application edge.

Cloud Security Posture Management (CSPM)

The analysis identifies CSPM as a key category in cloud security. Peakhour is not a traditional CSPM, but it contributes to security posture management through:

Traffic Analysis: Peakhour analyses incoming traffic patterns to identify potential security risks.
Configuration Recommendations: Peakhour recommends security configuration improvements based on observed traffic patterns.

Cloud Workload Protection Platform (CWPP)

The article notes that CWPP products provide granular protection for cloud workloads. Peakhour contributes to workload protection through:

Application-Layer Filtering: Peakhour filters traffic at the application layer to protect cloud workloads.
Real-Time Threat Detection: Peakhour detects and blocks threats in real-time.

Cloud Detection & Response (CDR)

CDR focuses on detecting, investigating, and responding to incidents. Peakhour supports CDR work via:

Log Generation: Peakhour generates detailed logs of all traffic for incident investigation.
Anomaly Detection: Peakhour detects anomalous traffic patterns that indicate security incidents.
Automated Response: Peakhour responds to detected threats by blocking malicious traffic.

Cloud-Native Application Protection Platform (CNAPP)

The analysis defines CNAPP as a combination of CSPM, CWPP, and CDR. Peakhour aligns with that model through:

Integrated Security: Peakhour provides a single platform for traffic filtering, threat detection, and response.
Application-Centric Protection: Peakhour's reverse proxy design protects cloud-native applications at the application edge.

Cloud Infrastructure Entitlement Management (CIEM)

Peakhour does not directly manage cloud infrastructure entitlements, but it complements CIEM efforts through:

Access Pattern Analysis: Peakhour analyses access patterns to applications, providing insights that can inform entitlement decisions.

Non-Human Identity (NHI)

The article highlights the growing importance of managing non-human identities. Peakhour contributes to this area by:

Service-to-Service Communication Monitoring: Peakhour monitors and controls service-to-service communication.

Remediation Ops (RemOps)

RemOps focuses on managing the growing volume of security alerts. Peakhour supports RemOps through:

Alert Aggregation: Peakhour aggregates security events from traffic analysis into usable alerts.
Prioritisation: Peakhour prioritises alerts based on threat severity and potential impact.

Additional Peakhour Capabilities

Peakhour also addresses cloud security needs outside the categories covered in the Scale VP analysis:

DDoS Protection

Peakhour provides DDoS protection via:

Layer 7 Rate Limiting: Peakhour protects against application-layer DDoS attacks.
Traffic Anomaly Detection: Peakhour identifies and mitigates DDoS attacks in real-time.

Content Delivery Network (CDN)

Peakhour's delivery and cache functionality reduces cloud load and traffic bills through:

Traffic Optimisation: Peakhour reduces load on origin servers and decreases traffic bills.
Geographic Distribution: Peakhour serves content from geographically distributed nodes.

Bot Management

Peakhour manages bot traffic through:

Bot Detection: Peakhour identifies bot traffic.
Policy Control: Peakhour implements policies for managing different types of bots.
Automated Mitigation: Peakhour applies countermeasures against malicious bot activity.

Cloud Visibility

Peakhour addresses visibility gaps in modern cloud environments:

Traffic Insights: Peakhour provides detailed insights into front-end traffic patterns.
Real-Time Analytics: Peakhour delivers real-time analytics on traffic, threats, and application behaviour.

Final Thoughts

Peakhour addresses several categories identified in the Scale VP analysis of emerging cloud security opportunities. It also covers adjacent needs at the application edge, where traffic, threats, bots, delivery, and visibility meet.

See how Peakhour's Application Security Platform addresses key areas of modern cloud security. Contact our team to strengthen your cloud security posture.

RFC 9460

2023-11-16T00:00:00+11:00

RFC 9460 introduces two DNS record types: "SVCB" (Service Binding) and "HTTPS". They let browsers learn more connection details during DNS lookup, before redirects and TLS negotiation add extra steps. The result is cleaner connection setup, with practical improvements in speed, security, and efficiency.

Understanding the Current Process

Traditionally, when a browser connects to a website, it follows a sequence:

Browser requests site via HTTP.
Server redirects request to HTTPS.
Browser receives ALPN (Application-Layer Protocol Negotiation) during the HTTPS handshake.

The model is secure, but it is not optimal. It involves multiple round trips, which affects Time to First Byte (TTFB) and the overall user experience. Load balancing and failover are also less direct than they could be. RFC 9460 changes this by allowing DNS to provide the necessary connection details earlier. That reduces the steps involved in establishing a secure connection, lowering TTFB.

The Impact of SVCB and HTTPS Records

SVCB and HTTPS records move useful connection hints into DNS. They speed up the time-to-first-packet by incorporating the Alt-Svc HTTP header and ALPN TLS extension into DNS, which shortens connection setup. These records also enable redirection at the zone apex, a task not possible with CNAMEs. They simplify DNS load distribution and failover, making web services more resilient. They also remove the need for HSTS preloading and support Encrypted Client Hello (ECH), formerly ESNI, for better privacy.

Adoption and Industry Response

Adoption started before the RFC was finalised. Firefox has been conducting HTTPS lookups since May 2020, limited to DNS over HTTPS (DoH). Apple's iOS, Safari, and macOS have followed suit since September 2020. Chrome introduced partial support in December 2020 and has recently enabled ECH by default. Various DNS service providers have also started supporting HTTPS and SVCB records.

As reported on Netmeister, adoption is still early but not insignificant. As of October 2023, about 10 million domains have implemented an HTTPS record for their 'www' service names, roughly 4.4% of domains. Around 9.1 million domains, or about 4.0%, use the record on their bare second-level domain name. Among the top 1 million domains, approximately 22.5K (25.5%) use HTTPS records for 'www' service names, and nearly 24K (25.6%) use them on bare domains.

What the Records Look Like

A typical SVCB record might look like this:

_example.com. 7200 IN SVCB 1 svc4.example.net. (alpn="h2,h3" port="8004")

This record indicates that the service at _example.com can be accessed at svc4.example.net using either HTTP/2 or HTTP/3 on port 8004.

An HTTPS record could be:

example.com. 3600 IN HTTPS 0 svc.example.net.

This record suggests that example.com should be accessed securely through svc.example.net.

Apex Domains and the Importance of SVCB/HTTPS Records

One long-running DNS limitation is the inability to use CNAME records at the apex (root level) of a domain due to conflicts with other necessary records like NS and SOA. RFC 9460's SVCB/HTTPS records address this by enabling apex domain aliasing without those conflicts. This matters for efficient content delivery networks (CDNs) and load balancing strategies.

These records enhance capability

1. Load Balancing:

Consider a website that needs to distribute traffic across multiple servers. SVCB records can indicate different server endpoints with varying priorities.

example.com. IN SVCB 10 server1.example.com. (alpn="h2,h3")
example.com. IN SVCB 20 server2.example.com. (alpn="h2")

In this example, server1.example.com is the preferred endpoint (lower priority number), offering both HTTP/2 and HTTP/3 protocols. If it's unavailable, traffic automatically shifts to server2.example.com.

2. Failover Mechanism:

For a service that requires high availability, SVCB records can express failover directly:

critical-service.example.com. IN SVCB 1 primary-service.example.com. (alpn="h2,h3")
critical-service.example.com. IN SVCB 2 backup-service.example.com. (alpn="h2")

Here, primary-service.example.com is the primary endpoint. If it fails, the system automatically falls back to backup-service.example.com.

3. Apex Domain Usage:

A practical advantage of SVCB/HTTPS records is their ability to handle apex domains, where CNAME records are not feasible. This is important for root domain aliasing to different service providers.

example.com. IN HTTPS 0 cdn-provider.example.net.

This record indicates that the apex domain example.com is to be served through cdn-provider.example.net, overcoming traditional DNS limitations.

4. Encrypted ClientHello Support:

Future enhancements of SVCB could include keys for Encrypted ClientHello, which improves privacy and security during the initial TLS handshake.

secure.example.com. IN SVCB 1 tls-service.example.net. (ech="base64-encoded-key")

This record can be used to initiate a TLS connection with tls-service.example.net using the provided Encrypted ClientHello key.

5. Directing Traffic to Specific Protocols:

For services that need to direct clients to newer or more efficient protocols, SVCB records can specify the exact protocols to use.

api.example.com. IN SVCB 1 api-server.example.com. (alpn="h3")

Clients that understand HTTP/3 can connect directly using this protocol, bypassing the usual HTTP/1.1 or HTTP/2 protocols.

The Long Wait

HTTPS has been around for a while, so RFC 9460 raises an obvious question: why did this take so long? Apex records have had their share of problems, including not being able to use CNAMEs and having to resort to custom records like ALIAS or Cloudflare's 'cname flattening'.

It is a fair question. We've had some bizarre records hanging around for ages along with a wide range of solutions to the "CNAME at the zone apex" problem.

Credit to the creators of RFC 9460 for getting this through and obtaining browser support: - B. Schwartz from Meta Platforms, Inc. - M. Bishop from Akamai Technologies - E. Nygren from Akamai Technologies

Final Thoughts

RFC 9460 gives DNS a more useful role in HTTPS connection setup. SVCB and HTTPS records let operators publish endpoint, protocol, failover, and privacy information before the browser starts negotiating the connection. That gives service providers more precise control over how clients reach web services, with practical benefits for performance, reliability, and security.

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.

Navigating CDN Consolidation

2023-11-01T00:00:00+11:00

The CDN industry is moving quickly, with major providers such as Akamai and Cloudflare consolidating their positions. For businesses caught in that movement, changing CDN providers is rarely a simple swap. Your CDN sits in front of your website or application, so migration decisions touch performance, security, routing, caching, and operational risk.

Market Shifts in the CDN Industry

The CDN market is being reshaped by large providers and newer entrants. Akamai's acquisition of Linode is one example, expanding its cloud services and strengthening its position beyond CDN. Cloudflare is moving in a similar direction, adding cloud-based services around its CDN platform.

Akamai's Strategic Moves

Akamai has recently bought customer contracts from both Lumen and StackPath. This is likely to lift its 2024 revenue by tens of millions of dollars. The transferred customers will also benefit from Akamai’s wider cloud and security services.

Azure CDN Standard from Akamai, StackPath CDN, and Lumen CDN are all going offline soon. Clients have received only 2-3 months' notice to migrate, which is a tight window for a service that usually has routing, security, caching, and origin dependencies. Vendors should avoid putting customers in this position. A multi-CDN strategy can reduce that exposure.

What Happened to Section.io?

Section.io, once a CDN, shifted to edge computing before being sold to Webscale. That leaves approximately 300 Australian websites looking for new service providers. If you are one of them, now is the time to act.

These moves make the decision to switch or stay with a CDN provider more complex, especially for smaller businesses that need flexible and reliable local alternatives such as Peakhour. Switching your CDN is not as straightforward as changing a DNS record. Your CDN acts as the gateway to your website or application, so a move can involve reconfiguring a large part of the delivery stack.

Why Peakhour Is the Right Choice

Peakhour is a local, reliable alternative in an industry changing quickly. We offer the flexibility needed for customisation and a full suite of services.

If you are considering a CDN switch, treat it as a technical migration rather than a procurement task. Peakhour can help make that transition smoother.

Peakhour's Top 10 Things to Consider When Changing Providers

Switching CDNs? Work through these ten factors before you move:

Caching Rules: Use the migration to review and optimise your caching settings.
POP Distribution: Understand how the new CDN's points of presence may affect your traffic.
Security Gaps: Evaluate how the new CDN's security measures compare to your current provider.
Access Lists: Make sure IP whitelists and blacklists are carried over cleanly.
Origin Security: Update IP addresses to ensure your origin server recognises the new CDN.
SSL/TLS Certificates: Confirm the new CDN supports your existing SSL/TLS settings and can carry over the certificates you need.
API Compatibility: Ensure the new CDN offers APIs that match or exceed your current usage.
Analytics and Monitoring: Assess if the new CDN's analytics tools meet your needs.
Rate Limiting: Review the new CDN's rate limiting options, especially if your site experiences traffic bursts.
Costs: Account for migration work, potential downtime, and any hidden fees.

Additional Considerations for a Seamless Transition

Beyond the top ten, also consider:

Bot Protection: Evaluate how the new CDN manages automated traffic.
User Agent Validation: Make sure the new CDN effectively screens search engine bots.
IP Reputation Lists: Know how your new CDN updates and uses IP reputation lists.
API Protection: Confirm that the new CDN provides strong API security controls.
Dynamic Page Caching: Check how the new CDN handles caching for dynamic content.
Query String Handling: Understand how your new CDN treats query strings, as this can affect cache performance after migration.

Special Concerns for E-commerce Sites

For e-commerce, also think about:

Site Integrations: Does the new CDN support plugins for your platform, such as Magento?
Custom WAF Rules and Exceptions: Ensure these can be moved to the new CDN.
Image Optimisation: Update Image APIs if your CDN handles image transformations.

Advanced Configurations

Advanced setups need closer review:

Origin Mounting: Confirm your multiple origins will work as needed with the new CDN.
Request Routing: Make sure you can replicate your existing routing configurations with the new provider.
Edge Redirects: Ensure the new CDN can handle any redirects you’ve configured at the edge.

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.

Content and Origin Mounting

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

Some features look niche until you map them to the problems they remove. Content mounting is one of those features. It has been available in Peakhour for some time and has helped solve some unique challenges for our biggest clients. We've applied it to SEO, usability, performance, and security problems. Peakhour's implementation is also unique in the CDN world.

What is Content Mounting?

Peakhour's 'Content Mounting' lets you 'mount' content hosted on another website or server onto a subfolder of your main website. For example, say you have the primary hostname of:

example.com

This feature effectively means that you can serve content from:

shop.example.com

under your primary hostname, eg

example.com/shop/.

Fetching content from a different origin is configured using Edgerules, giving you a high degree of control over how content is fetched and for whom. EdgeRules allow you to:

Match criteria beyond the URL, for example a cookie value, a header, the device type, and more.
Override the hostname header, eg the incoming request for example.com will have the host header to the origin replaced with shop.example.com. This is crucial for the secondary origin server to respond to the request. It also overrides the Server Name Indication (SNI) for the request to the origin.
Rewrite the path, eg the request for /shop/ can be rewritten to be just / so it matches the URL scheme on the secondary origin.
Rewrite links in the returned HTML document. Content on shop.example.com will have resources/links referencing shop.example.com. Those links need to be rewritten as example.com/shop/ so navigation stays on example.com and CSS/JS/images load properly. The restriction is that only links in HTML will be rewritten. Links in JavaScript or CSS won't be rewritten, so content might not look right.

Use Cases for Content Mounting

Boost domain authority: By 'mounting' all your content onto your main domain, you can significantly increase the amount of quality content under your primary URL. This aggregation can improve your website's domain authority, a key factor search engines consider when ranking your site.
Improved User Experience: This strategy also improves the user experience by keeping everything under one main domain. It reduces confusion, provides consistency, and keeps navigation seamless. Search engines prioritise websites that offer a strong user experience, so this could indirectly improve your rankings.
Improve Performance: Each hostname that the browser has to connect to incurs a performance cost. It has to start a new thread and negotiate a DNS lookup and TLS handshake. You can speed things along with browser hints like dns-prefetch and pre-connect but it can still be in the region of 100-500ms per hostname. Mounting them onto your main domain and allowing Peakhour to maintain warm connections to the different hosts can deliver measurable benefits.
API Security: With the rise of Headless eCommerce and microservices, it is common for information to be fetched from several different hostnames. By mounting them on your main domain, say under /api/, you can achieve versioning and consistency.
Eliminate CORS configuration issues and preflight requests: When JavaScript in your browser has to call another hostname, it needs specific headers that grant permission, and there is also a preflight request penalty. Trendspek eliminated CORS and preflight requests from their application using our content mounting and dramatically improved 3D model loading.

Conclusion

Content mounting is a practical tool for organising and orchestrating your website content. With the rise of microservices and headless ecommerce, it can be vital for ensuring a consistent and secure website experience.

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.

ZDNS - scan the entire internet

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

The lack of a free Reverse DNS (rDNS) lookup database has made large-scale DNS research harder. To address this, we used ZDNS, an open-source, high-performance DNS toolkit developed by Stanford University, to create our own rDNS database. To reduce UDP timeout issues during rDNS operations, we devised a scan-ordering approach that randomised the IP space and improved the efficiency of the scanning process.

Leveraging ZDNS for rDNS Lookups Across the Internet

Understanding rDNS is useful for internet operations and research. Active DNS measurement helps us inspect how providers advertise the use of their IP address space. One of the components of this ecosystem is Reverse DNS (rDNS), which serves an important role in IP database categorisation and ASN (Autonomous System Number) classification. However, running rDNS across the entire internet is not a trivial task.

Previously, Rapid7 provided a free database for rDNS lookups, but it has discontinued the offering. This situation has prompted the need to create our own database, calling for a robust, efficient, and scalable tool to accomplish the task. ZDNS was the right fit.

Introducing ZDNS

ZDNS, a part of the ZMap.io project, is a capable tool developed by Stanford University to support scalable and reproducible DNS research. ZDNS is an open-source DNS measurement framework specifically optimised for large-scale DNS research on the public internet. It can resolve 50 million domains in 10 minutes and query the PTR records of the complete public IPv4 address space in approximately 12 hours.

This high-performance toolkit offers a modular interface, enabling researchers to safely implement new functionalities. Its architecture is designed to expose DNS lookup chains by performing recursive resolution. ZDNS supports a command-line interface and outputs results in JSON, a machine-parsable format.

Enhancements by ZDNS

ZDNS's architecture and feature set are tailored to the challenges of extensive DNS research. Its guiding principles are that the DNS lookup chain is exposed, and that the tool is safe, easy to use, and extensible.

ZDNS's performance optimisations make it a suitable tool for DNS experiments that require querying a large number of names. Parallelism, UDP socket reuse, and selective caching are some of the critical performance optimisations that enable ZDNS to efficiently handle large volumes of DNS queries.

ZDNS's scalability, execution time, and success rate have been evaluated against several existing tools, showcasing its performance. For instance, when it comes to exposing the DNS lookup chain, ZDNS is 85 times faster than Dig. ZDNS also outperforms other higher-performance tools, achieving 2.6 to 3.6 times more successful queries per second and experiencing about 30% less packet drop than MassDNS.

Our rDNS Journey

When we started scanning the whole internet with rDNS, we hit a practical roadblock: UDP timeouts made the scans slow. The system spent too much time waiting for responses from parts of the internet that were either empty or broken.

We used two changes. Firstly, instead of scanning the internet's addresses in order, we mixed them up and scanned randomly. This spread out our requests and stopped the system from getting stuck on troublesome ranges. Secondly, we checked smaller sections of the internet first, so we did not waste time waiting for big chunks of the internet that weren't responding.

With these changes, we scanned the whole internet in 13 days, finding over a billion addresses. The main lesson was straightforward: scan order matters when timeout behaviour dominates runtime.

Wrapping Up

ZDNS has proven to be a valuable tool for DNS research, especially for substantial tasks like performing a reverse DNS scan of the entire internet. Our experience underscores the value of practical adjustments when dealing with large-scale challenges, like randomising the IP space to avoid delays caused by UDP timeouts.

As an open-source tool, ZDNS is available on Github. For more detail, read the award-winning paper presented at IMC 2022.

Our work with ZDNS shows its value in DNS research and the operational detail involved in large-scale DNS work. By randomising the scan order, we mitigated timeout issues and improved the efficiency of our scanning process.

Izhikevich, L., Akiwate, G., Berger, B., Drakontaidis, S., Ascheman, A., Pearce, P., Adrian, D., & Durumeric, Z. (2022). ZDNS: a fast DNS toolkit for internet measurement. In Proceedings of the 22nd ACM Internet Measurement Conference (pp. 33-43). https://doi.org/10.1145/3517745.3561434 ↩
ZMap Project. (n.d.). ZDNS. GitHub. Retrieved 2023-05-15 13:00, from https://github.com/zmap/zdns. ↩

Maximising Website Speed

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

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

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

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

The Need for Speed

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

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

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

Correlation with Search Rankings

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

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

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

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

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

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

Conversion Impact of Speed

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

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

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

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

Real-Life Success Stories

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

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

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

Optimising for Search Performance

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

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

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

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

Enhancing Engagement

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

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

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

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

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

Key Speed Metrics

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

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

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

User Expectations and Impact on Business

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

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

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

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

Common Culprits

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

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

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

Continuous Monitoring and Performance Optimisation

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

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

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

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

Preparing for the Coming Recession

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

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

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

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

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

Down But Not Out - JXL Will Return on Safari

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

Just as we were coming to terms with the controversial decision by Google to drop support for JPEG-XL (JXL) in Chrome, Apple announced support for JXL during the WWDC June 5th livestream. That is a meaningful shift. JXL was down, but not out.

Google's decision to stop JXL support in Chrome surprised us at Peakhour, along with plenty of others who care about web performance and image delivery. Google Chrome, as the most used browser globally, often sets the course for web standards. In deciding to drop JXL, Google appeared to be exercising its dominance over those standards, and the decision drew real debate in the web community.

Apple's announcement changes the picture. Apple has long pushed high dynamic colour and high-resolution features, and Safari support is a useful signal for image delivery. By bringing JXL support to Safari, Apple is giving this promising image format a fair go.

This move also hints at wider JXL support across the entire Apple ecosystem, which includes iPad, iPhone, Mac, and Apple TV. While there are still some limitations - embedded colour profiles and animations are not yet supported in the current MacOS Sonoma beta - we hope these gaps are fixed soon.

At Peakhour, this is good news. We look forward to welcoming Apple users to our websites, where they will be able to see the quality benefits of JXL images as soon as their operating systems support it.

This turn of events gives JXL a much-needed boost. It does not undo Google's Chrome decision, but it keeps the format in play and makes the future of web image formats less settled than it looked a short while ago.

Understanding HTTP Link Headers

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

HTTP headers are part of browser requests and server responses. They carry information about the connecting client, the requested resource, the server, and other request context. An HTTP header has a case-insensitive name followed by a colon (:), then its value. Headers are used for authentication information, content negotiation, and related protocol behaviour. Here are some sample request headers sent by my browser when requesting a page on the Peakhour website:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-AU,en;q=0.9
Connection: keep-alive
Cookie: _ga_NRWSVE0PSC=GS1.1.1685943893.13.0.1685943893.0.0.0
Host: www.peakhour.io
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.4.1 Safari/605.1.15

The HTTP Link header

An HTTP Link header lets a server send context about a document back to a client. It can identify related resources or the direct location of a specific asset. For page-load optimisation, Link headers can be an alternative to putting preload/preconnect/prefetch hints in the HTML.

History

HTTP Link headers were proposed as a standard in the late 1990s, around the same time the HTTP/1.1 protocol was defined. However, it wasn't until 2010 that HTTP Link headers were officially recognised by the Internet Engineering Task Force (IETF) in RFC 5988, which described their purpose and functionality.

Uses

HTTP Link headers have several uses in web development. Some common examples are:

Pagination: Say we have a blog site with hundreds of posts, and we display 10 posts per page. When a user requests a page, we can use Link headers to provide URLs for the next and previous pages. This helps navigation through the large list of posts. Here's an example of how it might look:
```
Link: </posts?page=2>; rel="next", </posts?page=4>; rel="prev"
```
Preloading: Suppose we have a heavy image or a large CSS file that we know will be required for a webpage. We can use a Link header to tell the browser to start downloading it early, improving the perceived page load speed. For instance:
```
Link: </images/big-picture.jpg>; rel=preload; as=image
```
Resource Hints: Link headers can give the browser hints about resources that might be needed in the future, so the browser can decide whether to fetch them ahead of time. For instance:
```
Link: </scripts/myscript.js>; rel=prefetch
```

Comparison to Link Tags and Why Headers Can Be Better

Now you might be wondering, "Why use Link headers when we can use HTML Link tags?" There are several reasons HTTP Link headers might be a better choice:

Faster Processing: Since HTTP Link headers are part of the HTTP response, they arrive before the HTML document. This allows browsers to start preloading or prefetching resources sooner, which can improve page load times.
Greater Flexibility: HTTP Link headers can be used in situations where HTML Link tags cannot. For instance, they can be used with file types that don't support HTML, like JSON or XML. They can also be added by a third party, e.g., an edge delivery layer such as Peakhour, without the need to parse and rewrite the HTML document.
Less Clutter: Link headers can make your HTML less cluttered, as you can avoid filling the HTML document with numerous Link tags.

Conclusion

HTTP Link headers are a small part of HTTP, but they are useful for performance and flexibility. An edge delivery layer can add Link headers without the overhead of parsing or manipulating the main document, which makes them useful for optimising website performance.

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.

The Death of JPEG-XL

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

Today, Peakhour disabled JPEG-XL transformations on our image optimisation service. We had enabled them because the technical case looked strong, but that work came to an abrupt stop when Google announced it was deprecating JPEG-XL in Chrome.

JPEG-XL (JXL) was widely treated as a serious next-generation image format. It was royalty-free, performed better than JPEG, and had only recently become practical to target, with the bitstream frozen in late 2020. Google then removed support for the young format in Chrome 110, a decision that mattered because of Chrome's reach.

The Rise and Fall of JXL

The decision to phase out JXL was hard to reconcile with the state of the format. As an image optimisation service focused on transparent image optimisation, we had been following JXL closely and had seen substantial improvements and interest. Seeing it shelved so soon was frustrating, especially since it was largely based on Google's own PIK proposal.

The rationale provided by Google was that there wasn't "enough interest from the entire ecosystem" and the format did not bring "sufficient incremental benefits." That justification was thin. JXL was still experimental, so broad adoption was always going to take time. Google also did not provide direct comparisons with existing formats that proved JXL lacked incremental benefits.

Google's move shows how much control Chrome gives it over web standards, with other browsers often left to follow. That matters. By deciding what features are included or omitted in Chrome, Google shapes the web, often in line with its own strategic interests. The deprecation of JXL in favour of its own patented AVIF format is one example.

A Resounding Response From the Community

The community response was unusually strong. The issue surrounding JXL's removal became the second most "starred" issue in the history of the Chromium project. Developers raised clear concerns about Google disregarding community feedback while exercising heavy influence over web standards. Google's interpretation of "ecosystem interest" may be more self-referential than it appears.

This incident, like many before it, shows the control Google exercises over the web and the impact of its decisions on the internet ecosystem. Our removal of JXL transformations from Peakhour's services is a reluctant acceptance of that reality.

The Way Forward

Google's decision may have sounded the death knell for JXL, but it does not end work on better image formats. We remain committed to optimising the digital experience for our customers and will continue to support formats that improve performance and user experience.

This incident also shows why alternatives matter when one vendor has outsized influence. Browsers like GNU IceCat, which plan to support JXL and similar formats, keep pressure on the dominant path, and networks beyond the web like Gemini remind us that the web is not a monopoly.

This is our message to the "big G": we might be smaller, but we won't be bossed around. The internet is broad enough for more than one path.

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.

Origin shield

2022-06-10T13:00:00+10:00

CDN providers often promote the size of their network, and how many Points of Presence (POPs) they have. Higher capacity, more resilient networks are useful from a security point of view (think DDoS attacks), but more POPs can also work against what the CDN was designed to do: take load off an origin and improve performance for end users.

The POP Problem

Modern CDNs are what's called 'Pull' CDNs. That means the CDN won't store content/resources until a user requests it. The first time a user requests a resource, it goes to the CDN POP, checks its local cache, gets a miss, and then passes the request through to origin. As the resource is returned, the CDN stores a copy for the next time someone wants it. If your CDN has 100 POPs, then this process has to be repeated 100 times to fully 'warm' the CDN for that specific resource. That's 100 requests to origin. The more POPs your CDN has, the more likely you are to get a miss and hit the origin.

When the caches at POPs are fully populated, the effect on your application can be minimal. During a cache MISS event, typically either due to resource expiration or a manual purge, many requests can be sent to the origin server concurrently while the individual POPs rebuild their caches. The more POPs, the longer the process takes.

This can be a problem, especially when caching dynamic pages that need to be server side rendered, large resources, or transformed resources. For example, take a busy ecommerce store running Magento during a sale, Magento will purge content when sales are made, forcing the cache to rebuild each time. During a busy period it can reduce your cache hit rate and degrade site performance.

Enter Origin Shield

CDN Origin Shield is a feature that lets you nominate the CDN Point of Presence closest to your server as a shield. All requests that hit other POPs and receive a cache miss will then go to the nominated shield before hitting the origin. The shield becomes a 'super cache' and can reduce the amount of requests to your origin in a cache miss.

Peakhour.IO implements origin shield as a simple dropdown on an origin pool where you can select the geographic location that should be used as a shield. Requests to your origin are now routed through this geographic location before reaching your origin in a cache miss scenario.

Clients who use multiple geographic origins can also benefit from Origin shield. Peakhour.IO allows the specification of an origin shield per origin. For geographic load balancing, you will need to contact support for setup.

Seeing is believing

The Peakhour.IO summary now includes your edge CHR, your shield CHR and your overall CHR so that you can see the effect in action.

Some of our clients have seen typical increases of 10-20% of their overall Cache Hit Rate, and greater than 40% when specifically looking at often flushed dynamic content.
Quicker cache convergence
Fewer hits to origin
Better end-user experience
Higher conversions

Final Thoughts

Origin Shield is an important feature for certain types of site, or when you're looking to maximise your cache hit rate. CMSs that offer built in full page caching, like Magento and Drupal, flush content often, and are susceptible to performance degradation as load increases. Minimising hits to the origin in these cases is vital.

If you are interested in getting more out of your CDN, need a bespoke CDN solution, or need a provider that offers performance, optimisation and security services, reach out to discuss the right setup.

Origin shield with request collapsing helps minimise origin hits, improve CHR and maintain user experience for your web application.

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.

Fastly Outage

2021-06-09T13:00:00+10:00

You may have heard that Fastly, one of the world’s largest providers of CDN services, had an outage of about 1 hour on the 8th July. Some of the world's largest websites and services were down, including reddit, CNN, The Guardian, Shopify Stores, Stripe and Spotify, to name a few.

According to Fastly themselves, the outage was caused by a 'service misconfiguration' (Update: Bug triggered by a client changing their configuration), which propagated globally and took websites offline. When users tried to access a website using the Fastly service, they were presented with a Varnish 503 Guru Meditation error (for those of us old enough to remember, Guru Meditation is a geek reference to the Commodore Amiga computer of the late 80s!). This generally occurs when there is an issue contacting the server that the website is actually hosted on. There were also some reports on twitter saying 'unknown domain'.

Essentially, Fastly took down its own network with a bad software update. Similar problems have affected other online platforms in the recent past, including Google, Amazon, and Cloudflare.

Why wasn’t there a Plan B?

Fastly is an excellent service, with an enviable reliability record. There is a reason why they're trusted by some of the world's largest websites to improve reliability and load times. However, the vast majority of Fastly clients still had to sit tight and wait for Fastly to fix the issue. Luckily this was only an hour. It could have been much longer.

Just like death and taxes, software outages are a certainty. The real story is not that Fastly had an outage. It is why didn't these large websites have a contingency plan for a single point of failure. For sites at that scale, this is a major oversight in infrastructure planning.

How to handle a CDN failure

The simple solution is to have a backup CDN provider already configured and tested, ready to switch over to if your primary provider fails. You can then utilise short expiry of DNS records to redirect users when the failure happens. This needn't be very expensive or complicated, although individual circumstances vary.

A Quick Introduction To DNS (Domain Name System)

Modern CDNs, like Fastly, Cloudflare, and Peakhour, operate as ‘reverse proxies’. This means they sit between a website's end users and the website server itself. They achieve this through DNS configuration.

When someone types a domain url into a browser, eg fastly.com, a request is sent to a DNS server with the host name (eg fastly.com) to find the IP address of the server to retrieve the content from. CDNs, like Fastly, get website admins to list the address of the CDN on the DNS server. That means requests for a website go through the CDN first. The process is analogous to listing someone else’s number in the phone book so they take calls for you.

The DNS server has a TTL (Time To Live) associated with its records. This TTL tells whoever asked for an IP address, for a given hostname, to remember the answer and not ask again until after the TTL has passed. Typically DNS record TTLs will be 1 hour, but they can be shorter, eg 1 minute.

Switching providers in case of an outage

By keeping a short TTL in DNS, webmasters can switch the answer for a DNS request to that of another provider, meaning users can quickly be directed to an alternative Cloud Provider. Once service has resumed on the primary provider, DNS can be switched again so normal traffic is resumed. The key is that the alternative provider is configured, tested, and ready to go.

This switch can even be automated to minimise outages. Premium DNS services, like Amazon’s Route 53, have optional health checking of DNS answers. This allows a switch to happen nearly instantly. The only downtime would be for people already on the site who have to wait for the TTL to expire before being directed to the backup Cloud Provider. In fact this is exactly what Peakhour.io does. In the event of a catastrophic outage we use DNS to switch to backup infrastructure so our clients are minimally affected.

Backup provider options

Now we've shown how switching CDN providers can be done, let's compare the major players and how they might serve as a backup CDN for Fastly. The three things we'll look at are Cost, Features, Integration.

Simply route traffic to the origin

This would be the simplest and most cost effective option, Assuming your origin server can handle the increased load that removing its CDN would entail. It also assumes that it's ok to lose any features that you may have been relying on, eg load balancing, WAF, edge scripting, image optimisation etc.

Cloudflare

Many people use Fastly because it uses Varnish, a richly featured, programmable cache with several advanced features. If you rely on those features, eg cache tags, cache on cookie value, custom cache tags, then you have to be on Cloudflare's top plan, which is not cheap.

The other major drawback of Cloudflare is that, unless you are on the most expensive plans, you have to cede control of DNS to them by delegating your domain. Cloudflare DNS is a great service, however it has the major drawback of caching negative DNS requests for an hour. If you were switching from an A record to a CNAME record or vice versa, you could be down for an hour regardless. Not ideal.

Akamai

Akamai has a highly respected, fully featured, and very expensive product. Maintaining a backup option with them will run into the $1000s a month. Only you can decide whether it’s worth it.

Cloudfront

Amazon's CDN offering is the third of the big three alternatives. Since it uses volume based billing, it could be an attractive CDN option as a standby, as long as you don't mind missing out on cache by tag (sorry Magento and Drupal). It is also complicated to configure for dynamic content and could miss features that you need. In fact most people use Cloudfront for static content, eg images, CSS, etc and run a Varnish instance within AWS to provide easier to configure full page caching.

This is what the BBC did with the Fastly outage. They had their backup infrastructure on Cloudfront and, as of time of writing, hadn't switched back to Fastly.

Peakhour.io

Peakhour is also volume based billing with a minimum monthly charge of $20. We provide all the advanced caching features that Fastly does, as well as WAF and image optimisation as standard, all in the one service fee. We don't require you to cede control of DNS to us and we're Australian owned and based.

Final Thoughts

CDNs, no matter how big, can fail. If your website is important then it needs a Plan B. This is how that Plan B works, and it doesn't have to be expensive when using a provider like Peakhour.io.

The important part is having it configured and tested before you need it.

Setting Up A Chia Hobby Farm

2021-04-30T13:00:00+10:00

Here at Peakhour, when we're not making websites faster and more secure, we like new tech and we like a good scheme. We ran Seti@home while at uni, and mined some bitcoin back in its early days (unfortunately we don’t have them anymore). Just recently we decided to set up a Chia farm, not the super-food Chia, but the new crypto coin Chia!

What is Chia?

Chia is not just a cryptocurrency; it is a brand new blockchain and smart transaction platform that implements the first new Nakamoto consensus algorithm since Bitcoin. It was invented by the engineer behind BitTorrent, Bram Cohen, who set out to address the shortcomings of Bitcoin.

The Chia network is set to officially launch on May 3rd, and the crypto world is going crazy getting ready.

I thought Bitcoin was great, what’s wrong with it?

The major flaws that Chia sets out to address are:

The environmental impact

Without getting too technical, Bitcoin relies on very intensive computations to verify transactions (Proof of work). These computations are carried out by 'miners' who are rewarded for their efforts from an ever decreasing pool of possible bitcoin. As the blockchain gets older, the verification gets harder, and as a result the Bitcoin network is now consuming as much electricity as a mid-sized country like Argentina. Huge mining operations have been set up in China, and some even have dedicated power plants. One poster child for the environmental impacts of bitcoin is an Australian startup looking to reopen a decommissioned coal power plant to power its mining operations.

Possibility of manipulation

The huge energy requirements have led to massive server farms in cool regions near cheap electricity, concentrating mining in the hands of a few large players. This centralisation opens up Bitcoin to the possibility of manipulation as anyone with 50% of the network can effectively change the blockchain.

How does Chia address these issues with Bitcoin?

Chia has implemented a new consensus algorithm called proof of space and time. It relies on unused hard disk space, which lots of people have and can use free of charge. Again, without getting too technical, 'Farmers' seed unused space on their hard drive/SSD with 'plots' of cryptographic numbers. When verifying transactions, the network issues a challenge to the farmers, who then scan their plots for the closest answer. The farmer passes this answer back to a server on the network known as a 'timelord'. The farmer with the closest answer is rewarded with a coin.

The more 'plots' a farmer has, the higher the chance of winning a coin.

Setting up the Farm

We got excited about the idea of Chia being the next big thing and decided to hitch a ride on the bandwagon. We had a spare old computer lying around, so we decided to fill it up with as much storage as we could find and farm some Chia!

To set up a farm you need as much space for plots as you can get your hands on. The speed of this space is not critical, so you can use spinning drives. We found 12-terabyte NAS drives to be the sweet spot for bang for buck, and opted for 4x Seagate Ironwolf NAS drives from Scorptec. (Note: they’ve gone up $40 since we bought them!)

Seeding the plots, however, is VERY disk intensive, so you need speedy and reliable SSDs. Since they don't have moving parts you'd think that SSDs would be very reliable, but just like spinning drives, they wear out and eventually die. SSDs come with a TBW (Terabytes Written) rating which estimates the amount of writes you can do before the drive will die. Popular consumer SSDs like a 500GB Samsung EVO 870 have a TBW rating of 300. Chia recommends getting server-grade SSDs that have ratings into the Petabytes, but of course they come with a price to match.

We were limited by the age of our available motherboard, so we could only choose from SATA3-compatible drives. Appropriate enterprise SSDs were also unavailable, so in the end we settled on 500GB Seagate Firecuda 120s that are rated at 700 TBW (also from Scorptec). We decided on two so we could double the plotting rate.

Now we had our hands on the drives, we just had to install everything. Within a few hours of transferring components and wiring it up we were good to go and started plotting.

Our Chia Farm!

Final Thoughts

Our old hardware limits the speed of the SSDs and therefore the number of plots we generate. We're managing around 10 plots a day and will need close to 500 before we’ve filled the available storage.

When we bought our equipment (28th April) the chia calculator showed that we’d be earning around a coin a day when fully plotted. However, with the official launch of Chia imminent, the network has exploded in growth, passing 1 Exabyte (1000 Terabytes) just one day ago. It's now up to 1.68 Exabytes! So unfortunately our estimated time to a coin is down to one every 7 days. That’s still pretty good though, and if Chia does end up supplanting Bitcoin we might just make back the setup costs. It has been a fun exercise, even if we did spend too long on it, and if it does end up being a flash in the pan we can always use the drives for something else….

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.

Common Issues That Affect Website Performance

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

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

1. Latency

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

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

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

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

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

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

How do I check for latency problems?

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

2. Old version of HTTP

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

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

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

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

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

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

3. Slow Server Performance

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

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

How do I check for slow server performance?

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

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

4. Page Weight

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

How do I check my page weight?

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

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

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

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

5. Blocking Resources

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

How do I identify blocking resources?

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

6. Third Party Resources

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

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

Spotting a problem with third party resources

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

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

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

Conclusion

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

Are Australian Magento Stores Ready For Web Vitals?

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

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

A quick refresher of Web Vitals

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

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

How will Australian sites fare?

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

Methodology

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

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

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

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

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

The results

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

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

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

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

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

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

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

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

Sites that pass all criteria

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

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

How you can test your site

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

Conclusion

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

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

Instant Alerts

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

We've introduced Instant Alerts, an optional service that notifies you when there is a problem with your site. You can specify the email addresses and/or mobile numbers that should receive the alerts.

At the moment you can receive alerts when your origin server:

Times out
Cannot be reached at all
Returns an error

To avoid repeated messages, each alert has a cooldown limit you can set from 30 minutes to 24 hours.

If you're using a service like Pingdom to check that your site is up, you probably will want to enable Instant Alerts. Services like Pingdom might be served pages from our cache while your origin server is actually down.

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.