Pegasaas
Forum Replies Created
-
Forum: Plugins
In reply to: [Pegasaas Accelerator WP] Test Submission BlockedHello @bhennen
As I have not heard back from you, I cannot investigate this issue further. However, should you wish to reach out to me via our private support channel at https://pegasaas.com/contact/, I would be happy to investigate further.
Kind regards,
Brandon Devnich
Pegasaas.comForum: Reviews
In reply to: [Pegasaas Accelerator WP] Magnifico acelerador[Traducción de Google]
Gracias por tomarse el tiempo para compartir su experiencia.
Me alegra saber que el complemento te ha ayudado a acelerar tu sitio web.
Saludos cordiales,
Brandon Devnich
Pegasaas.comForum: Plugins
In reply to: [Pegasaas Accelerator WP] Test Submission BlockedHello @bhennen!
That can be a tricky issue to circumvent if the server is truly blocking the API from optimizing or returning the optimization.
But, I’m happy to investigate further. For security reasons, please do not share any credentials in this public thread. You can contact me directly through https://pegasaas.com/contact/ with guest administrator access to your WordPress dashboard.
Kind regards,
Brandon Devnich
Pegasaas.comForum: Plugins
In reply to: [Pegasaas Accelerator WP] Page not completed loaded when I’m logged inThis is to summarize what went in to the final solution.
It turns out that when Cloudflare is acting as the global CDN, when Elementor goes to make a change to the /elementor/css/*.css files, those files are not updated in the browser (due to the “expires” header that is passed from Cloudflare). In addition, the resource appeared to be “persistent” in the CDN cache.
The solution had to be multi-faceted.
- all css files for the /elementor/css/ folder needed to have their filenames appended with a unique timestamp
- those css files also need to be cleared from the Cloudflare system through an API call
- we discontinued keeping our own cached copy of the the /elementor/css/*.css files as there was little-to-no transforming of urls or minification performed on this files
We had to employ both #1 and #2 because although the settings in Cloudflare seemed as though they should work with the “Standard” setting, the files were not showing an updated copy with #1 alone or #2 alone.
My thanks to @mnahmed for allowing access to his WordPress dashboard so that I could make repeated small changes to an Elementor page as well as the plugin through the WordPress plugin editor interface. Without this type of access, I don’t know that we would have come up with a solution.
Thank you,
Brandon Devnich
Pegasaas.comForum: Plugins
In reply to: [Pegasaas Accelerator WP] Page not completed loaded when I’m logged inHi @mnahmed
About the only route that I think may resolve this, is if I were to log in to try the same update, and evaluate it in real time, to see what resource is being affected and that is causing it, and see what may be blocking it.
If you’re comfortable with going this route (granting access to the WordPress dashboard), please do not put it in this thread, but instead contact me directly via our website at https://pegasaas.com/contact/
Kind regards,
BrandonForum: Plugins
In reply to: [Pegasaas Accelerator WP] Page not completed loaded when I’m logged inHi @mnahmed,
Ahh, this was my fault. I updated the Pegasaas “Primary” API server, but neglected to push the update to the “Secondary” and “Tertiary” servers. I’ve done that now, re-optimized the page, and the .css files appear to have the cache busting in them. Whether that actually resolves the problem, I would ask that you give it another go and tell me if it works now.
My apologies for all this back and forth.
Brandon
Forum: Plugins
In reply to: [Pegasaas Accelerator WP] Page not completed loaded when I’m logged inHi @mnahmed,
Alright, it looks like it is working when you’re logged in, but the API was skipping over the update.
I’ve tweaked the API and it appears to now be working. I’ve tested it for:
https://www.englishcenterperu.com/clases-particulares-de-ingles/
Can you confirm it is or is not working when you clear the cache now?
Thank you for your patience.
Brandon
Forum: Plugins
In reply to: [Pegasaas Accelerator WP] Page not completed loaded when I’m logged inHi @mnahmed,
Please be advised that I have released v3.1.8 which should address those issues you were experiencing.
Kind regards,
Brandon Devnich
Pegasaas.comForum: Plugins
In reply to: [Pegasaas Accelerator WP] Page not completed loaded when I’m logged inHi @mnahmed,
First of all, thank you for your patience — this is a fairly long thread and I very much appreciate the time you’ve spent in the back and forth of trying to get all the issues sorted.
I decided to get to work on the cache-busting by installing Elementor and run through the process of editing and changing the page.
What I actually found was that the locally optimized .css (which we use to to both minify the css as well as map to optimized images) was not being cleared. I had thought they were being cleared, but it turns out I only thought I had completed that feature.
So, I’ve just completed the preliminary updates that will auto-clear the locally optimized cache files, as well as the browser cache busting I spoke of earlier.
I will complete this update on Monday, and have the patch posted up early/mid next week.
I am confident this will resolve the problem you’ve been experiencing.
Again, thank you for your patience and for sticking with me while I got this nailed down.
All the best,
BrandonForum: Plugins
In reply to: [Pegasaas Accelerator WP] Page not completed loaded when I’m logged inHi @mnahmed,
It depends on how you have incognito configured. By default, I don’t believe it clears the resource cache, it uses a sandbox for the cookies and history. I have mine set to “disable cache” as I do development in it.
When you clear the browser cache, you don’t need to clear the cookies or the history — just the “cached images and files”.
When I viewed your page yesterday, the -80px style was applied, and I had never viewed the page before. However, if you viewed it, and the -80px was not applied, then that indicates a browser-caching situation on the CSS file.
I’ll work on implementing the browser cache busting on Elementor page-####.css files next week.
All the best,
BrandonForum: Plugins
In reply to: [Pegasaas Accelerator WP] Page not completed loaded when I’m logged inHi @mnahmed,
The -80px margin bottom was applied to the the <section id=’home’> via both the critical css that is injected into the page, as well as post-3490.css
The “Critical CSS” snapshot is used to render the page on first render, and then the deferred stylesheets come in later. Now, if post-3490.css has been cached by the web browser, then you may see the previous cache. The plugin is designed to clear the elementor page level .css files when the page is updated, automatically.
I did just check, and it appears as though the .css file has a 24 hour cache time.
We certainly do want to leverage browser caching, so disabling the browser caching is not the route we want to take.
I employ a “browser cache busting” technique with the Premium subscriptions CDN that I think I can apply automatically to those sites that use Elementor (where the stylesheets are rebuilt on page update).
Know that your visitors are getting the latest copy of the stylesheet, however you yourself are seeing the older version. To confirm this, try making a change again, and then clearing your browser cache. If, all of a sudden, you’re seeing the latest version, then I’ll go and implement this ‘cache busting’ mechanism.
Kind regards,
BrandonForum: Plugins
In reply to: [Pegasaas Accelerator WP] Page not completed loaded when I’m logged inHi @mnahmed,
Here is a timeline of what I’m seeing:
06:58 optimization requested to the API, completed and returned to plugin in < 30 seconds
07:00 low priority request submitted to the API, completed and returned in < 30 seconds
07:02 low priority request submitted to the API, completed and returned in < 30 seconds
07:05 low priority request submitted to the API, completed and returned in < 15 seconds
07:22 low priority request submitted to the API, completed and returned in < 15 seconds
07:26 low priority request submitted to the API, completed and returned in < 30 seconds
~07:30 your first message today
07:33 priority optimization requested to the API, completed and returned to plugin in < 30 seconds
07:34 priority optimization requested to the API, completed and returned to plugin in < 30 seconds
07:38 priority optimization requested to the API, completed and returned to plugin in < 30 seconds
~08:00 your second message today
09:00 low priority request submitted to the API, completed and returned in < 30 seconds
09:04 low priority request submitted to the API, completed and returned in < 30 seconds
09:11 low priority request submitted to the API, completed and returned in < 30 seconds
09:16 low priority request submitted to the API, completed and returned in < 30 secondsThe API is most definitely submitting the requests back to the plugin, and quickly at that. We’re getting “success” messages about the cache clearing and the optimizations being saved.
We only keep a cache of the most recent request, so I can’t look back on what was submitted a couple of hours ago. The only thing I can suggest is that if you had another page where you wanted to test this on, and only “update/save” once, and then let me know if it did not update the live version within a minute, then I can look at that.
The critical css that is stored when doing the dynamic optimization is based off of the previous request. So, when you “publish” your changes, it clears the HTML cache, but it temporarily uses the critical css from the previous request. This really only tends to be apparent if the CSS change was made for an area “above the fold”. Anything below the fold gets re-factored based when the stylesheets are later loaded.
The other possibility is that the CSS files may be cached. Generally speaking, Elementor re-builds the CSS files on each save. It could be that the CSS files are stale.
I can start to investigate this type of thing for you, but it goes beyond the level of support that I can feasibly do for non-paid subscriptions. Whatever investigation I do in this type of scenario is done when I can fit it into the cracks after priority support has been managed.
I hope you understand.
If you can make a small change (with padding) on a page that you don’t change often, and then let me know what it is, I will attempt to look at it in our API cache. Please, just save it once.
All the best,
BrandonForum: Plugins
In reply to: [Pegasaas Accelerator WP] Page not completed loaded when I’m logged inHi @mnahmed,
Hmm, hard to tell without investigating.
Can you tell me which page, and which region you had the padding applied? I’d like to check your page and our API cache to see if it’s visible to me.
It may be that the critical css snapshot did not pick up on the padding, or perhaps the CSS is cached.
Kind regards,
BrandonForum: Plugins
In reply to: [Pegasaas Accelerator WP] Page not completed loaded when I’m logged inHi @mnahmed
I just looked, and that image indeed does show for me:
It could be that the image wasn’t immediately available when Cloudflare cached it when you first viewed the page (because it had to be optimized the first time, which can take 5-10 seconds). If it served a broken image back to your browser, it could be that your browser has cached the bad image.
I would first try viewing the image above in your browser directly (the full url I provided).
If the image comes up broken, then try clearing your browser cache.
If that does not resolve it, go to Cloudflare and clear the cloudflare cache.
And if that does not resolve it, let me know.
Kind regards,
Brandon Devnich
Pegasaas.comForum: Plugins
In reply to: [Pegasaas Accelerator WP] Page not completed loaded when I’m logged inHi @mnahmed,
I just did some testing in using our own “expires” settings, and it appears we use a “default” of 14 days. While that’s great, we should probably set the text/html to explicitly “do not cache”.
So, what I’d recommend is changing the SG Optimizer code to “access 0 seconds” from “access plus 6 months”. Really, you should try to allow for some browser caching of the html, however it is unlikely that a user is going to hit the flattened page cache more than once in their session.
The resource hit to the server is negligible when hitting the flattened page cache, so it make more sense to set the browser caching to 0 seconds so that if you do update your page/post, that any visitors browser would re-request it from the server. It’s still very fast, and it means the content is fresh.
So, to be clear, change the SG Optimizer plugin’s setting for:
ExpiresByType text/html “access plus 6 months”
to:
ExpiresByType text/html “access 0 seconds”I’ll add that line, explicitly to our plugin next week, in v3.1.7
