Please read! Deprecation of post-processing asset optimization

[kito]

On October 17, 2023, the built-in asset optimization feature will be at end of service.

Netlify’s post-processing asset optimization feature bundles and minifies CSS and JavaScript, and compresses images during build time. We understand that these capabilities have been valuable to many of our users, and we apologize for any inconvenience this change may cause. However, we believe that this change will enable us to focus on providing you with an even better experience in other areas.

Timeline

To help smooth the transition, we will be doing a phased approach for this feature removal.

• As of today, July 17, 2023, the feature is deprecated. We’ll show a deprecation notice in the logs for new deploys of affected sites.
• On August 24, 2023, new sites will not be able to use the asset optimization feature.
• On September 19, 2023, we’ll disable mixed content detection and the related GitHub checks.
• On October 17, 2023, the feature will be at end of service. We’ll no longer run asset optimization for new deploys, and any related settings will be removed from the Netlify UI. Any related configuration settings in netlify.toml will be ignored.

How do I know if I’m using this feature?

Asset optimization is disabled by default. However, if you’re not sure whether your site uses this feature, you can check in a few places:

• Look for the warning icon next to your site name on the Netlify UI.
• Your site configuration. Go to Site configuration > Build & deploy > Post processing > Asset optimization.
• Your netlify.toml. Check for any [build.processing] settings.
• Your deploy logs. The next time you deploy your site, check for a log line that says: DEPRECATION NOTICE: Your site has asset optimization enabled. This feature will be at end of service on October 17, 2023.

What will happen to my site after asset optimization is removed?

After October 17, 2023, Netlify will still build and serve your site.

However, we won’t run the optimization step on new builds and, as a result, we will serve the original assets. Since asset optimization is just an optimization, all functionality of your site should still work. But, users might experience slower load times because they’ll need to download more and/or bigger files.

For older deploys of sites that had this feature enabled, we’ll keep serving the optimized assets.

How can I run a test build without asset optimization?

You can run a test build without changing your site configuration by creating a branch and updating your netlify.toml file to include:

[build.processing]
  skip_processing = true

This way, you can verify the impact on a Deploy Preview or Branch Deploy before merging your changes to your production branch.

You can be more specific by disabling a different part of the optimization post-processing, as mentioned in the docs. This way you can test and configure options for JavaScript, CSS, and images individually.

What are my options?

Most modern site generators and frontend build tools provide their own way of optimizing assets, so it’s likely that your framework of choice already provides an alternative for this. We recommend you look at their docs and community to find out the recommended option.

If your framework doesn’t provide an alternative, consider using dedicated bundling tools like webpack, Parcel, or Rollup to manage and optimize your JavaScript and CSS files before deploying them to Netlify. You can also consider an image optimization service, such as Netlify Image CDN, Cloudinary, or Imgix, to help optimize images for web delivery. These services often offer other advanced features like lazy loading, responsive images, and automatic format selection.

We understand that each project has unique requirements, and there isn’t a single solution that will work for everybody. If you have any other questions along the way, let us know!

[net-user]

When I disable asset optimization, pretty URLs does not work (despite being enabled):
.html is not removed

With asset optimization enabled and everything deselected, pretty URLs works:

Can you reproduce this bug?
Setting pretty URLs should be independent of asset optimization as it has become a separate setting.
Thanks in advance for fixing!

[eduazy]

Honestly, it doesn’t make any sense to remove these useful features. You’re not providing a valid explanation either.

[davidsneighbour]

This decision makes sense but is too sad

Could you (@kito) explain, please, if this has any influence on plugins like image-optim-build-plugin, which we might use as a replacement for post-processing images for instance? The mentioned image processing options in most SSGs I know do not optimize file sizes (smushing, EXIF-removal, etc.). The way I understand the announcement, those aren’t impacted.

[hrishikesh]

@davidsneighbour, build plugins won’t be affected.

@net-user thank you for flagging. I’ll pass this on.

[adamdjbrett]

I am saddened and disappointed to learn that built-in asset optimization is ending. This is now the second mission-critical feature I will e losing at Netlify. I strongly encourage you to please revisit and keep this feature. Thank you.

[fool]

Hey Adam! Is there some reason you wouldn’t want to move to your own control of this feature? Our built-in feature is not tunable at all by you (e.g. to optimize some files and not others, or adjust how things are minified and bundled), is not perfect (there are many known bugs, including causing your deploy to fail completely if you reference a missing file you refer to in your CSS files), and finally - has not been updated in years. In the end: using something like webpack will give much better results!

If that isn’t possible for your codebase for some reason, could you explain more about why that is?

[asunapg]

Bumping the pretty URLs error. Even while enabled, it’s still showing the non-pretty links (index.html, etc.).

[fool]

Thanks @asunapg for the reminder - we are working on a dev team with the escalation there. Obviously for now you can leave asset optimization enabled so your site isn’t broken in the meantime.

[adamdjbrett]

Because I am new to SSG’s and I like having a set it and forget it post compiling optimization, which for me just works. I’m using Jekyll and the jekyll-webpack plugin I explored using is 3 years old and gave me errors. Now I feel embarrassed for even asking or voicing my concerns on this thread.

[fool]

Thanks for the report around the problems enabling pretty URL’s without asset optimization enabled - Dev team is working on a fix for us, but it will likely not land til next week, so in the meantime to use Pretty URL’s:

• leave asset optimization enabled
• turn off all features in that config section otherwise
• leave pretty URL’s enabled
• and redeploy

…and you should be unblocked for now. We’ll follow up here when you can turn off asset optimization but leave Pretty URL’s enabled, which will happen in the next couple of weeks.

[fool]

I do apologize for giving you the impression you should be embarrassed or were doing something dumb, Adam - that is not the case! As a solutions-focused nerd myself, it feels there is a much better solution available already - so it seemed like everyone would want to be using the better solution.

I do understand it doesn’t fit your 0-effort use case, and am sorry that it will cause you undue effort, but I do still assert that the results will be better if you migrate, even if it takes a bit of effort.

As a mitigation for the situation you and other customers are in, I’ll work with my team to write a Support Guide on alternative tools to achieve the same goals with minimal effort and link it here when ready.

[asunapg]

That worked. I’d propose a “re-deploy” button in some cases. Rather then needing to upload a file again.

[adamdjbrett]

I guess this is another reason to move away from Jekyll and adapt 11ty.
Thank you for your response and time.

[cletchroots]

So it sounds like right now pretty URLs are part of asset optimization, but in the future when asset optimization goes away we will still be able to use pretty URLs. Is that correct or should we start finding our own custom solutions for pretty URLs?

[erick.booth]

A shocking announcement, but you’re right, this encourages developers to get informed about and take control of their own asset optimization. As said, there’s plenty of bundling tools like Webpack, Babel and Parcel already integrated into many frameworks, so if this change will truly help allocate resources and attention to other Netlify services, then it’s a thumbs up from me!

[hellosarah]

A support guide will be much appreciated.

I echo @adamdjbrett’s dissapointment. For me, the set it/forget it feature significantly contributed to Netlify’s low barrier to entry. Which in turn allows me to facilitate projects with contributors across a greater spectrum of skill levels.

*Example: Less moving pieces while working with others who don’t have significant, if any, experience beyond a platform like Shopify. *

[adamdjbrett]

Thank you @hellosarah. I agree a support guide would be especially helpful for Jekyll and 11ty.

[hrishikesh]

A question for all:

If I (on a personal-level, not something from Netlify), were to create a build plugin to handle asset optimization, would that be an acceptable solution? If yes, what would be the features you’d be mostly interested in?

Not making any promises, but I just took a basic shot at it today and have a basic working ready. It’s in very early stages though, so it’s hardly ironed-out or tested. Thus, collecting ideas right now.

[biruwon]

Hi everyone,

The problem about pretty URLs being coupled to asset optimisation should be solved now. Please, try it and let us know if you find any problems!