Peakhour.IO - Features

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.

Consistent Hash with Bounded Loads

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

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

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

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

Here's a rough pseudocode example:

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

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

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

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

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

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

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

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

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

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

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

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

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

Locality Sensitive Hashing

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

Locality Sensitive Hashing (LSH) is a computer science technique for designing hash functions for high-dimensional data. LSH aims to maximise the probability that similar items map to the same hash bucket. The principle is to amplify the difference between similar and dissimilar items, keeping similar items closer together while pushing dissimilar items farther apart. This gives a probabilistic approach to nearest neighbour search, a problem that appears in machine learning, data mining, and information retrieval.

Background and Usage of LSH

LSH was introduced by Piotr Indyk and Rajeev Motwani in 1998 to address the "curse of dimensionality," where traditional computational algorithms become significantly less efficient as the dimensionality of a problem increases. This makes LSH useful in contexts dealing with large and complex data sets, including text analysis, recommendation systems, image recognition, and genome sequencing.

The general idea is to use hashing to map high-dimensional data into a lower-dimensional hash space. The hashing scheme is designed so that collisions are much more likely for objects close to each other in the original space than for objects far apart. This supports sub-linear time complexity for nearest neighbour searches, which matters when working with large data sets.

LSH Variant for Load Balancing

LSH is also used in load balancing for distributed systems. A variant of LSH, known as Consistent Hashing, is often used for this purpose. In consistent hashing, the output range of a hash function is treated as a fixed circular space or "ring" (think of this as a circular hash table). Each node or server in the system is assigned a random value within this space, and each data item or request is assigned to the node closest to it in the hash space.

The practical advantage of consistent hashing is that when a node is added or removed, only an average of 1/n keys need to be remapped, where n is the number of servers. Conventional hash functions would require almost all keys to be remapped. This property makes consistent hashing useful in dynamic environments where the server set changes often, such as in a CDN (Content Delivery Network).

LSH in CDNs for Load Splitting and Caching

In a CDN, data is distributed across multiple servers in different geographical regions. The objective is to let users access the data they need as quickly as possible. This is achieved by routing each user's request to the server closest to them that has the data they want.

Consistent hashing, a variant of LSH, fits this scenario. By hashing both data and user requests, we can assign each request to the server closest in the hash space. This approach gives an even distribution of load across all servers, improving overall system performance.

LSH can also make CDN caching more efficient. When a request for a specific piece of content comes in, the CDN can use the hash function to find the server holding that content. The content can then be served quickly, improving the user experience.

LSH and Server Pool Rebalancing

LSH also helps with rebalancing server pools. In dynamic environments, workload changes constantly, and servers may be added or removed frequently. This can create an imbalance in load distribution across servers.

Consistent hashing mitigates this issue. As mentioned earlier, when a server is added or removed, consistent hashing only requires a minimal reassignment of keys. This keeps load redistribution to a minimum, so the system can quickly adapt while maintaining a balanced load across all servers.

Maglev and LSH

Maglev is a network load balancer developed by Google that uses a distinctive approach to connection distribution. It employs a variant of consistent hashing to balance load across a pool of servers. Using a large lookup table and a consistent hashing-like algorithm, Maglev can evenly distribute traffic across servers, even when servers are added or removed.

Maglev's algorithm starts by assigning a pseudorandom permutation of backend servers for each entry in the lookup table. These entries are then filled by iterating over the permutation and assigning each entry to a server. If a server becomes unavailable, its entries are reassigned to other servers using the same permutation. If a server becomes available, it is gradually reintroduced into the permutation, minimising disruption. This is a practical demonstration of LSH's principles applied to server load, high availability, and performance.

Conclusion

Locality Sensitive Hashing has applications from high-dimensional data analysis to load balancing in distributed systems. Its property of bringing similar items closer in the hash space and pushing dissimilar items farther apart makes it useful for handling large and complex datasets. In CDNs and server pool management, LSH, and its variant Consistent Hashing, support balanced load distribution and efficient caching, improving system performance and user experience. Its application in Google's Maglev shows how these principles can be used in production-scale load balancing.

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.

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.

AVIF Support For Automatic Image Optimisation

2020-11-02T13:00:00+11:00

Today we're adding support for the AVIF image format to our automatic image optimisation and image manipulation API. AVIF is currently supported in Chrome Desktop (version 85 and up) and has experimental support in Firefox. Since Chrome support comes via Chromium, other Chromium browsers, including Edge and Opera, are expected to support AVIF by the end of the year.

AVIF has several practical benefits over legacy image formats like JPEG, PNG, and WebP.

Much smaller file sizes for the same picture and quality.
HDR and wide colour gamut support.
Support for transparency (unlike JPEG)
Support for animation (unlike JPEG)

A Quick Background of AVIF

AVIF is a next generation image format derived from the AV1 video codec developed by the Alliance for Open Media, a collaboration between Google, Microsoft, Netflix, Arm, Amazon and others. It uses the same HEIF container as the HEIC format used on iPhones/iPads and offers similar file sizes. However, Apple's HEIC format is based on a commercial, patented codec, so anyone else wanting to adopt HEIC has to pay costly licensing fees. Another next generation format, JPEG XR, developed as a successor to JPEG, was also never widely adopted because of its expensive licensing requirements.

The AV1 codec was developed to be open source and royalty free, addressing the current maze of patent and licensing issues with existing formats. The companies behind the Alliance for Open Media have guaranteed to defend the format against patent challenges.

How does it compare?

NOTE: If you are interested in a technical in-depth comparison between AVIF, JPEG, and WebP, then check out this post from Netflix.

The two most popular image formats on the web today are JPEG and WebP. JPEG was introduced in 1992 and is still very widely used, despite its age. WebP was introduced by Google around 2010 and has only just gained wide browser support.

The first (and main) advantage of AVIF is that file sizes are much smaller than either JPEG or WebP for the same quality image. In recent testing WebP had a 30% advantage over JPEG while AVIF was 50% smaller than JPEG. Our own testing has shown similar results. If you are willing to accept a small loss in image quality, then the improvements become more substantial; we'll look at these results in a separate blog post. If you want to see what difference AVIF will make to your website, try our pageweight report.

The second advantage of AVIF is wide colour and HDR support. You might have seen Apple and others touting their 'wide colour gamut' and High Dynamic Range (HDR) displays. Colour gamut refers to the number of colours a display can reproduce, while HDR lets a display render extra levels of brightness for each colour, creating more realistic colour transitions and revealing more detail in both shadows and highlights. Both JPEG and WEBP have a maximum of 8-bit colour depth (256 levels per colour), so they can't take advantage of these newer displays, a major reason why Apple moved to HEIC in iOS. AVIF supports 10-bit (1024 levels) and 12-bit (4096 levels) colour depths, which can make full use of these higher-quality displays.

Finally, unlike JPEG, but like WebP, AVIF supports transparency and can be lossy or lossless. It can also store a series of animated frames (like animated GIFs).

Drawbacks

Right now the two issues with AVIF are lack of progressive rendering and the speed of encoding. The lack of progressive rendering means nothing is displayed on screen until the image is fully loaded. JPEGs in comparison can display a low quality approximation very early in the load process, which can make the website appear to load faster. This is offset somewhat by AVIF's smaller file sizes, as the full images will be downloaded sooner.

Encoding speed is a problem for the server; large images can take a few seconds on fast CPUs. However, encoders will improve and direct hardware support will grow.

AVIF for Peakhour clients

Peakhour has rolled out AVIF support around the world. For the time being, though, we will not be supporting animation. Peakhour clients don't have to take any action to start seeing the benefits of AVIF. Supported browsers will simply start loading smaller images.

Due to the time taken to encode AVIFs, especially large ones, Peakhour is taking the encoding out of line, even for image API requests. If the AVIF generation is taking too long we'll return a JPEG or WebP, depending on the browser Accept header, until the AVIF is ready to be served from our cache.

AVIF should reduce pageweight for clients whose visitors use supported browsers. Even though internet connections are getting faster, transfer size reductions are still as important as ever.

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.