Front end and back end speed

Is it just me, or is anyone else experience longer than usual load times in the admin for simple things like loading pages, saving modules, etc. And longer load times on the front end sites… seems to be some sort of degradation in site speed for many of my sites where they were previously loading way faster.

Or am I losing my mind (well this is probably a given).


In the process of migrating my first site from BC. Using Google Page Speed Insights to compare the still live BC site to my treepl test site (AU data centre) im finding the Treepl site a little slower. 97/98 on BC vs 94/95 on Treepl. Server response time seems to be the main culprit.
Not sure if server speed picks up at all when you go live with Treepl?
Is this the sort of speed degradation your seeing, or is it something more substantial?

Mine are with a few live client sites (one of which we recently assumed from other Treepl partner). Seems the issue with load times is with liquid heavy sites. Again, site speed was fine a month or so ago, just noticed it this week that sites seem a bit slower than usual. I really can’t say if it was between sprint 4.4 or 4.5 or 4.6

All I know is for a few of my sites they were certainly loading faster before (no modifications made to any of these sites).

I find that even the website is slow to load which does not speak well for the cms.

Agreed @hopestew thought that was just me visiting the site with site speed issues.

I think the new liquid rendering engine (Beta feature) will help here.
Have you tried this on the slow sites?

Not until it is out of beta no. Can’t risk wrecking a live site from Beta stuff. Again, seems to be something in the infrastructure updates in one of the sprints that’s slowing things down. I went through all of this already back in v3.0.

This is a recent thing and my client was the one who brought it up to me, where she said the site loaded fast and then now it is loading slower. With no technical updates to the site from either me or them. Have now heard this from a few people. Anyways, hopefully Treepl is reading this and can address this (which I’m sure they will as they do take this stuff seriously).

Same here. Slow front and back end. Until recently creating a custom module took almost a minute. Went down to 10 seconds now, but I remember it to be much faster. And we have to beta rendering on on all instances.

If you experience issues with speed in admin and/or frontend, please send the URL with details to support. We will investigate every site.


Hi Vlad,
Does a Treepl test site run at 100% speed, or is there some compromise?
ie. Will my site run any quicker when I make it live?

Hi Reagan,

Every trial site may load longer after being idle (not visited), the speed of the live site is absolutely different.

@Vlad.z It is more an inconsistent behavior: Often module items need up to 5 seconds to save, sometimes it goes faster. It’s on all my live and trial sites. Also loading items and item lists can take a while even if the list is short. Partners often describe the Treepl admin as faster than with BC. For me it is significantly slower, so I would like to double check if there’s any differences with how other partners see it. Already switched to Google Chrome for the admin, but there might be more I can do.

We’re in process of refactoring some of the core elements of the CMS that will stabilize the speed and performance of both backend and frontend. These updates will start rolling out later this week as separate hotpatches.


Thanks for the update @vlad.z

@A3CS @TimL @hopestew @Reagan_Vautier Hi Guys, are any of you still disappointed with this performance issue, has it gone away for you with more recent updates?

I find the inconsistency described by Tim still ongoing and it seems to affect some sites more than others. I’ve raised it with Treepl Team and initially they said it was being resolved but more recently they are saying it’s the site performance with large issues / video etc on some sites. Obviously, I’m aware of some of those issues. But there’s no way for me that explains the early part of the process which almost seems like an addressing issue, plus the fact that the same slow site was quicker on BC. Because it’s not consistent, it’s frustratingly difficult to pin down (I’m sure for the Treepl Team as well as us!).

One of the selling points of Treepl was that it was going to be quicker than BC. I’ve had third parties develop Umbraco sites before and speed was never an issue, so was hopeful as this was the underpinning of Treepl that it would be very solid and reasonably quick. (I’ve had the issues in the bad old days of Joomla and WP sites and how slow they could be with version updates).

Don’t want to be negative here, I really want this to work for everyone, I just want to know if anyone else has any issues - with a view to finding a solution! It’s a real concern and as a result I’ve put a hold on any new dev in Treepl that wasn’t quoted and agreed before last autumn, but even so have some things in the pipeline that I would like to be sure we can deliver successfully.

Thanks all.

1 Like

Hi everyone and thank you for raising this…

There are two factors that affect sites’ performance: infrastructure related and CMS related.

Infrastructure issues are mostly caused by overloads that are affected by migrations and new trial sites, and we did have an overload on one US box and one AU box recently. The pace of migrations and new trial sites have significantly increased starting January (by 256% compared to December) and February already shows more load. This issue is resolved by physically adding more servers to our data centers and that requires several hours of work for our admins.

On the CMS side… there is currently a known reindex issue that affects several sites’ performance, it’s a top priority right now so we plan to release a hot-patch this week to address that exact issue. In general, the CMS’s load speed is stable and fully acceptable but it is slower than BC at some parts and definitely needs improvement.

Starting Feb 20th (a long-awaited official ecommerce release that affects other working modules of the system), after 21 months of insane development pace, we will finally start working on refactoring of the entire CMS. The main outcome would be significant speed increase both for the sites frontend and the admin (at least as BC or faster in every (!) aspect).

It was impossible to apply any effective refactoring and develop new major features (like ecommerce) at the same time. We’ve tried it in November/December and ended up doing roll-backs; ecommerce delay was a result of that attempt as well.

We know every spot where the optimization is needed and know exactly how to fix it, so starting Feb 20th, we will have dedicated devs working exclusively on the entire CMS optimization. Those performance updates will require lots of QA (since they affect existing sites) but nevertheless, we plan to roll them out with every release starting March 11, those will also include some improvements already requested in the public backlog.

P.S.: I plan on doing an open Treepl gathering later this month or early March. I will share our progress and upcoming plans. Our team will be there to answer any of your questions. More details are coming soon.

Thank you for choosing Treepl! We truly enjoy developing this amazing platform for you!


Sounds awesome Alex - Thanks for the feedback :pray:

Our trial site is so slow that it takes minutes to do something as simple as upload an image rather than seconds.

We were hoping to do some minor changes today and finish off our client’s website and launch immediately but this speed is making it near impossible.
Please look at this video. Why one site is working fine and the other is taking a long time to load? Both are on the AU data centre.

Hi @Khy. I know it’s no consolation to your issues and concerns here, and I can only hope you get a response/resolution soon.
But if I can offer a possible suggestion to try in the meantime… if you haven’t already, perhaps duplicating the trial site as a new instance? The new site might not suffer the same degradation?
I think most settings and data are duplicated in this process so may not be any additional work, so might be worth a try.