Okay I apologize for my huge delay. We had a terribly busy month. I'm picking this back up now. Thank you for being so helpful and thorough @adamczajczyk! That's helpful to know the two CDNs are different with different purposes. I wasn't quite sure how that worked. Makes sense now. I suppose we'll give them each a try again separately and see if they work for us yet. I think you were right with the old "et" directory being for Divi. It had been on the server at one point. It's no longer used and so I went ahead and removed the "et" folder as well. No problems. So, I guess that leaves me with just trying to switch up the Elementor print out method for its CSS like you suggested. I'm just puzzled why that didn't used to mess up and but just started recently (in March when I first posted this issue). We never had problems with it in the many months prior. Maybe cause of an update you all did with Hummingbird? Who knows, maybe it isn't the issue anyway. I'll try it and find out. Quick question though: Doesn't changing the print out method for the CSS to be inline / included like that rather than compiling in a separate file make the whole process slower? Maybe it doesn't matter since we're running a caching plugin like Elementor that compresses and caches it all anyway? I don't know. I'm still learning the whole way caching/compressing/combining/gzipping and all that work together.

Okay I apologize for my huge delay. We had a terribly busy month. I'm picking this back up now. Thank you for being so helpful and thorough @adamczajczyk! That's helpful to know the two CDNs are different with different purposes. I wasn't quite sure how that worked. Makes sense now. I suppose we'll give them each a try again separately and see if they work for us yet. I think you were right with the old "et" directory being for Divi. It had been on the server at one point. It's no longer used and so I went ahead and removed the "et" folder as well. No problems. So, I guess that leaves me with just trying to switch up the Elementor print out method for its CSS like you suggested. I'm just puzzled why that didn't used to mess up and but just started recently (in March when I first posted this issue). We never had problems with it in the many months prior. Maybe cause of an update you all did with Hummingbird? Who knows, maybe it isn't the issue anyway. I'll try it and find out. Quick question though: Doesn't changing the print out method for the CSS to be inline / included like that rather than compiling in a separate file make the whole process slower? Maybe it doesn't matter since we're running a caching plugin like Elementor that compresses and caches it all anyway? I don't know. I'm still learning the whole way caching/compressing/combining/gzipping and all that work together.

Okay I apologize for my huge delay. We had a terribly busy month. I'm picking this back up now. Thank you for being so helpful and thorough @adamczajczyk! That's helpful to know the two CDNs are different with different purposes. I wasn't quite sure how that worked. Makes sense now. I suppose we'll give them each a try again separately and see if they work for us yet. I think you were right with the old "et" directory being for Divi. It had been on the server at one point. It's no longer used and so I went ahead and removed the "et" folder as well. No problems. So, I guess that leaves me with just trying to switch up the Elementor print out method for its CSS like you suggested. I'm just puzzled why that didn't used to mess up and but just started recently (in March when I first posted this issue). We never had problems with it in the many months prior. Maybe cause of an update you all did with Hummingbird? Who knows, maybe it isn't the issue anyway. I'll try it and find out. Quick question though: Doesn't changing the print out method for the CSS to be inline / included like that rather than compiling in a separate file make the whole process slower? Maybe it doesn't matter since we're running a caching plugin like Elementor that compresses and caches it all anyway? I don't know. I'm still learning the whole way caching/compressing/combining/gzipping and all that work together.

Okay I apologize for my huge delay. We had a terribly busy month. I'm picking this back up now. Thank you for being so helpful and thorough @adamczajczyk! That's helpful to know the two CDNs are different with different purposes. I wasn't quite sure how that worked. Makes sense now. I suppose we'll give them each a try again separately and see if they work for us yet. I think you were right with the old "et" directory being for Divi. It had been on the server at one point. It's no longer used and so I went ahead and removed the "et" folder as well. No problems. So, I guess that leaves me with just trying to switch up the Elementor print out method for its CSS like you suggested. I'm just puzzled why that didn't used to mess up and but just started recently (in March when I first posted this issue). We never had problems with it in the many months prior. Maybe cause of an update you all did with Hummingbird? Who knows, maybe it isn't the issue anyway. I'll try it and find out. Quick question though: Doesn't changing the print out method for the CSS to be inline / included like that rather than compiling in a separate file make the whole process slower? Maybe it doesn't matter since we're running a caching plugin like Elementor that compresses and caches it all anyway? I don't know. I'm still learning the whole way caching/compressing/combining/gzipping and all that work together.

Hello Adam Czajczyk Thanks for the thorough response. Really appreciate it. I've pondered if there's a server side caching in place as well. I didn't think there was, but I went ahead and double checked things to see for sure. I asked the Support with A2 and they said there's not either. They offer it as a plugin which we do not have installed (wish our last host would have done it this way). Anyway, there is no other caching mechanism in place besides Hummingbird then... apart from something maybe Elementor is doing. The weird thing though is the file that Hummingbird kept pulling back up that we deleted was the exact same file, as in, even the same long gibberish file name. Not just a new file, compiled with the old files, but the exact same file name as the one we deleted and emptied. Almost as if it was caching the cache or something weird. But again, where would it be storing these duplicates? Would there be any strange conflict with the new CDN? We had it on for a while but a bunch of our users lost their images on their site so I shut that off (future support ticket, cause we want to use the CDN). But I pondered if there's something still affecting the site now from that? Other question just for certainty: (A. Hummingbird creates the wphb-cache folder in our directory structure, right? We have another one on the same level simply called "cache" and it contains a folder called "et" which contains multiple more number directories that all seem to be empty. It may be left over from our old server, or maybe it's Elementor. If it's not Hummingbird, I'm going to delete it. I don't think it was the problem though as they're all empty. Thanks for your help!

Hello Predrag Dubajic Thanks for your quick help with this. A message has been sent to you with all the info you requested using the form you gave. Please let me know what you do and when you're finished / what we need to do next. Thanks so much for your help!

Update: I've had to turn this off for now because it simply isn't working. It doesn't matter how many times we dump the cache and recheck the files, it isn't updating. We manually delete the files ourselves from the server, and it still somehow comes back with old ones from who knows where. What is going on!? Where is it even loading those from?