Exploring Netlify Redirects with Phil Hawksworth
Build optimizations from proxying to Cloudinary
Redirects can provide elegant integrations with other services. This example shows how Cloudinary can be used behind the scenes to provide optimized image assets in your site without adding heft to your build process.
- Proxying with named placeholders
- Avoiding DNS-based performance pitfalls
- Avoiding tight-coupling to APIs and services
- Avoiding build bottlenecks by using services like Cloudinary
Now let's look at a use case for redirects with proxies that can help optimize our builds, optimize our sites and make use of third-party services. In this example, we're going to be using Cloudinary to start serving our image assets, and we'll be using their URL-based APIs to streamline what otherwise might be some heavy tasks in our build for a site and for serving optimized images easily.
Let's look at the site that we're going to be exploring. It's one of the most important websites on the web it's petsof.netlify.com and this is a site which the Netlify team add their pets to it's a place that you can find important information and photos of Maximiliano and of Burt Macklin and of Gatto and of Sundance and of Angel and all of these, pets that are the owners of different members of the Netlify team.
Now this is a page. Which grows organically over time. As more people join the company, more people add their photos to this list. And this is the kind of page that could be quite heavy if the assets that are in here weren't all being carefully optimized. The way the site is, managed. If we go and have a look at the code in the GitHub repository, and you can find this as well it's, a public git repo Netlify forward slash pets of Netlify.
It's a site, which is built by a static site generator. We go and have a look at the source here. We'll find that there's a place where there's a bunch of data, which is an array of objects. Each one is just the name of the pets that we want to show and the, file, which is the photo which, shows them. We have a, an images folder with all of the images of all of the pets for the site. Now these are uploaded by all kinds of different people. So this isn't just limited to developers and engineers at Netlify.
So as you might imagine for any content managed site, the assets aren't necessarily all optimized on the site. And in fact we've, decided to not make optimizing the assets part of the build. Instead, we're going to use a different system. So if we go off and let's look at Guff here. So there's a picture of Guff which is Lauire's dog here on the site, the original asset for this. If we go and look at the asset, which is here, we are. This is the original assets. And it's being served on the site, in the images folder, all of those assets and the images folder are being served. This is a two and a half megabyte image. So really we wouldn't want that and other images to be two and a half megabytes in this long page.
So what we're going to do is we're going to optimize those. A very popular way to optimize things would be at build time to get all of the image assets there and run a build script, which resizes, those saves them in an optimized way, shrinks the size of them so they can be save. But we're not going to do that as part of our build in set, we're going to use a third party service to do that for us.
We're going to use Cloudinary. Cloudinary is a service which is all about an image CDN and image transformations. And we'll let them do this heavy lifting for us. This is the dashboard for my Cloudinary account. I'm just on the free tier here. It's, perfectly adequate for my needs here. You can see I've have a bunch of assets in here. In fact, that's going to have a look at this one. This is sourced from pets of Netlify images, guff Laurie. It's the same image we just looked at. And this is. In cloud and re system. And we can in fact go and take a look at the URL that they'll serve it on. So they will serve it from their CDN for us. cloudinary.com is my, account. Image. And then here is the source image that they, used for this, the, they use the pets of netlify.com forward slash images, guff-laurie. That's the image that we're publishing.
Cloudinary offer a fetch API. That's in fact, what this URL is for. It's an image using their fetch API, and this is the source image for it. So by making this request, Cloudinary, we'll go off and fetch the source image from this URL. They'll ingest it. They'll do whatever transformations you might want and then they'll serve it from their CDN. And we can start to to do manipulations on this and transformations right in the URL. So there's a syntax for changing the height of this. So if we say let's make the height 400 They'll resize that catch that version for us, and save it and start serving that four is on this URL. This is a really powerful way of Ingesting assets into a third party doing transformations, and then serving that for us. It would be ideal really to be serving this much smaller, lighter weight assets onto our site than serving all of these at their, original asset sizes.
And that's exactly what we do. So instead of the URLs for all of these assets that we're serving on the page, being images slash the asset name. Instead of that, if we go and look at the view source of this page. We can see actually the URLs that we're using for all of these images are a little bit different. They're forward slash cloudinaried and a number. And then the the asset the, image file name. This is, relative to our domain. But you can see we've got a value in here and the name of the file. What are we doing? How are we getting from there to this URL? We're using something we've used along the way already where using a redirect.
So let's go back and look at our source. Let's look at the Netlify dot toml file. And here we are here. We can see a redirect rule being described. And what we're doing here is we're saying. Any requests to the cloudinaried URL path. We're going to put out a couple of named placeholder parameters. So we're going to have something called height, something called image, and then we'll pass those along to a URL that we want to be rewriting to or proxying to behind the scenes. So we'll use the height that we pull out of the URL to populate that, age, underscore height parameter in the Cloudinary API or pass through the original image, which we're still serving from our domain so that Cloudinary can ingest that and serve that to us.
This means then that with this redirect rule, All of these URLs now work correctly. So we can go and see professor cuddles. We can see cloudinaried forward slash 200 professor cuddles. So that is proxying that through for, us to Cloudinary, we can change. Change the size of that. So, professor cuddles can be hypnotic can be served at whatever size we like. Critically this is not having to do another DNS hop for the user. The user is still connecting to pets of netlify.com. Their browser doesn't have to go and do all of the DNS handshaking, all of the, various bits of the request that can add latency to requests. Instead they're all requesting things directly from the pets of netlify.com domain behind the scenes on Netlify is edge network the proxying is happening to the to the third-party to cloudinary. But then these assets can also be cashed within that CDN.
This means that this page, rather than being made up of lots of very large heavy images can now come down to much smaller optimized images being served without having to go through the steps of a heavy build process.
These are all just done at, execution time and then cashed in the CDN. One of the things to notice is that in addition to our proxy rule in our redirects, we also have this one, we have a 404. So in case that any requests are made to this cloudiaried path that we have, if those aren't satisfied by Cloudinary for whatever reason instead we will use our custom 404 to route that instead to the original image being served from the petsof.Netlify domain. So it means that we have a bit of safety just in case anything should happen here.
So there's another useful way to use redirects. We looked at how we can be proxying to third parties with named placeholders to pull out properties from the URL and pass those along to other APIs and services.
We've seen that we're avoiding DNS-based performance pitfalls there by continuing to expose things to the user on the same domain as the rest of the site. By adding this proxy and this abstraction between the URLs on our site and the third-party services, It means that we avoid any tight coupling between our front-end and the APIs that serve it behind the scenes, we can always change those URLs invisibly to the front end, should we decide to integrate the different services?
And it also means that we can have an asset pipeline with things like image, optimizations that we outsource to other services so that our builds can remain fast and efficient and we can offset the work to other services that are optimized for those.