I want to reverse proxy a webflow site

Webflow have their own CDN which is horribly slow.

We’d like to use a CDN to speed up our site, however only the html responses are served from the primary domain, all images css and js are served from a third-party domain, e.g. https://cdn.prod.website-files.com.

As it’s webflow, we don’t have code level access to modify the static files it produces.

Is it possible to cache our entire website in fastly, but with the HTML, CSS and JS rewritten to remove the third-party domains (e.g. https://cdn.prod.website-files.com) so that the images, js and css can also be served from fastly’s cache?

If it is possible, please could you outline the steps?

Am posting it in “compute” because I imagine that’s the way - but if there is a simpler way I’d love to hear it!

many thanks

1 Like

This may be possible, but it depends on Webflow’s flexibility around the asset URL path within their applications.

At a high level, proxying an asset host in the following architecture is easy:

www.example.com -> Fastly -> cdn.prod.website-files.com

We can rewrite the Host header (or other auth systems) going to the origin so the assets are proxied and cached like you’d expect. It’s the same flow for proxying any HTTP origin for other files as well.

However, if webflow’s application logic forces you to use their CDN domain for assets, they’ll still pull directly from their systems regardless of the logic you put in place at a CDN or edge system.

If they support using a vanity domain for assets, that’s a good sign that this is possible.


If standard proxying and rewriting headers isn’t enough to work out of the box, there may be some other options within Compute to rewrite the Webflow logic itself within Fastly, but that would introduce a significant increase in your overall application complexity, so I’d be careful trying that first.


Alternatively, using Fastly to proxy the HTML and dynamic content via your vanity domain IS easy and likely would result in some general UX and performance improvements, even if assets are still slower.

Thanks for your advice. Webflow doesn’t allow use of a vanity domain for assets, so the contents refering to assets (mostly from html) would need to be modified before pushing into fastly’s cache.

It’s the assets that are impacting perrformance, not the “first file” html page.

Cloudflare does this using a “worker”. I’m hoping there’s a similar approach here.

thanks