Recently, I faced an issue where Vercel was giving me a warning that I was almost reaching my free tier limit on "Image Optimization - Transformation". After a few trials and errors, I managed to fix that so that it doesn't exceed my free tier unnecessarily.

In this article, I'll explain what the issues were, how I pinpointed the exact cause, and what options I had for resolving them. I'll also walk you through the approach I ultimately chose and how I managed to fix the problem.

So What Was the Problem?

My current website is running on version 5 (Year 2026), which uses a CDN from Cloudflare R2 Object Storage. It also has massive SEO optimization for both web search and AI search.

You can check out the website directly here: fahimbinamin.com. I'm not sure which version you'll be able to see in the domain when you're visiting the website, but it'll always be the latest version.

As version 5 of my website is a multi-page website, I tried to include everything about me under one platform. I have a lot of writing published in multiple places, and I wanted to add all of the articles under the same platform. But I also wanted to make sure that their canonical URLs worked well. This would help the AI crawler/bot understand the original published URL/source. So I incorporated this feature in the 5th version of my website.

This website uses Next.js and Next's image optimization protocol properly. Currently, the codebase is closed source and you won't be able to access it anywhere. But I've shared a screenshot so that you can have a glimpse of how it looks now.

Anyway, to save money, I like to utilize free resources as effectively as possible. For the CDN, I'm using Cloudflare with R2 object storage. All the media you see on my website (images, PDFs, and so on) comes from Cloudflare R2 object storage. It's running via Vercel.

Everything was going smoothly until yesterday, when I noticed an email from Vercel stating that I was approaching my free tier limit for image optimization.

I opened the usage panel expecting to see my own project images: profile photos, project screenshots, and gallery frames. Instead, almost every source image listed was hosted on freecodecamp.org.

This was confusing for a few seconds because I don't host my images on freeCodeCamp. Then I remembered that I actually link to them!

Table of Contents

I've organized the entire article with sections that can help you jump around if you want or need to read any specific section separately.

• Where These Images Actually Come From

• Confirming the Scope

• Two Ways to Fix This Issue

• Which Solution I Chose

• Doing the Migration

• Why This Is the Better Fix Long-Term

• What I Will Do Differently Next Time

• Conclusion

Where These Images Actually Come From

I have cross-posted a lot of my writing to freeCodeCamp over the years. When I backfilled my articles into this site's blog archive, I kept the article bodies intact, including the <img> tags pointing at freeCodeCamp's and Hashnode's CDNs (as those were the places where the screenshots had always lived).

The blog renderer wraps every inline image in a BlogImage component:

import Image from "next/image";
 
export default function BlogImage({ src, alt, caption }) {
  return (
    <figure>
      <Image src={src} alt={alt} fill sizes="(max-width: 768px) 100vw, 768px" />
      <figcaption>{caption}</figcaption>
    </figure>
  );
}

next/image actually doesn't care whether the src points at your own domain or someone else's. As long as the host is listed in images.remotePatterns in next.config.ts, Next.js will run it through Vercel's Image Optimization pipeline in this step, including fetching the original, resizing it for every breakpoint, re-encoding to AVIF/WebP, and caching the result.

I had added cdn-media-0.freecodecamp.org, www.freecodecamp.org, and cdn.hashnode.com to that allowlist months ago in two separate commits. I did that specifically so those backfilled images would render instead of breaking.

That actually worked for me in this case. But it also meant that every one of those images (and every responsive size Next.js generated from each one) counted against my Vercel account's free-tier Image Optimization quota. I don't want my quota to be spent carelessly, since it resets monthly and I don't control how many times a crawler or a page load re-triggers a size variant.

Confirming the Scope

Before fixing anything, I wanted real numbers instead of a guess. I grepped every post in content/posts/*.mdx for src="..." attributes pointing at the three external hosts:

src="(https://(?:cdn-media-0\.freecodecamp\.org|www\.freecodecamp\.org|cdn\.hashnode\.com)[^"]*)"

That turned up 691 image references across 33 posts: old screenshots from tutorials going back to 2021, everything from disk-partitioning walkthroughs to CUDA setup guides. All of it was being optimized on someone else's dime (mine) instead of being cached once and served flat. That's what was causing the issue earlier.

When I was looking for solutions, I found two ways that could instantly help me fix the issue quickly.

Two Ways to Fix This Issue

Option 1: Stop optimizing them. Pass unoptimized to next/image for any source that isn't my own CDN. Vercel stops touching those requests entirely.

In that case, the browser fetches the image straight from freeCodeCamp, and there's no resizing or AVIF conversion, and zero quota impact. This means that it will be just a small diff that can be done in minutes.

Option 2: Own the images. Download all 691, re-host them on the Cloudflare R2 bucket I already use for every other image on the site, rewrite the src attributes to point at cdn.fahimbinamin.com, and drop the three external hosts from remotePatterns entirely.

Which Solution I Chose

Option 1 was tempting for how little needed to be touched. But it meant permanently giving up responsive sizing and modern formats for a third of my blog archive, and it left the site depending on freeCodeCamp's CDN staying up and those specific URLs never changing.

Option 2 costs more up front but matches how every other image on the site already works. It also keeps the optimization benefit and removes the external dependency completely. So I went with Option 2.

Doing the Migration

Step 1: Download Everything

I wrote a small Node script that walked every post, matched the same three-host regex, and pulled down each unique URL:

const HOST_RE =
  /src="(https:\/\/(?:cdn-media-0\.freecodecamp\.org|www\.freecodecamp\.org|cdn\.hashnode\.com)[^"]*)"/g;
 
// ...for each match, download to downloaded-images/<slug>/<filename>
// and record oldUrl -> "images/writing/<slug>/<filename>" in url-map.json

Files were organized by post slug specifically to avoid collisions, since a lot of these screenshots share generic names like 2022-01-20_18-50.png across completely different tutorials. Lastly, it was a total of 691 downloads with 0 failures, about 105 MB in total.

Step 2: Upload to R2

I restructured the download folder to mirror the target key prefix (images/writing/<slug>/...) and uploaded it to the bucket using CS Browser. R2 exposes an S3-compatible API and a GUI client handles hundreds of nested files more reliably than dragging a folder through the dashboard.

Step 3: Verify Before Touching content

Before rewriting anything, I spot-checked a couple of the newly uploaded URLs:

curl -s -o /dev/null -w "%{http_code}\n" \
  "https://cdn.fahimbinamin.com/images/writing/automount-a-storage-partition-on-startup-in-linux/HDD-Partition.png"
# 200

Step 4: Rewrite the MDX

A second script read url-map.json and replaced every matching src="..." in content/posts/*.mdx with the equivalent cdn.fahimbinamin.com URL:

content = content.replace(HOST_RE, (match, url) => {
  const entry = urlMap[url];
  if (!entry) return match; // left untouched, logged for review
  return `src="${CDN_BASE}/${entry.cdnPath}"`;
});

After the testing, I found out that a total of 33 files changed, 692 replacements (one image was referenced twice in the same post), and 0 were left unmapped.

Step 5: Clean Up the Config

With no more <Image> references to the external hosts, I removed all three from images.remotePatterns in next.config.ts:

// Removed, no longer needed
{ protocol: "https", hostname: "cdn.hashnode.com", pathname: "/**" },
{ protocol: "https", hostname: "cdn-media-0.freecodecamp.org", pathname: "/**" },
{ protocol: "https", hostname: "www.freecodecamp.org", pathname: "/**" },

I ran a full production build afterward. All 43+ blog posts pre-rendered clean, lint passed, and nothing was broken.

Why This Is the Better Fix Long-Term

The quota problem was really a symptom of a smaller mistake: treating a third-party CDN as if it were infrastructure that I controlled. It rendered fine for months, right up until usage crossed a threshold I wasn't watching closely enough.

unoptimized would have made the warning go away without addressing the issue. But I would have kept depending on freeCodeCamp's URLs staying valid indefinitely, with no optimization to show for it either.

Self-hosting means that every image on this site now goes through the same pipeline, and uses the cache rules and CDN, regardless of where the content originally lived. I didn't want anything that could silently break because someone else changed a URL structure.

What I Will Do Differently Next Time

The two remotePatterns entries for freeCodeCamp and Hashnode were each added months apart, each time because a backfilled post's images were broken and adding the host was the fastest fix.

I never asked myself before, "should this actually be hosted here, or should it live on my own CDN from day one?" That question is cheap to ask before backfilling content and expensive to answer after 691 images and 33 posts are already live pointing outward.

I've written that rule down now, so future backfills download and re-host before a single <img> tag ever points off-domain.

Conclusion

Thank you so much for reading all the way through. I hope that this article will help you if you face the same issue in the future.

To get more content like this, you can follow me on LinkedIn and X. You can also check my website and follow me on GitHub if you're into open source and development. If you like to watch programming and technology-related videos, then you can subscribe to my YouTube channel as well.

In recent times, there has been a steady rise in styling tools that you can use to elevate the visual appeal of your websites. Such tools include CSS frameworks, animation libraries, icon libraries, and typography libraries. These tools offer customization flexibility, responsiveness, and consistency.

One awesome thing about these styling tools is that they bundle stylistic effects in a file which you can access via a Content Delivery Network (CDN).

In this article, we’ll be looking extensively at CDNs, how they work, their different hosting methods, the differences between them, their pros and cons, and the best use-cases of the methods for your project.

Let's dive straight into it!

What we’ll cover:

1. What is a CDN?

   • How does a CDN work?

   • Real-world analogy to explain CDNs

2. Why are CDNs Important?

3. Different Ways to Use a CDN

   • Remote Hosted CDN

   • Locally Hosted CDN

   • Hybrid Hosted CDN

4. Conclusion

What is a CDN?

A CDN, or Content Delivery Network, is a system of distributed servers that delivers web content (like images, stylesheets, scripts and other resources) to users, reliably and efficiently.

How does a CDN work?

A CDN’s primary function is to cache and serve both static and dynamic web content to users. It achieves this by using the following:

• Origin Server: This is the main server where all content is originally hosted.

• Edge Servers: These are servers distributed in different geographical locations to serve web content to users closer to them.

• Caching: This is a way of storing content on edge servers to reduce repeated requests to the origin server.

• DNS Routing: This is the mechanism that reroutes users to the nearest edge servers based on their location.

This is what happens when a user clicks on a CDN link:

• If trying to access the resource for the first time, the request hits the origin server.

• The origin server sends the resource to the user as a response and also sends a copy to the edge server located geographically closest to the user.

• The edge server caches the copy.

• When the user wants to access the resources again, the edge server (not the origin server) sends over the cached copy.

Real-World Analogy to Explain CDNs

To further explain how the CDN works, I’ll give an analogy to make it clearer. Imagine having an account with a bank that has its headquarters in New York (origin server).

You don’t expect customers who live far away from New York to be scampering to the headquarters any time they encounter issues. Instead, the bank provides branches (edge servers) in different locations to cater to the needs of their customers. Customers can easily walk into any branch nearest to them and get their issues or transactions sorted.

The branches have every customer's account information and transaction logs (cached data). Every branch of that bank delivers the same services and can satisfy their customers regardless of their distance from the headquarters.

The distribution of branches in different locations helps reduce the traffic that would have caused delays if the bank had just the headquarters as the only option. On contacting the bank's customer service on an issue, you would most likely be redirected to the nearest bank branch to you (DNS Routing)!

Why are CDNs Important?

There are many reasons why CDNs many websites use CDNs these days. Some of the key benefits are:

1. Improved Website Performance: CDNs can compress files and optimize images automatically, which helps speed up load time.

2. Efficient Resource Storage: With CDNs, styling resources are stored and managed properly. Resources are also stored in files matching their content types.

3. Better Search Engine Optimization (SEO): Using CDNs directly speeds up load time which in turn impacts search engine rankings. Google considers site speed a key metric that allows web pages to show up higher in search engines.

4. Better User Experience: Users prefer faster and more responsive websites to slow and unresponsive ones. With a better user experience, a website is sure to receive more engagement and lower bounce rates.

Different Ways to Use a CDN

There are three ways you can access CDN resources in your project:

• Remote Hosting

• Local Hosting

• Hybrid Hosting

Remote Hosted CDN

Remote CDN links allow developers to access styling resources from a third-party server by simply linking to the CDN in their HTML files via the link or script tag.

Bootstrap, for example, has two primary CDN links – one for CSS stylesheet and another for JavaScript (handles dynamic interaction like dropdowns, pop-overs, and so on).

To use a Bootstrap stylesheet in your project, you need to add this single line - https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css

And for the JavaScript: https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/js/bootstrap.bundle.min.js

How to find remote CDN links

The best way to identify thte remote CDN links of your desired styling tool is to visit their official documentation site and look for the direct links there.

Advantages of a remote CDN:

1. Easy to Use: You don’t need to download, manage, or upload files with CDN links. All you need to do is insert a single line of code in your HTML file and you are good to go.

2. Global Caching: whenever you visit a website that uses CDN links, it downloads the resources on loading the page and then saves it in your browser cache. On subsequent visits to the same website or other sites that use the same CDN, it fetches from the cache and displays these resources more quickly. This is one of the biggest advantages of using CDN links, as it improves website load time.

3. Optimized Global Delivery: CDNs are built to deliver content to users around the world by serving files from edge servers closest to users. This helps reduce the time it takes data to transfer across a network, also known as latency, and boosts performance for international users.

4. Reduced Server Load: Due to the CDN fetching data from an external source, the load on your server is reduced, which is helpful for high-traffic websites.

5. Real-Time Updates: Companies that own CDN links carry out periodic bug fixing, security patching, and feature updates, which can be beneficial for your project. These updates are reflected as soon as they are released.

Disadvantages of a remote CDN:

1. Customization Limitations: Styling components in remote CDNs are standard and unmodified. To modify them, you would have to override the specific styles in your local file which can introduce complexities.

2. No Control over Updates: When automatic updates are made, they can cause problems in your web applications. If the changes being introduced include drastic changes, it can affect your website’s layout or behavior in a big way.

3. Dependency on Third-Party Availability: If the CDN service experiences hitches like downtime or slowness, it can lead to broken styles thus, affecting your site’s performance negatively.

4. Privacy and Security Concerns: Links referencing an external source can pose serious security concerns, as they can be used to track users and get vital information. It is important to include only trusted CDN link sources in your web project to avoid breaches.

Locally Hosted CDN

These are CDN resources downloaded from a remote CDN and saved within your project folder or hosted on a local server. This approach allows you to have full control over the resources.

How to host CDN resources locally:

Hosting locally is straightforward and easy. All you have to do is:

• Access the resource by navigating to the CDN link URL (for example, https://cdn.jsdelivr.net/npm/bootstrap@5.3.3/dist/css/bootstrap.min.css).

• Copy the code found in the URL.

• Create a file with the appropriate file extension (.css, .js) within your project folder.

• Paste and save.

• Reference the file in your HTML document.

If you follow these steps, you should be able to localize the CDN resource and access its styling locally.

Advantages of a locally hosted CDN:

1. Full Control over Files: With resources resident within your project folder/server, you’re in full control of your files as there will be no unexpected outages, changes, or updates that might break your site.

2. Offline Availability: Local hosting ensures that your styling resources are always available, especially for users with little or no network. This is perfect for building Progressive Web Applications (PWAs).

3. Customization: There’s be no need for overrides, as your styling can be modified from within your project files.

4. Security: By localizing CDN resources, you reduce the risk of potential third-party attacks on your project to the barest minimum.

Disadvantages of a locally hosted CDN:

1. No Global Caching: There is no benefit of global caching when resources are hosted locally. This will result in slower load time for first-time visitors.

2. Increased Server Load: With files residing locally, the load on the server increases especially as traffic increases. This approach puts a burden on the server and its capacity has to be considered.

3. Manual Updates: While hosting locally gives you control over updates, you’ll need to manually track and apply updates to your stylesheets when necessary. Also, missing security updates could make your site vulnerable.

4. Regional Performance Impact: If your server is located in a specific region, users from faraway places may encounter slower load times because the content has to travel greater distances.

Hybrid Hosted CDN

This approach involves the combination of using both the remote link and local hosting of CDN resources. A hybrid approach – which involves using remote CDNs for core libraries and local hosting for custom stylesheets – may strike the perfect balance between performance and control.

Best Approach to Use

The decision between remote and local hosting of of your CDN styling resources depends on factors such as project performance needs, user base, and security. Your choice should depend on the suitability of the approach to your project and should elevate the performance levels.

Best use-cases for a remote CDN:

1. Global User Base: If your website is to be accessed by a large, globally distributed audience, using the remote option would work best due to its performance and caching advantage.

2. Fast Integration: In a situation where you want to develop and deploy a project in the shortest period of time, using the remote CDN link is quick and easy.

3. Low-Traffic Website: Small projects such as portfolio sites and blogs are better served using a remote CDN link so as not to put a strain on the server. It also leads to easier implementation.

Best use-cases for a locally hosted CDN:

1. High Security Needs: For applications that require tight security due to the sensitivity of their operations, hosting the CDN resources locally will reduce third-party risks and vulnerabilities.

2. Offline Applications: For web applications that work offline, localizing styling resources would be the best option.

3. Customization Requirements: If you need to create your tailored styling versions, hosting them locally is the best option.

Conclusion

In this guide, you’ve learned what a CDN is, how you can host your CDN, and some of the benefits, drawbacks, and best use-cases for each approach.

Remote CDNs provide speed, convenience and reduced server load, while local hosting offers greater control, security, and customization options.

Ultimately, the best approach depends on your specific use case, audience, and priorities.

You can connect with me on LinkedIn or X for more frontend-related posts and articles.

See you on the next one!