Performance help

I’m looking for some additional ideas on how to speed up our WordPress Portal, which we’ve built from the ground up.

The pages are taking a little longer that would like to load and it causing some concerns.

Things i’ve tried:

Putting CDN’s in for as much as possible.

wp_enqueue_style( 'font-awesome-stylesheet',
awesome.min.css', array(), '1.0.0' );

Optimising images.

Keeping all plugins updating and removing

unnecessary ones.

Reducing database calls

Reducing Post revisions

Hosting is on it’s on VPS. The portal is the only thing on the VPS and the VPS is of good specification

A variety of code changes to speed up

Can anyone help with thoughts?

  • Adam Czajczyk
    • Support Gorilla

    Hello Richard

    I hope you’re well today and thank you for your question!

    I tried to check the site but it requires login so when I’m loading it as a visitor, it redirects me to a login form. That actually loads quite fast and I believe it’s not that part that you are trying to improve – I assume it’s what’s “behind login”, right?

    I’ll be happy to review it and see what else/more I could suggest but I’d need to be able to see an actual site and to access its back-end to check current configuration. Would you please enable support access to the site so I could do it?

    To do so, please go to the “WPMU DEV -> Support” page in your site’s back-end and click on “Grant support access” button there, then let me know when it’s ready.

    Kind regards,


  • Richard
    • Site Builder, Child of Zeus

    Hi Adam,

    I am good thank you – how about yourself?

    Correct. It’s an internal system, thats locked via login. Correct, the login page loads quickly.

    It’s pages and navigating around, is painfully slow at times.

    Anything we can do to speed it up would be a step in the right direction.

    Support access has been granted.


  • Adam Czajczyk
    • Support Gorilla

    Hello Richard,

    I’m fine, thank you!

    Thanks for confirmation and for granting access. Apparently though, the “login” somehow takes over and it doesn’t let me in even via the support access. That rarely happens but in such case I won’t be able to use that tool to check the site and I wold need to access the site directly.

    Would you be able to provide me with admin level login and password? That can be an additional, temporary account that you create and then remove after I’m done with checking that.

    Note: Don’t leave your login details in this ticket.

    Instead, you can send us your details using our contact form and the template below:

    Subject: “Attn: Adam Czajczyk

    – Site login URL

    – WordPress admin username

    – WordPress admin password

    Thank you in advance and I apologize for inconvenience!

    Kind regards,


  • Steve
    • Site Builder, Child of Zeus

    Just a simple question really. Are you running php version 7.1 or higher? If you’re still in the 5.6 or so range changing to 7.1 or higher can help with speed. Also, try checking to make sure your server has gzip compression enabled. Beyond that without seeing anything else i’m not sure what to recommend.

    I hope that helps somewhat!

    • Predrag Dubajic
      • Support

      Hi Steve,

      Thanks for jumping in, what you suggested could indeed help here, even tho PHP 5.6 isn’t as old as some of the other versions some hosting companies are still using it’s certainly good idea to use 7+, which not only provides better security of the site but it also has a lot of (good) impact on speed.

      Best regards,


  • Richard
    • Site Builder, Child of Zeus

    Thanks all! Yes running 7 and Gzip plus other stuff.

    I will email in next week, I’m on annual leave at the moment. Have to be super careful with GDPR. So I’ll be giving you access to our dev environment as I can’t give live due to client data on there.

    Appreciate all you’re help.

  • Adam Czajczyk
    • Support Gorilla

    Hi @richard36984!

    Sure thing, just send me a message at any and I’ll “jump back in” and check this. We’re working 24/7 so whenever it suits you best :slight_smile: The “dev environment” is, of course, fully understandable and as long as it’s an (almost) exact copy of a live one – minus sensitive data, certainly – it will suffice.

    Best regards,


  • Adam Czajczyk
    • Support Gorilla

    Hi @richard36984!

    I got your message, thank you :slight_smile:

    I was able to access the site so I reviewed its configuration and then “wandered around” for quite a while on both front- and back-end to see how is it behaving. I must say that it was working quite fine during my visit – it wasn’t particularly slow and wasn’t slowing down at all.

    Is there any specific area/way that I should test it to actually experience that slowness? I’m asking because the site is not quite “typical” and I could easily miss some part of it or some specific “workflow”/path to follow. If so, let me know please and I’ll test again.

    That being said, some “general tips” that I’d like to share would be:

    1. Start with a very basic and simple tweak which is raising WP memory limit; the site’s currently operating on the default 40M which is very low amount while the server allows up to 256M. That would be the value that I consider a reasonable amount for any site; to do this, add following line to the “wp-config.php” file of the site:

    define('WP_MEMORY_LIMIT', '256M');

    Make sure that it’s added above the “/* That’s all, stop editing */” line.

    2. You could benefit from our Hummingbird plugin. The caching options (page cache and browser cache) alone should help but also the Asset Optimization tool too. Here’s more info on Hummingbird:

    Please note: due to the nature of the site it might take some time and effort to configure Asset Optimization properly (you will surely want to use an “Advanced Mode” of it) to find a balance between optimization and performance (so the site wouldn’t break). That’s a bit daunting task and is mostly a “trial and error” procedure that takes time but together with Hummingbird caching it can really boost performance significantly, off loading server itself.

    3. Server itself.

    That’s more complex issue but it actually might be a “bottleneck” here as the site itself is not that complex, in fact. You mentioned that the site get’s “sometimes” slow. This often means that the server is getting “clogged”. It’s a VPS so it’s highly configurable on a system level and that is a good news but it also requires a good knowledge of server administration/management.

    The point is: from what I can see it’s powered by Apache and the default Apache configuration is not the “performance beast”, to be honest. Tweaking Apache config for performance alone can boost speed but mostly – stability (so minimizing changes of temporary slow downs).

    I found some helpful resources on this for you:

    Another good way to speed up and “stabilize” performance is to use Apache as a main webserver but put nginx “in front” of it to act as a sort “reverse proxy” and to server static resources.

    Here’s a guide on setting nginx up as reverse proxy for apache:

    and more information about using nginx to server static resources:

    Basically, such setup would mean following “flow:

    browser request -> nginx -> is it a static content (e.g. jpg file)? -> yes; nginx serves it

    browser request -> nginx -> is it a static content? -> no -> apache -> apache serves it

    It might even be made more complex by adding cache for static resources on “nginx” level (in addition to page caching on site) and adding e.g. caching for a database. But I don’t think that would be necessary.

    To sum it up: first two suggestions are “general” tips that I think you could try right away (even though it might take some time to configure Asset Optimization). The third one is much more complex and it’s definitely a job for a proficient server admin but that’s not something I would start with.

    Also, if you can suggest some additional ways/paths/areas for testing on site so I could actually experience these slow downs, I would access the site again and test it again as it might show up what other changes/tweaks could be applied.

    Best regards,


  • Richard
    • Site Builder, Child of Zeus

    Hi Adam Czajczyk

    Hope you are well?

    Firstly, thank you for taking the time to respond to me, it’s very much appreciated.

    I’ve added that memory limit to the config file. Although, the server memory limit is 256MB in the PHP.ini.

    I’ll read through the server recommendations. We are running http/2 mixed in with CloudLinux

    Areas, that are slowing down:

    When browsing to the “client dashboard” for example, browsing through the tabs is listening fast. However, when browsing to other pages the load time is slow and even to search is slow.

    We’ve tried hard to make the UI intuitive, enough so you don’t have to click off pages so much but you have to.

    We don’t use the backend at all, everything is front end. The only time, we use the backend is to delete a record and that can be painful.

    I appreciate it’s a very complex / unique system and everything is bespoke, which is way complex than we every expected and the live has ALOT of data.

    Appreciate the help.


  • Adam Czajczyk
    • Support Gorilla

    Hi Richard,

    Thanks for your response and additional explanation.

    I have run Chrome audit (lighthouse) on the site this time and got similar results to yours. It looks like the two biggest issues here reported are:

    1. Keep server response time low (TTFB)

    2. Defer unused CSS

    The delay cased by the server response time on the first load is really huge (if you look into the “Network” tab of Chrome console, ordered by “Time”:wink: and that’s indeed an issue.

    What I would start with to try to improve that would be:

    1. Definitely give Hummingbird a try. That would let you address the #2 issues (Defer unused CSS) – you can use Hummingbird’s Asset Optimization to minify and combine CSS files and that alone should lower the loading time (less requests to serve and less data to be send) but then also experiment with “Move to footer” and “inline” options for each files. It will take some “experiments” but you should be able to minimize that CSS impact on the site significantly.

    2. Addressing TTFB (Time To First Byte) issue might actually be a problem. The point is that’s a “waiting time” between server getting a request and responding to it. It, in fact, is in the most part the server-thing issue. It’s possible to try to minimize it with so called “full page cache”. I see you had WP Rocket enabled but also Hummingbird includes Page Cache (I’d go for this one).

    The downside is that Cache (and actually asset optimization as well) should not be enabled during development as it might seriously affect the changes made to the site. So you might need to hold on with it until you’re done with site creation – or give it a go and then disable it until you’re ready to go live.

    The bigger problem is that while caching is a huge “speed booster” it’s also not a “dream solution” for TTFB issue because while it does lower a server load and speeds up the site it also “kind of” masks the real problem which actually is… a slow server. By “slow” I don’t necessarily mean the CPU/RAM etc but rather how it performs and that, again, is a matter of OS, php, webserver and db configuration mostly.

    What else could be done, would be enabling native DB cache. Apparently it’s disabled (I have installed Query Monitor plugin on the site, it’s disabled now and you can remove it at anytime) but the site is making a lot of db queries upon each load so enabling it might help here as well:

    Another thing, small but it’s small steps that make a journey, would be to to actually try to serve FontAwesome directly from your server instead of offloading it to any CDN. You already got CloudFlare implemented so there’s no need to offload it to MaxCDN and according to performance tests that’s adding up to load time.

    I’m also not sure about the theme. Audit suggests that the site is using “an excessive DOM size” which means that the produced markup is very complex. Reported is over 3,000 nodes while recommended is no more than 1,500 – that is a difference. I don’t have access to the theme but it might actually be an important factor as well, requiring some optimization.

    That said, I’m sorry for such a “generic” response but it’s quite a “touch case” because there’s nothing “obvious” at the first glance and even at more “insightful view” the site itself seem to be setup and configured fine. So, it’s more like my thoughts and conclusions on what I see on site and in tests and based on my previous experience rather than a “step by step” guide on how to ultimately solve that but I hope that it makes some sense to you and can be of at least some help.

    Kind regards,


  • Richard
    • Site Builder, Child of Zeus

    Hi Adam Czajczyk,

    Thanks for your help. To date:

    I’ve been working through the issues & i’m unsure if i’m actually doing anything to help but these are my findings to date.

    MYSQL Caching is now turned on = & the output is this:

    mysql> SHOW VARIABLES LIKE ‘query_cache_size’;




    | Variable_name | Value |




    | query_cache_size | 16777216 |




    I’m having mixed results. Which is hard to actually find out where the issue lays.

    I’ve been digging through the theme & the truth is we starting using limitless theme:

    Our first backend dev, hacked it and made it work with WP. This was far from ideal so we striped it back and made our own theme called “Octopus” it’s a cut down version and the front end, is all ours but it still needed some work, there was 7K Files, in there that wasn’t being used and such, I got the DOM under 700 on the main home dashboard and under 1500 on the client dashboard. Which is some improvements.

    I have installed http/2 on the box, this has helped too

    I’ve reduce CSS & image sizes.

    Deferred offscreen images.

    I’ve tweaked apache and installed caching

    i’ve got the TTFB down as low as seems possible (0.68s)

    Reducing all images to next gen formats. I would of liked to use JPG 2000 but chrome doesn’t support it.

    I’ve tried to get the loading time of the chains down but this isn’t having very little impact.

    Taken away the htaccess non ssl to ssl redirect, this was causing a massive 4 second delay

  • Richard
    • Site Builder, Child of Zeus

    Hi Again Adam Czajczyk,

    I've been playing with the Hummingbird Plugin & with a variety of other tools and scripting changes / clean ups. i''ve decreased the DOM size again.

    The only other issues i've got going on:

    Since installing HummingBird, i'm getting the Invalid Cache on static assets error.

    Finally humming bird is telling me to make the server respond quicker. i'm at a loss with this one,

    http/2 is enabled.

    ttfb is down, considerably

    Caching is enabled.

    Opcache is enable and the MYSQL Caching.

  • Predrag Dubajic
    • Support

    Hi Richard,

    It seems that TTFB still has the highest impact on your results, enabling Page Caching and using CDN can help with that further.

    As for the “Invalid Cache on static assets”, you can go to Hummingbird > Caching > Browser Cache and increase the caching time to improve this result.

    The values set by Humminbird are some suggested values but if you want to tweak them for each resource you can do that by changing times in .htaccess code provided by Humminbird.

    You can find some more information about browser caching here:

    Best regards,


  • Richard
    • Site Builder, Child of Zeus


    Thanks for this.

    I’ve been in contact with our server provider & cPanel

    cPanel confirm, the TTFB is not being caused by the server and is setup as expected and is performing well.

    The network the server is on, is causing issues (some) I think – they say they have run network tests and a test VPS and they say the VPS is responding on static content within 150ms – which is VERY high indeed. Anything about 50ms is deemed as laggy.

    I’m unsure how to increase the TTFB – we’ve made a tonne of changes to the code and hummingbird has bought the node size down but overall it seems to be improving.

    We cannot use a CDN – this is because the domain our portal is on i.e has it’s own glue records, which are running our redundant cluster, for our clients hosting platform. So this is a tricky one. The only way to get around this, would be to use a new (separate domain) for our hosting platform and then setup the NS with the DNS Cluster. That would be the only way, the domain “” could use a CDN to it’s full functions.

  • Predrag Dubajic
    • Support

    Hi Richard,

    Is there an option for you to create new clean WP installation on that same server, and check the TTFB for that?

    If there’s no difference, and vanilla installation is having low TTFB as well, then there’s not much that could be done from your end except for caching and CDN.

    Best regards,


Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.