search

umco / umbraco-stacked-content

Stacked Content for Umbraco 7
https://our.umbraco.org/projects/backoffice-extensions/stacked-content
MIT License
17 stars 26 forks source link

Slow to initialise #6

Closed leekelleher closed 7 years ago

leekelleher commented 7 years ago

I have noticed that once you have a few blocks in the stack, the initialisation slows down (a lot). I haven't investigated this yet, just wanted to flag it here for future reference.

mattbrailsford commented 7 years ago

do you have previews turned on?

leekelleher commented 7 years ago

Nope, this is with the "disable preview" option enabled.

It could be something with UaaS? as I've noticed this on a Staging environment - as that's where the content is being entered.

I'll investigate more later 👍

leekelleher commented 7 years ago

20 days later, I have some feedback...

On my project, we're have 13 doctypes associated with the Stacked Content instance. So when innerContentService.getScaffolds is called, it takes a while. :hourglass:

I'm wondering if there's a way we can delay the request?

mattbrailsford commented 7 years ago

Hmmm, you probably could get them at the point of opening the dialog for the first time, or maybe even just run it in the background. We could separate out detecting single item mode and only require that to start, then load scaffolds in the background?

mattbrailsford commented 7 years ago

Ok, so I've made some changes to try and resolve this. Though the majority of the work is actually inside InnerContent (this could get tricky reporting issues :))

I've pushed two branches to each repo "load-perf". As I say, the InnerContent one is the one with all the meat, while the StackedContent one is more an update to use the updated service methods. Obviously, you'll need to update both to test.

So, what have I changed?

The main issue was that previously, and this was copied from NC, we load all scaffolds on PE load. This makes sense for NC because it has to create the editor forms inline straight away, where as with Inner/StackedContent, we don't really need to until we open the dialog. So, with that in mind, I've moved all the scaffold fetching into InnerContent (so add on packages like StackedContent don't have to worry about these anymore) and it only gets requested when you click to edit/create a new item. This does make opening the dialog a little slower while it loads, but you are going to have to take the hit somewhere. To make this as performant as possible, when a scaffold is loaded, it gets cached for that PE so if you create/edit an item of the same type, it'll re-use the same scaffold so that it doesn't have to make another scaffold web request.

Because we no longer load the scaffolds, I've also had to make another web request though when you open the "add" dialog to fetch the name / icon of doc types you want to use (we got this from the scaffolds before). I've made this API action as minimal as possible, passing back only what we need, and again, I cache the result after the first load so you only take the hit once per PE/per editor page.

I think this is the best we could achieve. It has neatened up the innerContent service api though which I like as like I say, add on packages don't need to think about scaffolds any more, just passing in contentTypes.

@leekelleher do you wanna test this in your install and see if it improves things?

leekelleher commented 7 years ago

Thanks @mattbrailsford! 👍 I shall give it a test! 💯

leekelleher commented 7 years ago

@mattbrailsford I've tested it out (on the project that has those 13 different doctypes) and it works really well. I did various network throttling tests (only within Chrome dev-tools) and it performs well even on GPRS (500ms latency).

I'm happy to merge the "load-perf" branches in now if you want?

mattbrailsford commented 7 years ago

Whoop whoop! Make it so :)

On 18 Mar 2017 11:25 a.m., "Lee Kelleher" notifications@github.com wrote:

@mattbrailsford https://github.com/mattbrailsford I've tested it out (on the project that has those 13 different doctypes) and it works really well. I did various network throttling tests (only within Chrome dev-tools) and it performs well even on GPRS (500ms latency).

I'm happy to merge the "load-perf" branches in now if you want?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/umco/umbraco-stacked-content/issues/6#issuecomment-287537639, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgLyRY4bRCoV0XRRwVnbc1PhFe1NzGFks5rm78ogaJpZM4MDLoo .

leekelleher commented 7 years ago

Closing, fixed in PR #13. Thanks @mattbrailsford! 🎉