I don’t know if it’s a bug but i recently compressed all my cms assets and all my assets in general because they were using too much bandwith
I did the changes and publish my site, but in my site usage report still showing up the old assets like there’s were not changes at all, it is a bug or i missing something?
Make certain to republish your site.
If you’re still seeing it a few days after a publish, that’s concerning- I understand that compression does not remove the previous assets, it just creates new ones- so a few possibilities;
- it could mean a bug of some kind in the reports
- you might be referencing those assets elsewhere, e.g. an app, an LMS, a support platform. I’ve seen some unusual builds so I never rule this out.
- it could be that you have a “leech” who is using certain assets on another site, and you’re paying the hosting. Without server logs you’re blind to who is accessing them.
I’d probably consider “disconnecting” those old assets- which you should be able to do by cloning your site and them transferring the site plan. The new site will have a new site ID an all new asset URLs, and the old URLs should be shut down.
Webflow makes plan transfer pretty smooth now, however if you’re using 301’s I think you need to export them first, and re-import them on the cloned site.
You’re right i’m working with a client and it has an app that is consuming a RSS from the blog post, i don’t know why but the xml file is using the old assets.
It’s there a way of updating the RSS system or another way of fix this?
Oooh that’s very interesting. I tend to forget about Webflow’s RSS feature, that’s some excellent sleuthing you’ve done there.
It may be an intentional decision by Webflow’s dev team- RSS readers are fairly old-school and might not handle WEBP / AVIF well. The RSS feeds are also often used by external systems, e.g. one of my clients uses it to feed their mobile app. So changing RSS feed behavior would be akin to changing an API.
There isn’t an internal setting to switch what assets it delivers, so… options.
-
You could reverse-proxy it, and change the URLs. Webflow has a nice design in that the compressed images preserve the same basic URL as the uncompressed ones, with only the file extension changing, e.g. x.jpeg becomes x.avif. However you’d have to be extremely strict about your addition of new content, to make certain it’s already uploaded as avifs, or you’d have to recompress your CMS every time you upload a new item to ensure the avif version exists.
-
You could reverse-proxy it, and image-compress/cache those images externally e.g. on Cloudflare. A lot more work on the RP build however the user process can remain unchanged, and they can continue uploading PNGs and JPEGs in their content.
If you are able to change your RSS feed URL, you have some more options…
-
Use a 3rd party RSS aggregator that may cache and modify your RSS rather like I’ve described above. You’d have to research what’s available now. However if users are directly accessing your Webflow RSS, and you’re need that to stay live to inform your aggregator, you’ve got an issue… no way to disconnect those users and force them to update their URLs.
-
Create an entirely new RSS feed, directly from your content. There are tools for this or, e.g. you could use Zapier to add items dynamically to an RSS. The RSS flavor I’ve seen in Zapier’s RSS generator is different, more podcast-friendly. Then disable your Webflow RSS feed. There may still be history out there that, when people open old entires in their cached history, will still hit your JPEGs but it should reduce quickly. Obviously your last post on that feed should be “hey, we’re moving this, update your feed URL…”
IMO #2 is the right engineering choice. It’s the most reliable, configurable, and is resilient to uncompressed assets on new content uploads. But it’s also probably the most technical build.