Hummingbird Asset Optimization Keeps Reverting Back To Old Files

I'm running into a really frustrating experience with Hummingbird. We rolled out a new single post template layout using Elementor Pro. We had to change some things in the child theme CSS file that was overwriting some stuff in the new design using Elementor. I made the change and then cleared the site cache via Hummingbird > Caching. Nothing changed. So I went to Hummingbird > Asset Optimization (which, by the way, I'm still unclear as to why these are two separate areas), and then I cleared the cache from there. Nothing changed.

I could see in Chrome's Inspector that the problem was Hummingbird's cached CSS file, so I went in via FTP and just deleted the file. Still nothing changed and so then I was super confused! Finally, in desperation and just guessing, I clicked the Re-Check Files button in Asset Optimization. This finally made the whole site start using the newer CSS file from the child theme and everything started working.

After hours of work, and still confused, I went to bed last night. Today I checked the site, thinking I'd share with the client how it's all updated and looking nice, and found everything had reverted back to the old files again and was looking terrible again! :tired_face:

So, I'm completely at a loss. What is happening!? How in the world could that even happen? I must be really misunderstanding something about Hummingbird and the way it works or there's a serious bug at work here. It's making me think I'm crazy and it's pretty frustrating. Please help!

  • Riley with SOZO.DO
    • Webprenuer

    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?

  • Adam Czajczyk
    • Support Gorilla

    Hello Riley with SOZO.DO

    I hope you'r well today and thank you for your question!

    Issues of that kind usually happen when there's some sort of "cache overlap". That's not a "scientific term" but what I mean by this is a case when there's either some server-side cache or additional cache from some plugin or even the theme in addition to a "main" cache (may it be Hummingbird's "Page Cache" or W3 Total Cache or any other).

    In case of Elementor there's a setting for how the styles should be included into the site (on "Settings -> Advanced" page of Elementor configuration). If it's set to print out styles to external file what happens is that Elementor creates a file containing all the styles - whenever you change some layout/visual aspects of the site with Elementor, such file gets created.

    A CSS file is actually an "asset" but since Hummingbird already optimized these assets, the change is not visible. Depending on "what Elementor did" to the CSS files that it generated - whether it only updated existing files or created/added new ones - simply clearing cache may be enough but it might also be necessary to re-check asset optimization files to let Hummingbird discover new files and properly handle them.

    However, if there's some additional cache working on site - usually that's a server-side cache - this makes thing a bit more complex as "cached assets are cached"; that's redundant and can cause some "mess". I can see that you're hosting with A2 host and as far as I remember they do provide some server-side caching but whether it's used in case of your site or not, I have no way of knowing as I don't have any access to your hosting.

    That being said, there's also an issue with Hummingbird working with Elementor set to output styles to external files. Our developers are aware of this and there'll be additional "compatibility layers' added to the plugin in future. For now, please give this solution a try:

    1) check the host to see if there's any server-side cache enabled; if it is please clear it there (if possible, disable it too)

    2) then in Elementor settings in "Advanced" section switch the way the CSS is printed out from "External File" to the other (I believe it's "Include") option.

    3) enable Asset Optimization back, make it re-check files (and make adjustments to configuration if necessary), then clear Hummingbird caches by going to "Hummingbird -> Dashboard" page and clicking "Clear cache" button there

    If there's no interference form other caches or no other plugin is affecting/altering CSS that should help in most cases and whenever a layout change is done it should suffice then to clear HB cache after that from the "Hummingbird -> Dashboard" page (specifically this page as it clears Page Caching and internal asset optimization cache in one go).

    Kind regards,
    Adam

  • Riley with SOZO.DO
    • Webprenuer

    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!

  • Adam Czajczyk
    • Support Gorilla

    Hello Riley with SOZO.DO

    Thank you for getting back to me and I'm sorry for the late response.

    It's good to know that there's currently no A2-side cache as we can rule that out now.

    What you said about HB pulling the same file again and again though still suggests, as you also already mentioned, some "cache caching". Hummingbird itself shouldn't be doing that (it's "internally coherent" so to say) and that same goes to both CDNs: the WPMU DEV CDN for Asset Optimization and Smush CDN. Please not: they are not "the same" - while they are both CDNs they are separate and Smush CDN is only for images, it will not affect JS/CSS files. Those would only be affected by WPMU DEV CDN that you can enable in "Asset Optimization" settings.

    As for images being lost. We've been experiencing some temporary issues with our API recently so maybe that was the reason for that behavior after you enabled Smush CDN? It might be worth to give it another try but if it's still an issue - that would need to be investigated and troubleshooted separately.

    Getting back to the Hummingbird issue though: that additional "cache" folder containing "et" folder would most likely be a cache created by some theme from Elegant Themes (such as e.g. Divi, Extra or their other themes). If you're not using any of their themes, I think you might safely remove it - in fact any cache could, in theory, be safely removed and it would be re-generated if necessary. But that's "theory" and in practice it's difficult to predict. However, in this case I think you might give it a go. If there's currently no theme from Elegant Themes active that shouldn't make any difference as it shouldn't be in use but it's worth checking (just in case: you could first download or zip that folder to keep a backup of it before removing it, so you could restore it if necessary).

    Also, have you already tried the solution with switching the way Elementor prints out CSS from "external file" to "include"?

    Best regards,
    Adam

  • Riley with SOZO.DO
    • Webprenuer

    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.

  • Riley with SOZO.DO
    • Webprenuer

    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.

  • Riley with SOZO.DO
    • Webprenuer

    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.

  • Riley with SOZO.DO
    • Webprenuer

    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.

  • Predrag Dubajic
    • Support

    Hi Riley,

    In the past, it was better to have a separate file for CSS but since the performance test have changed how they rate the page it's better to have the critical CSS loaded inline.
    This way the speed test (and users of course) will have basic look loaded sooner while the rest of the files are being loaded in the browser, and that will give you better results overall.

    Best regards,
    Predrag

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.