With the launch of our new Site Tools-based infrastructure we have opened a wide range of opportunities to further improve the loading speed of the websites hosted on our servers. The first change we have already introduced to everyone using Site Tools is the replacement of the Static Cache with a new NGINX Direct Delivery. We no longer serve images, CSS, JS files, and other static content from the server memory, but we use NGINX for direct loading of these files from the SSD instead. This improves browser caching for your site and also makes CDN usage easier and more efficient. Most importantly, NGINX Direct Delivery allows more RAM space to be used for dynamic content caching, without compromising on static content loading speed.
What is NGINX Direct Delivery?
This is a method to serve static content of your website using the try_files functionality of NGINX. It allows us to remove the static content from the server memory, but still find it and serve it super fast directly from the NGINX, skipping the communication with the Apache web server.
What are the benefits of NGINX Direct Delivery?
Standard caching headers for better browser and CDN caching
With the NGINX Direct Delivery we started serving standard caching headers for static files. This optimizes the way your site is using the browser caching and CDN caching. In our previous Static Cache setup you had to use the SiteGround Optimizer WordPress plugin or number of .htaccess rules in order to properly configure browser cache. Now this is all set for you and you don’t need to do anything. We’ve configured the periods for which browsers will cache static content by the official Google guidelines and we communicate them with the headers. With the Static Cache, CDN servers sometimes failed to detect that a static resource is modified. Now, since we provide all the necessary standard headers, you don’t need to do any additional configuration for your CDN – it will properly get static resources and their modified dates and flush cache when needed.
Using server memory more efficiently
Probably the most important benefit of the implementation of the NGINX Direct Delivery is the fact that we have managed to free up a lot of server memory to store dynamic content. With the previous Static Cache setup we used to store a lot of static files in the RAM, which did make their loading fast. However, for your overall website speed it is optimal to use the RAM as much as possible for caching dynamic content. Now, with NGINX Direct Delivery, we have the option to serve static content super fast from the SSD. Thus, we can store more dynamic content in the RAM and for longer periods too. This has greatly increased our global dynamic-to-cache hit ratio, which means that sites using our dynamic cache option have been loaded in the fastest possible way for much more visitors than before.
The introduction of NGINX Direct Delivery is just the first step in an elaborate plan to make our clients’ website load faster than ever before. Stay tuned for the other exciting loading speed improvements news to be published shortly.
[subscribe_cta]
Hi Hristo,
Thank you for your topic.
I have today the 3 levels of cache activated on my websites (Level 1: Static Cache, Level 2: Dynamic Cache, Level 3: Memcached).
Is there anything I have to do to optimize my cache with your NGINX Direct Delivery ?
Thanks for ay advice 🙂
Not really, NGINX direct delivery will substitute your Static Cache without the need of any reconfigurations.
Are you bringing back Google page speed?
No, the current setup and what we have in hand for future updates provide much better performance.
Awesome! Will this be available on Cloud Hosting that use cPanel eventually?
Yes, once we migrate our cloud servers, direct delivery will be available for all.
When the migration for cloud servers is planned?
Migrations are being currently performed and will be completed in the next few months. You are going to receive an email before the actual date for your server’s migration.
Is this the migration that has been promised since September?
Yes. We will soon initiate them, please be patient just a little more 🙂
Looking forward to seeing this in action. SiteGround has been doing a smashing job at making performance improvements and of course fantastic support.
“…you had to use the SG Optimizer WordPress plugin or number of .htaccess rules”.
As someone who uses the SG WordPress plugin will there be recommendations to .htaccess rules for the new configuration? For example right now the plugin appends:
# Leverage Browser Caching by SG-Optimizer
ExpiresActive on
ExpiresDefault “access plus 6 months”
# CSS
ExpiresByType text/css “access plus 1 year”
# HTML components (HTCs)
ExpiresByType text/x-component “access plus 2 months”
…
Those rules will remain the same but on server level and the .htaccess lines generated by the plugin will be cleaned automatically.
So on SG sites/servers that are already running into file IO limits this will end up being a downgrade?
Our IO limits are set super high so if your account is reaching it, I’d recommend opening a ticket in your Help Desk so we can tell you what’s causing it.
Does NGINX Direct Delivery automatically replace static cache or do I have to do something?
Yes, it will replace it automatically without you having to do anything.
Is this effective immediately, or is there a way to tell through cPanel? I have manual expires headers I’ve added to my htaccess – should I remove them, and if so, when? Many thanks
It’s available in Site Tools. For existing clients who still use cPanel, it will be available after their migration to Site Tools. It won’t be necessary to remove manual expires headers, but they will also have no effect, since static content will be delivered directly from Nginx. Rules related to redirect, rewrites, which are not static content, will still work.
I assume this improvement is for the new client area only?
I still have the old cPanel interface. Could you give an update about the progress of the migration?
“Current customers who are using cPanel and the old User Area will be gradually switched to the new interfaces starting in September.”
Yes, it is available in the new Site Tools. We are migrating gradually existing customers and expect to complete all migrations within the next months. Everyone will receive an email with additional information before the migration of their account, so keep an eye on your Inbox.
Hi, great article. And good work for you guys staying on top of speed. When is this rolling for all websites? Is there like a batch where some clients get rolled out once or this something that happens at once for everyone?
It is available for all accounts on Site Tools 🙂
Hi is there any way to disable this on my site? This is causing me some trouble.
Problem is once user has login, he is redirected to the candidate dashboard. Then when user clicks on homepage the signin button is displayed again but the user is already logged in. And once i refresh the page the signin button is not there.
Its this cache causing trouble.
It shouldn’t be, I would love to learn more about your issues at hristo.p [at] siteground.com so we can make it better. Meanwhile, you can disable it from Site Tools -> Speed -> Caching.
You might need to request a new page after login and not rely on cache.
https://stackoverflow.com/questions/2405117/difference-between-window-location-href-window-location-href-and-window-location.
What is the difference between JavaScript’s
window.location.href = window.location.href
and
window.location.reload()
functions?
Does that work for all your plans?
Yes, it is available on all Site Tools plans. If you’re still on cPanel, you will have to wait until your server is up for migration.
What is your recommendation for leveraging browser caching for 3rd party resources?
Hello, unfortunately, webmasters don’t have much control over the caching of 3rd party resources. What some users do is to download these resources locally and use a cron to update the scripts from time to time.
But even if you don’t do that, keep in mind that it is very unlikely for Google to penalize you if their own tools like Google Analytics or Tag Manager are not optimized for speed.
Is it possible to disable it for a website? I have been working with support but we have not found a solution.
Since the switch, browsers do not detect when new comments are added contrary to before. One of my sites is a funeral home and the WordPress comments function is used for people to enter condolence messages. This causes returning visitors not to see new comments unless they know to hit reload at the top of the page. Previously, with static cache, the browser knew there was new content and would force a reload of the page.
I would appreciate if one of the top support reps for caching can contact me to look into it 🙂 I can provide the Helpdesk ticket number in private.
I wish we could have the option of keeping the old caching method for some sites.
Hello Eric, the NGINX Direct Delivery is available for clients who are already using Site Tools. Your account is still using cPanel, thus the observed behavior cannot be caused by this. Please check today’s reply by our Support team in your Help Desk.
my audio uploads aren’t playing anymore since this update, what is the problem and can l rectify it. l have tried about four means to get it done but still. Please reply
Hi, please post a ticket to our Support team, so they can check and help you further.
Yea
Hi there, will Siteground also add features for Magento optimization in 2020? I see lots of hostingcompanies in the Netherlands which have optimized their platforms for Magento and WordPress. For Magento they use Varnish or Redis caching options and FrontPageCaching
We strive to provide high-quality hosting that gives top website performance and excellent support for all customers, including Magento users. We constantly add enhancements to the service and new features and tools, but since their development is very time and resource consuming, we have to focus first at the applications that are most popular among our users or at the solutions that are most demanded. We are still reviewing the need for a Magento tool and thus cannot provide a definitive time frame for such a solution.
Hello Team,
Did you consider a Caching solution for Magento above 2.3 version ? Memcached stopped to be supported above it, and it is my case.
Thanks.
At this time we don’t plan adding new caching mechanisms for Magento above 2.3. If we add new optimization services we will surely publish a post about it.
Great job with the new client area, I just did the tour!
I will delete the SG Optimizer plugin from my WordPress sites, and I won’t need any additional configuration is that right?
Do I still need Cloudflare as a CDN server?
Thank you guys for a great job and support last year, and I wish a Happy New Year for all of you at Siteground!
Keep the plugin since it links your site to the Dynamic caching 🙂 The current change is regarding the static one!
Can you kindly guide me on this from this tab under site tools i see 3 different options nginx direct delivery, dynamic cache and memcached. By default nginx direct delivery is activated for my subdomain site but deactivated for primary domain. Inder dynamic cache there is option to download your plugin and for memcached all sites option deactived.
Finally how is this cache system working?
Those are three different layers of caching. The NGINX Direct Delivery handles your static resources – css, js, images, etc. The Dynamic caching is full-page caching which requires a plugin to operate. Last but not least, Memcached is type of object caching that improves the way your app works with its databse. Check out our tutorial for info on that matter: https://my.siteground.com/support/tutorials/supercacher
I cannot log into my account. It says error 504 Bad Gateway. NGINX. Please HELP! Have cleared browser cache and still have the same issue.
Hello, please try again. If the issue persists, please contact our Customer Care team for assistance.
“In our previous Static Cache setup you had to use the SG Optimizer WordPress plugin or number of .htaccess rules in order to properly configure browser cache.”
So once I see that I have the new Site Tools, do I remove the plugin?
Also, I have tried repeatedly to see the demo of the new Site Tools, but the page never fully loads and a little red banner on the right side of the page pops out and gives numerous failure notifications.
No, keep it on since it handles your Dynamic Caching, Memcached and other optimizations. As to your other issue, please contact our customer care team, my colleagues will assist you further.
Awesome! Will this be available on Cloud Hosting that use cPanel eventually
No, but they will get it once we migrate our Cloud accounts to Site Tools 🙂
I got a notification that you were moving to a new data center in Utah, which makes me think only one thing. … Did siteground get aquired by EIG, Endurance international group?
No, we are not aquired by anyone. Plus, we’re moving to Iowa and not Utah 🙂
Well, That’s good to know, thanks to the team.
Received a notice that my account has been moved to a new server. Did some testing. My sites behaves OK. Thanks. Well done. The only thing that bothers me, is the fact that previously my site was loading in 3.3 sec and now after the move, it now loads in 5.5 sec with “WP Fastest Cache”. It is even worse (7.4 sec) with SG Optimizer. Hope this is only due to DNS propagating.
I would recommend you to use the SG Optimizer plugin with our Dynamic caching enabled. That should get you much better results than any other caching plugin.
My site use WooCommerce and a wholesale site and so all the products add to cart is disabled until the user is logs in. But due to caching even after the user is logged in, the add to cart is not being enabled, the logged in user has to refresh the page multiple times to see the add to cart button. Same thing happens if we go to homepage the login link still says sign in instead of welcome back user. its this cache causing trouble.
NGINX Direct Delivery handles static resources – images, scripts, css, etc. It does not cache HTML and simply cannot be responsible for the behaviour you are reporting. Please, open a ticket in your SiteGround Help Desk and we will look into it and help you with troubleshooting this.
Is this for WordPress sites too, or some other platform?
It handles all static files on our servers no matter the application used.
Any update on the move? I’m still waiting for my site to be moved. No need to tell me when mine will move but just an idea of when you expect it all to be finished would be nice to use as an estimate…
Once we complete the migration to GCP we will proceed with cPanel to Site Tools one. I really can’t be more speciffic because we migrate servers, not separate accounts and it may be a month or three or more depending on the queue and DC you’re in.
Hey, Hristo.
How about serving static assets like .ttf, .woff and .svg which usually are CORS enabled? I don’t think nginx directly delivery has it enabled for those? How can we still benefit from it and still have CORS enabled for those requests?
We’re thinking about adding such config to the Direct Delivery feature but at this point I can’t give you ETA when it will be available. I am afraid you need to keep it off if you want to specify CORS for those file types.
We would also like to have CORS header control while this is on so we can benefit from Nginx directly delivery. Could this be added as a potential option?
You can set origin rules using .htaccess 🙂
This appears to be getting in the way of an .htaccess rule that redirects PDF file URLs in the Uploads directory to a php page to test for whether the user is logged in or not. Any advice?
NGINX Direct Delivery works in front of our web server which reads the .htaccess file. This means that requests for static resources that are somehow modified by it don’t even reach it. I am afraid that in your case the only thing to do would be to disable the direct delivery.
I had the same issue with the woocommerce_uploads directory and PDFs. Any way to get ningx not to server PDFs on my account?
You can disable the direct delivery from Site Tools
Can you also disable this file-for-file via the Environment settings in the SG Optimizer plugin in the WordPress admin? I am trying to allow just 1 JS file or directory without NGINX caching for cross-domain es6 js modules and don’t want to turn off the fast caching for the entire server…
You can use the instructions in this article to disable it for specific file: https://www.siteground.com/kb/disable-dynamic-caching-website/
HI Hristo,
I’d like to add Header set X-Frame-Options “DENY” to my headers to prevent clickjacking. I have it working in .htaccess with NGINX delivery OFF. Is there a way to add custom headers when NGINX delivery is ON?
Thanks,
Brian
Direct delivery works for static files only. Just add the lines and purge your Dynamic caching once. Then it will work just fine 😉