Hi, we are facing performance issues with addressables that are linked to the shaders. We have custom hierarchical structure of models in our scene. The lowest HLODs are always present in the scene, so they are not in any addressable groups. Higher HLODs and their appropriate LODs are streamed based on proximity. All the models are using the same shaders with the same variants. However when the models are added to addressables then the shader is inserted in the group as well. Once the model from the addressable group is loaded there is massive stall due to the Shader.Parse() (even though the shader is already present due to scenes objects with the same shader). After that the shader takes up to multiple GB in the RAM. Without addressables all the shaders occupies around 50-60MB, but with addressables this ramps up to something like 4-5GB (this behavior is only present in standalone build or when play mode script is set to Use existing builds) After reading multiple forums and posts about addressables I have come to the understanding that addressables don't know what is going to be available once loaded and therefor the shaders and other stuff has to be included as well. Based on that we have tried adding the shaders to the always included list, but this does nothing and the problem persists. After trying multiple workarounds the only solution that is currently working is to create standalone addressable group just for shaders and shader collection referencing them. During build we are injecting our custom shader processor that strips the shaders based on predefined variants. During the game initialization all the addressable shaders are loaded and then pre-warmed. This solution is working, there is no hiccup due to the Shader.Parsing and there is no memory penalization however it is extremely inpractical, because we have to go through all the shaders and manually determined all the variants in order this to work properly.