In the world of network optimization, Content Delivery Networks (CDNs) and caching play a vital role in improving website performance and user experience.

And while both aim to speed up website loading times, they have distinct purposes and mechanisms.

In this tutorial, we'll dive deep into the details of CDNs and caching to understand their similarities, differences, and how they contribute to enhancing online experiences.

Here's what we'll cover:

1. What is Caching?
2. What is a Content Delivery Network (CDN)?
3. Caching vs CDNs – What's the Difference?
4. When to Use Caching
5. When to use CDNs
6. Combining Caching and CDNs
7. Wrapping Up

What is Caching?

Imagine you’re a librarian managing a popular library. Every day, readers come in asking for the same set of books like “Think and Grow Rich” or “The Intelligent Investor.”

Initially, you fetch these books from the main shelves, which takes time and effort. But soon, you notice a pattern: the same set of books are requested repeatedly by different readers. So, what do you do?

You decide to create a special section near the entrance where you keep copies of these frequently requested books. Now, when readers come asking for them, you don’t have to run to the main shelves each time. Instead, you simply hand them the copies from the special section, saving time and making the process more efficient.

This special section represents the cache, storing frequently accessed books for quick retrieval.

Caching is a technique used to store copies of frequently accessed data temporarily. The cached data can be anything from web pages and images to database query results. When a user requests cached content, the server retrieves it from the cache instead of generating it anew, significantly reducing response times.

When a web server receives a request, it can follow different caching strategies to handle it efficiently. One prevalent strategy is known as read-through caching:

1. Request Received: The web server gets a request from a client.
2. Check Cache: It first looks into the cache to see if the response to the request is already there.
3. Cache Hit: If the response is in the cache (hit), it sends the data back to the client right away.
4. Cache Miss: If the response isn’t in the cache (miss), the server queries the database to fetch the required data.
5. Store in Cache: Once it gets the data from the database, it stores the response in the cache for future requests.
6. Send Response: Finally, the server sends the data back to the client.

What to Consider When Implementing a Cache System

Decide When to Use a Cache:

• A cache is best for frequently read but infrequently modified data.
• Cache servers are not suitable for storing critical data as they use volatile memory.
• Important data should be stored in persistent data stores to prevent loss in case of cache server restarts.

Set an Expiration Policy:

• Implement an expiration policy to remove expired data from the cache.
• Avoid setting expiration dates too short (to prevent frequent database reloads), and too long (to prevent stale data).

Maintain Synchronization Between Data Stores and Cache

• Inconsistencies can arise due to separate operations on data storage and cache, especially in distributed environments.

Mitigate Failures:

• Use multiple cache servers across different data centers to avoid single points of failure.
• Over-provision memory to accommodate increased usage and prevent performance issues.

Implement an Eviction Policy:

• When the cache is full, new items may cause existing ones to be removed (cache eviction).
• A popular eviction policy is Least Recently Used (LRU), but other policies like Least Frequently Used (LFU) or First In, First Out (FIFO) can be chosen based on specific use cases.

Real-World Applications of Caching

Social Media Platforms: Imagine scrolling through your Facebook feed. Thanks to caching, you see profile pictures, trending posts, and recently liked content instantly, even if millions of users are accessing the platform simultaneously.

Caching these frequently accessed elements on servers or your device minimizes delays and makes the experience smoother and more engaging.

E-commerce Websites: When browsing Amazon for a new gadget, you expect a seamless shopping experience. Caching plays a crucial role here. Product images, descriptions, and pricing information are cached, enabling the website to display search results and product pages rapidly.

This is especially crucial during peak seasons like Black Friday or Cyber Monday, where caching helps handle surges in traffic and ensures customers can complete their purchases without encountering delays.

Content Management Systems (CMS): Millions of websites rely on CMS platforms like WordPress. To ensure smooth performance for all these users, many CMS platforms integrate caching plugins. These plugins cache frequently accessed pages, reducing the load on the server and database.

This translates to faster page loading times, improved SEO ranking due to faster indexing by search engines, and a more responsive website overall, providing a better experience for visitors.

What is a Content Delivery Network (CDN)?

Now, think of a CDN as a global network of book delivery trucks. Instead of storing all the books in one central library, you have local branches worldwide, each with copies of the most popular books.

When readers request a book, you don’t have to ship it from the main library. Instead, you direct them to the nearest branch, where they can quickly pick up a copy. This cuts down on travel time (data transfer time) and keeps everyone happy with fast access to their favorite books.

In technical terms, a CDN is a network of servers distributed across various locations globally. Its primary purpose is to deliver web content, such as images, videos, scripts, and stylesheets to users more efficiently by reducing the physical distance between the server and the user.

How CDNs Work:

First, imagine that User A wants to see an image on a website. They click on a link provided by the CDN, like “https://mywebsite.cloudfront.net/image.jpg". This requests the image.

Then, if the image isn’t in the CDN’s storage (cache), the CDN fetches the image from the original source, like a web server or Amazon S3.

In response to that, the original source sends the image back to the CDN. It might include a Time-to-Live (TTL) header, indicating how long the image should stay cached.

Next, the the CDN stores the image and serves it to User A. It stays cached until the TTL expires.

Then let's say that user B requests the same image. At that point, the CDN checks if it’s still in the cache. If the image is still cached (TTL hasn’t expired), the CDN serves it from there (a hit). Otherwise (a miss), it fetches a fresh copy from the origin.

What to Consider When Implementing a CDN

• Cost Management: CDNs charge for data transfers. It’s wise to cache frequently accessed content, but not everything.
• Cache Expiry: Set appropriate cache expiry times. Too long, and content might be stale. Too short, and it strains origin servers.
• CDN Fallback: Plan for CDN failures. Ensure your website can switch to fetching resources directly from the origin if needed.
• Invalidating Files: You can remove files from the CDN before they expire using various methods provided by CDN vendors.

Real-World Applications of a CDN

Video Streaming Services: Imagine you're in Sydney, Australia, craving to watch the latest season of your favorite show on Netflix. Without a CDN, the data would have to travel all the way from a server in, say, California, leading to buffering and frustrating delays.

But thanks to CDNs, Netflix caches popular content on edge servers closer to you, in Sydney or its surrounding region. This significantly reduces the distance the data needs to travel, ensuring smooth playback and an uninterrupted viewing experience, regardless of your location.

In fact, studies show that CDNs can reduce video startup time by up to 50%, making a significant difference in user satisfaction.

Gaming Content Distribution: Gamers know the pain of waiting for massive game updates or DLC downloads. But companies like Steam and Epic Games leverage CDNs to make things faster.

These platforms cache game files, updates, and multiplayer assets on edge servers close to gaming communities. This means whether you're downloading a new game in New York or patching your favorite title in Tokyo, the data doesn't have to travel across continents.

Using CDNs can decrease download times quite a bit, leading to quicker access to the games you love and smoother multiplayer experiences with minimal lag.

Global News Websites: Staying informed about global events shouldn't be hindered by slow loading times. Major news organizations like BBC News and The New York Times use CDNs to ensure their breaking news updates and multimedia content reach audiences worldwide instantly.

By caching critical information like articles, videos, and images on servers across different continents, CDNs enable news websites to deliver real-time updates quickly, keeping readers informed regardless of their location.

During major events or emergencies, this can be especially crucial, as evidenced by a case study where a news organization using a CDN reported a 20% increase in website traffic without any performance issues during a breaking news event.

Caching vs CDNs – What's the Difference?

Similarities between caching and CDNs:

Improved Performance: Both CDNs and caching aim to enhance website performance by reducing latency and speeding up content delivery.

Efficient Resource Utilization: By serving cached or replicated content, both approaches help optimize resource utilization and reduce server load.

Enhanced User Experience: Faster load times lead to a better user experience, whether achieved through CDNs or caching.

Differences between Caching and CDNs

Scope:

• CDNs: CDNs are a network of servers located in different geographic locations around the world.
• Caching: Caching is a method of storing web content on a user’s local device or server.

Implementation:

• CDNs: CDNs require a separate infrastructure and configuration.
• Caching: Caching can be implemented within a web application or server using caching rules and directives.

Geographic Coverage:

• CDNs: Designed to deliver web content to users across the world.
• Caching: Typically used to improve performance for individual users or within a local network.

Network Architecture:

• CDNs: Use a distributed network of servers to cache and deliver content.
• Caching: This can be implemented using various types of storage such as local disk, memory, or a server-side cache.

Performance Benefits:

• CDNs: Provide faster and more reliable content delivery by caching content in multiple locations.
• Caching: Improves performance by reducing the number of requests to the origin server and delivering content faster from a local cache.

Cost:

• CDNs: Can be more expensive to implement and maintain due to the need for a separate infrastructure and ongoing costs for network maintenance.
• Caching: Can be implemented using existing infrastructure and server resources, potentially reducing costs.

When to use Caching

Caching is ideal for frequently accessed content that doesn't change frequently. This includes static assets like images, CSS files, and JavaScript libraries.

It's particularly effective for websites with a substantial user base accessing similar content, such as news websites, blogs, and e-commerce platforms.

Caching can also significantly reduce server load and improve response times for users, especially in scenarios where content delivery latency is a concern.

When to use CDNs

CDNs are invaluable for delivering content to a global audience, especially when geographical distance between users and origin servers leads to latency issues.

They are well-suited for serving dynamic content, streaming media, and handling sudden spikes in traffic.

CDNs also excel in scenarios where content needs to be delivered reliably and consistently across diverse geographic regions, ensuring optimal user experience regardless of location.

Combining Caching and CDNs

In many scenarios, employing both caching and CDNs together yields optimal results, particularly for dynamic websites and applications where a mix of static and dynamic content delivery is essential. Let's consider a popular news website as an example.

Imagine a bustling news website that regularly publishes breaking news articles, accompanied by images and videos. While the core news content is dynamic and frequently updated, the images and videos associated with older articles remain relatively static and are accessed repeatedly by users.

To address this, the website can implement a combined strategy:

1. Caching on the Origin Server: Frequently accessed elements like website templates, navigation menus, and static content are cached directly on the origin server. This caching reduces server load and enhances performance for initial page loads.
2. CDN Caching: The website leverages a CDN to cache frequently accessed images and videos associated with news articles on edge servers located worldwide. This ensures that users, regardless of their geographic location, can swiftly access these elements with minimal latency.

There are many benefits of the combined approach, such as:

• Faster Loading Times: By serving cached content from both the origin server and CDN edge servers, users experience significantly faster loading times, leading to a more engaging browsing experience.
• Reduced Server Load: Caching alleviates pressure on the origin server, enabling it to efficiently process dynamic content updates while serving static elements from cache.
• Improved Global Reach: The CDN ensures that users worldwide can access the website and its content with minimal delays, irrespective of their proximity to the origin server.

But there are also some factors to consider:

• Cache Invalidation: Regularly updating cached content ensures users access the latest information. Most CDNs offer efficient cache invalidation mechanisms to facilitate this process.
• Cost Optimization: While combining caching and CDNs enhances performance, it's crucial to evaluate the cost-effectiveness of caching specific content. Analyzing user access patterns helps determine the optimal caching strategy.

By strategically combining caching and CDNs, you and your team can create a robust content delivery infrastructure that delivers a superior user experience worldwide.

Wrapping Up

Both CDNs and caching play crucial roles in optimizing website performance and user experience by speeding up content delivery.

While caching stores frequently accessed data locally for quick retrieval, CDNs provide a geographically distributed network of servers to deliver content efficiently to users worldwide.

Understanding their similarities in performance improvement and resource utilization, as well as their key differences in scope, implementation, and cost is crucial for choosing the right approach for your specific needs.

In some recent tutorials, I covered supporting file uploads on the front end, supporting file uploads on the back end, and optimizing costs by moving file uploads to object storage.

Today, I'll continue to focus on more architectural work, but this time it’ll be focused on optimizing performance.

Overview of Object Storage Solution

Let's say we have an application that stores uploaded files somewhere in the world. For this example, it’s an Object Storage bucket from Akamai cloud computing services, and I've deployed it to the us-southeast-1 region.

You may be using a different provider and different region, but the following points will still apply.

So when I upload a cute photo of Nugget making a big ol’ yawn, I'll be able to access it at some URL like austins-bucket.us-southeast-1.linodeobjects.com/files/nugget.jpg

Nugget is a super cute dog. Naturally, a lot of people are going to want to see this. Unfortunately, because this photo is hosted in the us-southeast-1 region, anyone that lives far away from that region has to wait longer before their eyes can feast on this beast.

Latency sucks.

And that’s why CDNs exist.

What is a CDN?

CDN stands for "content delivery network". It’s a connected network of computers that are globally distributed and can store copies of the same files so that when a user makes a request for a specific file, it can be served from the nearest computer to the user.

By using a CDN, the distance a request must travel is reduced. This helps resolve requests faster, regardless of a user’s location.

Here’s a webpagetest.org test results for that photo of Nugget. The request was made from their servers in Japan, and it took 1.1 seconds for the request to complete.

Instead of serving the file directly from my Object Storage bucket, I can set up a CDN in front of my application to cache the photo all over the world.

So users in Tokyo will get the same photo but served from their nearest CDN location (which is probably in Tokyo), and users in Toronto are going to get that same file, but served from their nearest CDN location (which is probably in Toronto).

This can have significant performance implications.

Let’s look at that same request, but served behind a CDN. The webpagetest.org results still show the same photo of Nugget, and the request still originated from Tokyo, but this time it only took 0.2 seconds – a fraction of the time!

When the request is made for this image, the CDN can check if it already has a cached version. If it does, it can respond immediately. If it doesn’t, it can go fetch the original file from Object Storage, then save a cached version for any future requests.

Note: the numbers reported above are from a single test. They may vary depending on network conditions.

The Compounding Returns of CDNs

The example above focused on improving delivery speeds of uploaded files. In that context, I was only dealing with a single image that is uploaded to an Object Storage bucket. It shows almost a full second improvement in response times, which is great, but things get even better when you consider other types of assets.

CDNs are great for any static asset (CSS, JavaScript, fonts, images, icons, and so on). By putting it in front of my application, all the other static files can automatically get cached as well. This includes the files that Nuxt.js generates in the build process, and which are hosted on the application server.

This is especially relevant when you consider the “Critical rendering path” and render-blocking resources like CSS, JavaScript, or fonts.

When a webpage loads, as the browser comes across a render-blocking resource, it will pause parsing and go download the resource before it continues (hence “render-blocking”). So any latency that affects a single asset may also impact the performance of other assets further down the network cascade.

This means the performance improvements from a CDN are compounding. Nice!

So is this about showing cute photos of my dog to more people even faster, or is it about helping you make your applications run faster? YES!

Whatever motivates you to build faster websites, including a CDN as part of your application infrastructure is a crucial step if you plan on serving customers from more than one region.

How to Connect Akamai CDN to Object Storage

Now I want to take a little side-quest and share how I set up Akamai with Object Storage. I didn’t find much information on the subject, and I’d like to help anyone in this specific situation. If it doesn’t apply to your use case, feel free to skip this section.

With something like 300,000 servers across 4,000 locations, Akamai is the largest CDN provider in the world. It’s used by some of the biggest companies in the world, but it’s hard to find Akamai-related content because most large companies don't like to share unnecessary information about their infrastructure.

But I'm not most companies :)

(Note: You will need an Akamai account and access to your DNS editor)

In the Akamai Control Center, I created a new Property using the Ion Standard product, which is great for general purpose CDN delivery.

After clicking “Create Property”, you’ll be prompted to choose whether to use the setup wizard to guide you through creating the property, or you can go straight to the Property Manager settings for the new property. I chose the latter.

In the Property Manager, I had to add a new hostname in the Property Hostnames section. I added the hostname for my application. This is the URL where users will find your application. In my case, it was uploader.austingil.com.

Part of this process also requires setting up an SSL certificate for the hostname. I left the default value selected for Enhanced TLS.

With all that set up, Akamai will show me the following Property Hostname and Edge Hostname. We’ll come back to these later when it’s time to make DNS changes.

• Property Hostname: uploader.austingil.com
• Edge Hostname: uploader.austingil.com-v2.edgekey.net

Next, I had to set up the actual property’s behavior, which meant editing the Default Rule under the Property Configuration Settings. Specifically, I had to point the Origin Server Hostname to the domain where my origin server will live.

In my DNS, I created a new A record pointing origin-uploader.austingil.com to my origin server’s IP address, then added a CNAME record that points uploader.austingil.com to the Edge Hostname provided by Akamai.

• A: origin-uploader.austingil.com -> origin server IP
• CNAME: uploader.austingil.com -> uploader.austingil.com-v2.edgekey.net

This lets me build out my CDN configuration and test it as needed, only sending traffic through the CDN when I’m ready.

Finally, to serve files in my Object Storage instance through Akamai, I created a new rule based on the blank rule template. I set the rule criteria to apply to all requests going to the /files/* sub-route.

The rule behavior is set up to rewrite the request’s Origin Server Hostname and change it to my Object Storage location: npm.us-southeast-1.linodeobjects.com.

This way, any request that goes to uploader.austingil.com/files/nugget.jpeg is served through the CDN, but the file originates from the Object Storage location. And when you load the application, all the static assets generated by Nuxt are served from the CDN as well. All other requests are passed through Akamai and forwarded to origin-uploader.austingil.com, which points to the origin server.

So that’s how I’ve configured Akamai CDN to sit in front of my application. Hopefully, it all made sense, but if you have questions, feel free to ask me.

To Sum Up

Today we looked at what a CDN is, the role it plays in reducing network latency, and how to set up Akamai CDN with Object Storage.

But this is just the tip of the iceberg. There’s a whole world of tweaking CDN configuration to get even more performance.

There are also a lot of other performance and security features a CDN can offer beyond just static file caching: Web Application Firewalls, faster network path resolution, DDoS protection, bot mitigation, edge compute, automated image and video optimization, malware scanning, request security headers, and more.

My colleague Mike Elissen also covers some great security topics on his blog.

The most important thing that I wanted to convey today is that using a CDN improves file delivery performance by caching content close to the user.

Thank you so much for reading. If you liked this article, and want to support me, the best ways to do so are to share it, sign up for my newsletter, and follow me on Twitter.

You can find this and my other articles published on austingil.com.

When you're writing a Vanilla JavaScript application, you don't have to host all the code you use on your own site.

Most popular JavaScript libraries are available from a public Content Delivery Network (CDN).

This can simplify deploying the application and keeping dependencies up to date. In fact, if you've followed any JavaScript tutorial for a library, then you've probably already used a public CDN but may not be aware of it.

What is a CDN?

A CDN is a Content Delivery Network. These are file hosting services for multiple versions of common libraries. They are usually highly performant and offer location cached files so no matter where your users are, they receive the files from geo locations close to them. This can make your application faster than hosting files yourself.

CDN's also have the advantage that if you are using libraries common to multiple sites then your users may already have the file cached in their browser. This speeds up your site because the browser doesn't need to download the library again.

For example, JQuery has an official JQuery CDN. If most JQuery applications import the JQuery library from this CDN, then users are more likely to have JQuery in their cache already.

npm-driven CDNs

Not every library has their own CDN. Most libraries deploy to npmjs.com and rely on the programmer adding the library to their project via npm at build time. npm downloads the library from a CDN and adds it to the project locally.

We don't have to be using npm and JavaScript build processes to take advantage of the npm eco-system. We can use an 'npm driven CDN' as the host for libraries, without having to use npm.

An 'npm-driven CDN' is one which hosts the distribution code for libraries which deploy to npm.

For example, AG Grid which I demonstrated in my article "How to Convert a Static HTML Table to a Dynamic JavaScript Data Grid" deploys to npm but does not have its own CDN. Instead, programmers can add a direct reference to AG Grid from a CDN like unpkg.com.

<script src=
"https://unpkg.com/ag-grid-community/dist/ag-grid-community.min.nostyle.js">
</script>

npm-driven CDNs monitor the releases distributed via npm, and host the releases on their own site.

In the source code for my earlier freeCodeCamp post, I used the unpkg.com CDN to import AG Grid in my code using a script element.

As with all code that we copy and paste, it's worth understanding what it does so that we can handle any issues.

What CDNs are available?

I've only ever used three CDNs:

• Unpkg.com
• jsDelivr.com
• cdnjs.com

These are all professional and well-run sites. And the main reason I pick one above the other is that the tutorial I first followed for a library used that particular CDN in the code.

Knowing that multiple CDNs are available is useful because:

• a particular version of a library you want to use might not be on every CDN
• if a CDN starts having issues then you can amend your code to use another
• some libaries may be more popular on one CDN than another and you may want to use the most popular CDN to increase the chance that the JavaScript library code is cached on your users's browser.

npm CDNs distribute more than JavaScript

CDNs deliver more than JavaScript. For example, AG Grid deploys CSS files as well as JavaScript.

These would be referenced from the CDN as normal using link elements.

For example, AG Grid uses two style sheets.

The Structural Style sheet provides the CSS that will layout the data as a Grid.

<link 
 rel="stylesheet"
 href="https://unpkg.com/ag-grid-community/dist/styles/ag-grid.css"
>

The Theme Style sheet provides the visual aesthetics for the Grid.

<link 
 rel="stylesheet" 
 href="https://unpkg.com/ag-grid-community/dist/styles/ag-theme-alpine.css"
>

Both of these CSS files are also deployed to npmjs.com and can be included into our project from a CDN.

How (and Why) to Control the Version of the Library

In my open source table editing tool I use three libraries: AG Grid, PapaParse, and Faker.

Faker recently had an issue where a recent version deployed to npm had issues. So if my code had been defaulting to the latest version then my application would have failed.

Fortunately I had imported a specific version of faker from unpkg. As you can see from the src URL below I included version 5.5.3:

<script src=
    "https://unpkg.com/faker@5.5.3/dist/faker.min.js">
</script>

There are number of advantages to controlling the version:

• you will have tested your application on a specific version. If you deploy to production and allow the version to change with every new release, then your application may gradually exhibit bugs or incompatibilities over time because you haven't tested your application against the new version of the library.
• when using multiple versions of libraries, future versions may conflict with each other, again causing your application to fail in production and possibly without you noticing.

I import the three libraries I use at specific versions:

<script src="https://unpkg.com/ag-grid-community@26.2.1/dist/ag-grid-community.min.js"></script>
<script src="https://unpkg.com/papaparse@5.3.0/papaparse.min.js"></script>
<script src="https://unpkg.com/faker@5.5.3/dist/faker.min.js"></script>

This puts me in control of the testing and I'm more confident that any bugs in the application will be a result of my coding, rather than an update to a library used in the project.

The different CDNs may have a different syntax for controlling the version numbers. But you will be able to see the format to use by searching for the library on the CDN and following the documentation provided by each CDN.

Here are the listings for AG Grid on each of the CDN sites:

• Unpkg.com - AG Grid
• jsDelivr.com - AG Grid
• cdnjs.com - AG Grid

If you follow the links for the AG Grid packages then you will see that each site has a slightly different interface. But they all allow selecting a specific version of AG Grid and allow you to copy and paste the URL to add to your HTML file.

CDN in Practice

Below is a simple HTML file which will render a Data Grid on the screen.

I only have to deploy the HTML file, because the AG Grid library is loaded into the browser from the CDN.

In the example below I'm loading version 26.2.1 of AG Grid and the CSS files from the unpkg.com CDN.

<!DOCTYPE html>
<html lang="en">
<head>
    <title>CDN Added AG Grid Example</title>
    <script src="https://unpkg.com/ag-grid-community@26.2.1/dist/ag-grid-community.min.nostyle.js"></script>
    <link rel="stylesheet" href="https://unpkg.com/ag-grid-community@26.2.1/dist/styles/ag-grid.css">
    <link rel="stylesheet" href="https://unpkg.com/ag-grid-community@26.2.1/dist/styles/ag-theme-alpine.css">
</head>
<body>

    <div id="myGrid" style="height: 200px; width:500px;" class="ag-theme-alpine"></div>

<script>
document.addEventListener('DOMContentLoaded', () => {

    const columnDefs = [
        { field: "cdn" },
        { field: "url" },
    ];

    const rowData = [
        { cdn: "jsDelivr", url: "https://www.jsdelivr.com"},
        { cdn: "Unpkg", url: "https://Unpkg.com" },
        { cdn: "cdnJS", url: "https://cdnjs.com" }
    ];


    const gridOptions = {
        columnDefs: columnDefs,
        rowData: rowData,
        /* allow manual copy and paste */
        enableCellTextSelection:true,
        ensureDomOrder:true
    };


    const gridDiv = document.querySelector('#myGrid');
    new agGrid.Grid(gridDiv, gridOptions);
});
</script>
</body>
</html>

Unpkg imports are demonstrated in this deployed html page.

I could easily use other CDNs by changing the script and link elements in the head section of my html file.

JSDelivr using version 26.2.1

• https://cdn.jsdelivr.net/npm/ag-grid-community@26.2.1/dist/ag-grid-community.min.noStyle.js
• https://cdn.jsdelivr.net/npm/ag-grid-community@26.2.1/dist/styles/ag-grid.css
• https://cdn.jsdelivr.net/npm/ag-grid-community@26.2.1/dist/styles/ag-theme-alpine.css

JSDelivr imports are demonstrated in this deployed html page.

CdnJS using version 26.2.1. CdnJS takes a slightly different approach to version naming so it is worth checking the version drop down on the cdnJS AG Grid listing

• https://cdnjs.cloudflare.com/ajax/libs/ag-grid/Docs-26.2.0-20211117/ag-grid-community.min.noStyle.min.js
• https://cdnjs.cloudflare.com/ajax/libs/ag-grid/Docs-26.2.0-20211117/styles/ag-grid.min.css
• https://cdnjs.cloudflare.com/ajax/libs/ag-grid/Docs-26.2.0-20211117/styles/ag-theme-alpine.min.css

CdnJS imports are demonstrated in this deployed html page.

Summary

We don't always have to deploy JavaScript libraries to our site along with our HTML files. Instead, we can include them such that they are delivered by a Content Delivery Network.

Many tutorials we follow will show examples of doing this.

If we do import JavaScript or CSS from a CDN we should add the version number of the library that we are using to protect our deployed example from future issues if the library updates.

A good habit to get into is adding the version evern when we follow a tutorial. If we notice that the CDN included files do not have a version, then it is worth visiting the CDN to find out what the current version of the library is. Then you can add that version number to your source.

It is small adjustments like this that will make any portfolio projects you create on Github a little bit more professional.

What is a CDN?

A Content Delivery Network (CDN) helps you deliver your content more quickly. You can serve any type of content that remains unchanged over a period of time, like images, videos, CSS, JavaScript, HTML files, PDFs, and more.

A CDN is a group of servers that are spread across the world to deliver the content from the Edge servers. Edge servers are servers located closest to the place from where the request is being made.

Depending on the request, edge servers may either return the content from its cache or they can fetch it from the Origin Server. The servers that serve the actual content are called Origin servers.

In the above image, the Edge Servers are located around the world and the Origin Server is located in California, USA. When a request is made, the Edge Server located at Mumbai, India may contact the Origin Server if it's not able to serve the content.

How Does a CDN Work?

CDNs have four main parts: a Consumer, a DNS, an Edge Server, and an Origin Server.

When the Consumer makes a request, it is at first accepted by its Internet Service Provider (ISP). The ISP will then hit the content provider's Authoritative DNS.

An Authoritative DNS converts the DNS request to an IP request.

When the Authoritative DNS is made, it returns the IP address of the closest Edge Server. The Edge Server will then check in its own cache to see if the requested content is available.

If it is, then it returns the content. If the content is not available, it requests the content from the Origin Server and on retrieval caches it.

Benefits of a CDN

Low Bandwidth Consumption

Many web hosts have a limited bandwidth allocation per month. If you go beyond that you will be charged extra.

With a CDN most of your bandwidth will be saved since the content will be served by the edge servers.

Low Latency

The Edge Servers cache the content. So anytime cached content is requested the latency is reduced drastically. This is because the request doesn't go all the way to the Origin Server.

Security against DDoS

Almost all the popular CDN's have the capability to protect your webserver against Distributed denial of service (DDos) attacks.

Improves SEO

Loading time is one of the factors that can affect your site's SEO rankings. If you are serving most of your content via CDN, the loading times are drastically reduced and can help improve your SEO.

Deep Dive into Azure CDN

Let's say you have created an Azure Storage Account and hosted a very simple site that displays Hello World as h1. Now that you know the benefits of CDNs, you want to serve your simple site over CDN.

You will have an endpoint like https://demostorageaccountarjav.z29.web.core.windows.net/ (where instead of demostorageaccountarjav it would be your storage account's name). Here are more details on how to setup a static website.

Login to your Azure Portal and click on Create a resource from you dashboard. Search for CDN which will open the resource in the marketplace as below.

Create CDN

This will open up a form to create a CDN profile. A CDN profile is a set of CDN endpoints. There is not much to fill in here except the name, resource group, and the pricing tier.

Next, select the checkbox to create a CDN endpoint. An endpoint is where the Consumer will be requesting content. So if you have multiple sites you can create multiple endpoints as well.

I have attached a screenshot for your reference on what values to put in. Since CDN is a global service the region selection will be disabled.

CDN Details

You can now click on Create to generate the profile and endpoint. It will take a couple of minutes to create. After it is created and when you go to the home screen, you will have these 4 resources:

Azure Resources

As discussed earlier, the CDN Profile is a group of Endpoints. To view the details click the *Endpoint resource. You will see an overview with a link to the Endpoint hostname.

Endpoint Overview

When you open the endpoint hostname it might show "404 not found" initially. You might have to wait another 10-15 minutes before your actual site is visible.

As discussed in the benefits section you can configure the Endpoint for security, caching, routing, and a lot of other things. You can explore more options here.

How to Access via SAS Token

You may be wondering what to do if your resource is in a private container and can only be accessed via a Shared Access Signature (SAS) Token. Well you are in luck! The query strings are passed on as they are and since SAS is as a query string you are good.

Go ahead and create a new storage account (with static website disabled). Add a new Endpoint in the CDN profile that points to the newly created storage account.

For demo purposes I have created a container named site with private access level. And I've uploaded a Blob to it named Photo.jpeg in a Storage Account with the URL https://demostorageaccountarjav.blob.core.windows.net.

You can of course get a SAS token from the Azure portal directly for testing, but that's not how you would usually do in the real world. For that, you'll find below a simple snippet to create a SAS token in Node.js.

const azureSasToken = require('azure-sas-token');

// default token validity is 7 days
let sasToken = azureSasToken.createSharedAccessToken('https://<service namespace>.servicebus.windows.net/<topic name or queue>',
                                '<signature key name>',
                                '<signature hash>');
console.log(`sasToken: ${sasToken}`);

// Specify your own validity in secs, two hours in this example
sasToken = azureSasToken.createSharedAccessToken('https://<service namespace>.servicebus.windows.net/<topic name or queue>',
                                '<signature key name>',
                                '<signature hash>', 
                                60 * 60 * 2);
console.log(`sasToken: ${sasToken}`);

We have used a simple npm package named azure-sas-token. Once the SAS is generated your URL will look something like this:

https://demostorageaccountarjav.blob.core.windows.net/site/Photo.jpeg?sp=r&st=2021-03-25T07:28:45Z&se=2022-02-02T15:28:45Z&spr=https&sv=2020-02-10&sr=b&sig=PD4HlRI8bDEirMevpYQgpx6drwh%2BE5EpILfXkQOMlvw%3D

The above URL is pointing directly to the storage account. So go ahead and change the origin so that it uses the origin endpoint.

https://demowebsitearjav.azureedge.net/site/Photo.jpeg?sp=r&st=2021-03-25T07:28:45Z&se=2022-02-02T15:28:45Z&spr=https&sv=2020-02-10&sr=b&sig=PD4HlRI8bDEirMevpYQgpx6drwh%2BE5EpILfXkQOMlvw%3D

When you visit this site you will now be able to view the protected resource via CDN. You might have to wait a few minutes and/or purge your Endpoint to see the updated content.

Conclusion

In my opinion everyone should be using a Content Delivery Network. There are lots of other providers like Cloudflare, S3, and so on. But Microsoft is one of the major players emerging with a wide variety of services.

If you are an Azure fan like I am, you should definitely give Azure CDN a try.

For any feedback or questions you can get in touch with me.

Check here for more tutorials like this.

I wanted to set up a fun project for myself to learn some new technologies. And this time I decided I wanted to learn a bit about Static Site Generators (SSGs).

My goal was to build a blog using an SSG and have it deploy any time the code repository changed. You can see the result at https://caliburnsecurity.com.

Blog Requirements

Below are the requirements I put together when determining what I wanted my blog to support.

• Support Markdown for content generation
• Syntax highlighting
• Code line numbering
• "Serverless"
• Ready made themes/plugins - I am so NOT a frontend developer
• SEO capabilities
• Browse by keyword/category
• Search support (because this is statically generated, searching is through Google's index - there are other articles that discuss how to add a dynamic JavaScript powered search)
• RSS support
• Version controlled
• Static - no dynamic content (with a neat side effect of shrinking the site's attack surface and improving security)

So what actually is a Static Site Generator?

In short, an SSG is a framework designed to manage your website and transform it into a site serving only static pages.

Why use a SSG to build the blog?

One thing that took me some time to comprehend was why I would use a static site, if I already had a CMS. There were so many articles online about using an SSG with a headless CMS...but why?

Best I can tell, the benefits are simply that you have more flexibility using familiar frameworks such as React or Vue, while using a CMS to handle all content.

However, as I am by no means a frontend developer, I was close to scrapping this project. I thought "Oh well, I should just use Ghost - it's only $5/month if hosted on a platform like DigitalOcean, and is an all-in-one platform to serve content as well as manage the content".

However, I really wanted to try to learn something new, and see if I could just deploy a blog for free using only Markdown.

As always ends up happening, what I was hoping would take a few hours took quite a bit more time as I went down the rabbit hole of research into various technologies.

I played around with several different technologies, such as (not all of these are SSGs, more on that later):

• Pelican (Python)
• Hugo (Go)
• Hexo
• Gridsome (Vue - JS)
• VuePress (Vue - JS)
• Ghost
• Gatsby (React - JS)
• Jekyll (Ruby)

Why I Chose Hugo

I won't go in too much detail on all of the technologies I looked at. But in general, I found Hugo to be super quick to set up and build, and just the SIMPLEST of all the options.

While I know this is similar to Jekyll, I really just didn't want to deal with configuring a Ruby environment, and the speed of Hugo left everything else in the dust.

How to Start Building the Blog

For this exercise, let's build a static blog hosted by Netlify (free!).

Note: I'll be using PowerShell on my Windows box for this tutorial, so please recall that if copy/pasting.

Make sure you have these dependencies:

• Git
• Visual Studio Code (or your preferred editor)
• Hugo binary

Here's a high level overview of our workflow:

1. Download/Install Hugo
2. Create a Hugo project
3. Add and configure a theme
4. Add to Git
5. Deploy to Netlify
6. (Optional) Configure the free Netlify CMS

Download or install Hugo

To install Hugo, I went over to their GitHub Releases page and downloaded their standalone Windows x64 binary. I placed it in my Projects directory, where we will be creating our site (you can always install it properly/add the binary to your PATH, but I wanted quick).

How to Create the Hugo Site

To create a new site, simply run the below commands:

.\hugo.exe new site hugo-blog
mv .\hugo.exe .\hugo-blog
cd .\hugo-blog
.\hugo.exe server -D --gc

We now have our project created, and have just started the Hugo server. We used the -D flag to tell Hugo to show draft content, and I typically add in --gc to ensure that cleanup is run each time by clearing the cache.

You can access your site at http://localhost:1313.

Understanding the directory structure

You should now see the following directory structure:

|__archetypes
|__assets *this will not show up by default
|__config *this will not show up by default
|__content
|__data
|__layouts
|__static
|__themes
|__config.toml

• archetypes: Content template files with pre-configured front matter. We won't really be touching this.
• assets: Store any files processed by Hugo Pipes. This is out of scope for this tutorial.
• config: Optional directory to store configuration files. We won't be doing anything too crazy, so we will just use the default config.toml file.
• content: This is where your content lives - your posts and pages. The top level folders within this directory are treated as a section.
• data: Contains configuration files used by Hugo. I never had a need to touch this directory.
• layouts: Stores partial or full page HTML templates for the site. Anything in here can overwrite a corresponding entry from your theme, allowing you to customize the theme without modifying the theme's actual files.
• static: Store any static content, such as images, CSS, or scripts. Anything in this folder is copied as-is, without any modification or interpretation by Hugo. This is where you will store your media, such as images, for reference in your blog posts.
• themes: The directory where you will install any Hugo themes.
• config.toml: The default site configuration. You can use a separate directory if you want to separate different environments.

How to Add Your First Theme

For this blog, we will use the tale theme for Hugo. Run the following commands from the root of the project:

git submodule add https://github.com/EmielH/tale-hugo.git .\themes\tale

We will NOT be editing any files from the theme, but will make all modifications in the layouts folder discussed above. This will let us always update the submodule to update our theme without worry that we will overwrite any changes we have made.

To initialize the theme, edit the config.toml in your root directory and add the following lines (while also editing the defaults):

# Theme Settings
theme = "tale"
[params]
  Author = "Aaron Katz" # Add the name of the author (this theme only supports one author)
[author]
  name = "Caliburn Security" # Used by the foot copyright

There we go, the theme is now active! (Note that in many cases, themes will require you to copy and paste the theme's theme.toml file into your config.toml)

Go ahead and check out your page – every time you save a file Hugo rebuils the site live.

How to modify theme files

One issue with the current theme is that non-post content will be displayed in the homepage list.

To change this, let's copy the .\themes\tale\layouts\index.html page to .\layouts\index.html.

Once there, replace: {{range (.Paginate .Site.RegularPages).Pages}} with {{ range where .Paginator.Pages "Section" "post" }}. This will ensure only the "post" section will be displayed in the list.

I also wanted to add a brief footer, so go ahead and create a new file at .\layouts\footer.html and add the following code:

<footer>
    <span>
    &copy; <time datetime="{{ now }}">{{ now.Format "2006" }}</time> {{ .Site.Author.name }}
    </span>
</footer>

How to Add Google Analytics

I also wanted to add some Google Analytics to my blog, and I noticed the theme didn't incorporate this functionality.

Luckily, Hugo makes adding analytics extremely simple. Open up the config.toml file and add the following line:

googleAnalytics = "" # The UA-XXX number from Google Analytics

Once the configuration is saved, copy the .\themes\tale\layouts\partial\head.html file to .\layouts\partial\head.html and add the following code right below the head tag:

{{ template "_internal/google_analytics_async.html" . }}

There we go, now we have Google Analytics working. Cool!

How to Write Content

Let's add a nice About page so people know everything there is about me. :)

.\hugo.exe new about.md

To ensure that this page is added to the main menu, add the following line to the page's front matter: menu: main.

Note: To build Hugo, which will generate the content under the .\public folder, simply run .\hugo.exe

What is front matter?

This was a new term for me. Essentially, front matter is just structured metadata for your content.

By default, your template will add the following metadata fields to each page or post you create:

• title
• date
• draft

Other potentially useful front matter elements are:

• description - This allows you to enter a description for the content.
• expiryDate - Set a datetime for when the content should no longer be published.
• keywords - The meta keywords for the content.
• lastmod - The datetime for when the content was last modified (if you are using the enableGitInfo configuration command, this will be automatically set as the last time the file was mofieid in Git)
• markup - When set to "rst", you can use reStructuredText instead of Markdown (this feature is experimental)
• publishDate - Set a date in the future for the content to be displayed.
• slug - The tail of the output URL. Defaults to the filename if not specified.
• summary - The text used when providing a summary of the article. I find this useful if I don't want the first paragraph to appear in the summary, which is the typical default.
• - Use the plural form of the taxonomy index, such as tags or categories.

How to create an archetype for blog posts

Let's go ahead and change the default front matter we see for blog posts. In the archetypes folder, create a new file called posts.md and add the following:

---
title: "{{ replace .Name "-" " " | title }}"
date: {{ .Date }}
draft: true

slug: {{ .File.BaseFileName }} # Will take the filename as the slug. Feel free to change this to any format you like.  I like including this, so that I remind myself I have the option to change if I want.

summary: "" # Remove this if you want Hugo to just use the first 70 (configurable) characters of the post as the summary.
description: ""

# Lists
keywords:
tags:
categories:
---

Now let's do one final build with .\hugo.exe and get ready to configure our Git repository.

How to Configure Git

Time to configure the project for Git:

git init
git remote add origin <YOUR GIT URL>
git push -u origin master

Great, we now have our code stored within our repository, and we are ready for deployment!

How to Deploy Your Blog

Now that we have our site stored in Git, it's time to deploy! Almost done - I'll now show how to deploy to Netlify in under 10 minutes.

First, we need to create the Netlify application (feel free to create an account using any method available):

Next, we need to create the site and tell it where our Git repository is for our Hugo content:

Tell Netlify where your site is located

Select the repository

These can be left at the default settings

Next up, we will set up a custom domain for our site:

Select the custom domain option

Enter your custom domain

You should now see your domain with a message saying to Check DNS configuration. Click on that, and enter the provided DNS record information into whichever service provider manages your DNS records:

Example configuration within my Cloudflare account

Once complete, wait a few minutes for the DNS settings to propagate, and then select Verify DNS configuration:

Behold, your site is now live!

Example of my new blog hosted on Netlify!

Last, we should set up SSL for our site as a best practice. Netlify offers the option to use Let's Encrypt to automatically provision a certificate for your application. To do so, simply select Provision certificate:

Note: It can take quite some time for the certificate to be generated, so just be patient.

Netlify deployment settings

We have one final step before we are truly ready to use Netlify. Unfortunately, the version of Hugo used by Netlify is somewhat outdated by default. However, we can fix this by creating our own configuration for Netlify to follow when deploying our site.

First, create a file called netlify.toml in the root of your repository, and then add the following configuration:

[build]
publish = "public"
command = "hugo --gc --minify"

[context.production.environment]
HUGO_VERSION = "0.74.3"
HUGO_ENV = "production"
HUGO_ENABLEGITINFO = "true"

[context.split1]
command = "hugo --gc --minify --enableGitInfo"

[context.split1.environment]
HUGO_VERSION = "0.74.3"
HUGO_ENV = "production"

[context.deploy-preview]
command = "hugo --gc --minify --buildFuture -b $DEPLOY_PRIME_URL"

[context.deploy-preview.environment]
HUGO_VERSION = "0.74.3"

[context.branch-deploy]
command = "hugo --gc --minify -b $DEPLOY_PRIME_URL"

[context.branch-deploy.environment]
HUGO_VERSION = "0.74.3"

[context.next.environment]
HUGO_ENABLEGITINFO = "true"

All that's left to do is select Deploy site within the Netlify console, and your site is now live on a custom domain with SSL!

Wrapup

Whew! That was a lengthy blog post, but hopefully this shows how quick it is to get up and running with a "serverless" blog. Let's see what I learned :)

What I loved

• Super simple to build, just run hugo serve
• Live reload - make a change, save, and the page will reload
• Just simple in general - I didn't need to deal with grunt, gulp, webpack, or others
• Customizable output formats let you generate your static site, as well as a Google AMP site, JSON files, and so on.
• FAST. Did I mention fast?
• Can be deployed just about anywhere - whether using Netlify (my current choice), Amazon S3 & Cloudfront, Heroku, GitHub Pages, and more.
• Shortcodes are available if Markdown isn't enough
• Continuous deployment - everything is version controlled, and deployed when I publish to the master branch
• Allow commenting and sharing of posts

Challenges

• Hugo is sometimes too simple. No plugins or extensions at all, etc.
• Using Go is less intuitive and the shortcode feels messier than something like Vue
• Not too many themes available, but I expect the library to keep growing, as there is a very active user base

So do I need a CMS?

After all of this, I still had this question in the back of my mind. And the answer is, "it depends".

If I were to incorporate a lot of media, such as images or videos that I need to upload, it would certainly get tedious adding and organizing them all to the images folder in static.

At that point, I would look into a headless CMS such as Ghost, Netlify, or Sanity to manage the content, as long as I could still write my posts using Markdown.

References

• https://medium.com/backticks-tildes/hugo101-getting-started-with-hugo-and-deploying-to-netlify-9a813fe23b94
• https://blog.risingstack.com/static-site-generator-hugo-netlify/
• http://cloudywithachanceofdevops.com/posts/2018/05/17/setting-up-google-analytics-on-hugo/
• https://www.sitepoint.com/premium/books/a-beginner-s-guide-to-creating-a-static-website-with-hugo/read/1

Akamai is one of the world’s leading Content Delivery Network (CDN) providers. Through the Akamai Intelligent Platform many products are offered to aid performance, availability, security, and insight generation.

Other CDNs include Cloudflare, Fastly, MaxCDN, Incapsula, and Rackspace.

Here we will look at what a CDN is, then some specifics around Akamai’s implementation, including:

• The Akamai Intelligent Platform and Edge Servers
• The Akamai Interface and Property Manager
• Routing Performance
• Caching

What is a CDN?

A user request for content on the public Internet may appear simple, connecting to the server holding the content (the ‘content origin’) and returning this to the user, but it is in fact very complex.

Hidden complexity of connecting to the content origin

The connection may need to go through many Internet Service Providers (ISPs), peering points, and data centres, across competing networks, and suffer from no consistently available routes.

Many different device types and bandwidths may be used, from different global locations, with different content types requested.

This can lead to fluctuating speed and availability, security challenges, and little visibility of what is happening between the user and the content origin.

A CDN places more control in the hands of the content provider, and helps improve the end user experience.

It does this by acting as a parallel high-performance network, maintaining its own network of highly-distributed servers. By being dispersed over many physical and network locations, but optimized as one network, more control and reliability exists for user requests.

As a business grows, scaling to meet higher demands on the content origin also has challenges. We will also look at how CDN tools can be used to reduce load on the origin, helping not just improve performance, but also reduce cost by reducing how high the origin must be scaled.

Akamai Intelligent Platform

Akamai maintains a global network of more than 240,000 ‘edge servers’. These are positioned at the ‘edge’ of the Internet, as close to end users as possible. To achieve this many edge servers are even located directly in ISPs, or in mobile data towers, to even greater reduce the latency between connecting to a user’s ISP before moving into the Akamai network.

Akamai network of Edge Servers

When a user makes a request, Akamai dynamically maps this to the closest available edge server. The edge server applies the business rules that the content provider has specified, before using the best available route between all other edge servers within the Akamai network to fetch content from the origin. Business rules are replicated on each edge server.

Any content available and configured to be cached is then cached on the edge server for future requests connecting to that node. We will look at this in more detail later on.

A site is added to Akamai by adding a CNAME record in DNS that points from the hostname, say ‘community.akamai.com’, to an Akamai edge hostname, ‘community.akamai.com.edgekey.net’, where the Akamai controlled edge server mapping takes over to assign the best available edge server. If you ‘dig’ a hostname and see ‘edgekey.net’ then you know Akamai is being used by the content provider.

Entering the Akamai network

Akamai Interface

_Akamai’s [Luna Control Center](https://www.akamai.com/uk/en/solutions/intelligent-platform/control-center/" rel="noopener" target="blank" title=") and Property Manager

Akamai provides a web GUI named the ‘Luna Control Center’, several APIs, and a CLI.

As seen in the Monitor tab, many reporting and analytics tools are available for generating insights at a CDN level. Logs from edge servers are also available on request.

In the Configure tab we will focus on introducing Property Manager, and leave other options for a future post.

A property, sometimes also referred to as a configuration, is the main way to control how edge servers respond to user requests. Properties apply a list of rules to a set of hostnames, and you can only apply one property at a time to any given hostname. Rules are made up of criteria/match conditions and behaviors. An additional example of this will be seen later when looking at caching. Each property’s default rule must specify a valid Content Provider (CP) code to bill and report for the service. Rules are ‘last match wins’.

A Property Manager API (and CLI) exists, with a great glossary of concepts.

When making changes to a property a new version is first created, allowing changes to be made and tested while the previous property remains active. The new version can be first activated on the Akamai staging network, that a developer can point their local machine to run tests against, before activating in production. Production activation takes roughly ten minutes to globally roll out the new version to all edge servers, with a fast fallback option rolling back within minutes.

Route Performance

In addition to providing an ever increasing amount of distributed edge servers, to be able to serve cached content from as close to every user as possible, the route to the content origin can be optimized. In Akamai’s case this is via SureRoute.

SureRoute view of possible routes to the Content Origin

Akamai’s network of servers (a user first connects to the edge server and any subsequent parent to that server) overlays the default route to the origin. The default route may pass between several different ISPs and networks, which may not always peer well with each other. As seen above, a lossy link (or other such degradation) may mean a non-obvious route is the best option.

The best route is found in two steps.

• First, Akamai servers continually run probes against each other, and, at a lower rate, against all Akamai customer’s origins. These are used to calculate and distribute a centralized list of candidate routes between each edge server/origin pairing.
• Secondly, to narrow down these raw candidate routes to a single best option, a static SureRoute test object is placed by each customer at their specific origin of similar size to their average expected content. Races to fetch this object are periodically ran between each edge server and the origin so that a record of that with the lowest latency and/or packet loss rate can be kept up to date.

This means that on every request to an edge server the fastest and most reliable route at that point in time can be used to reach the origin.

Caching

Caching at an edge server can greatly reduce latency for the end user.

As organizations scale caching can also become increasingly important to reduce load on the content origin for both better performance and to reduce costs.

As described in the answer given to “Do Akamai edge servers share cached content”, edge servers are grouped together into network ‘regions’. If a specific edge server’s cache is not populated it will send a local request to the other edge servers in its region and if a peer has content it will serve the response before caching it itself.

If all local peer’s caches are empty (or stale) then the request will be forwarded to the edge’s parent server, where the same local check will take place between the parent’s peers. If no content is cached along the entire route then it will return to the origin and repopulate the cache with its response.

Cache ID Modification behaviours

The standard cache key used is made up of the host name (domain), path and query string. This can be modified to reduce cardinality and/or give more control over cache purging. This may be by only including specific query parameters, so excluding things such as product IDs, adding the values of certain cookies, headers, or user defined variables.

Match conditions (if ‘x’ cookie exists for example) can be combined with ‘bypass cache’ behaviors to create advanced scenarios such as caching different content for users with a session, or for users in different locations.

A browser extension such as ModHeader can be used to view Akamai Pragma Headers for investigating caching behavior locally.

Final thoughts

Using a CDN provides more control to content providers and tools such as those described above provide benefits that are increasingly important when working at scale.

While Akamai specific products have been discussed here, similar concepts of working at scale exist with other CDN providers.

Other Akamai specifics may be covered in a future post, feel free to keep an eye out or read up on suggested next topics such as:

• Security enhancements with certificate management and Web Application Firewalls (WAFs)
• Image manager for optimised image delivery
• Cloudlets to provide granular control outside of the Property Manage activation cycle with many types available for different use cases
• Global Traffic Management (GTM) for DNS-based load balancing
• mPulse for utilising Real User Metrics (RUM) for performance monitoring

Thanks for reading ?

You may also enjoy:

• A beginner’s guide to Amazon’s Elastic Container Service
• How to incrementally add Flow to an existing React app
• Progressive enhancement with CSS Grid