Keystone-classic: Admin UI is very slow to load the first time you view it

[jstockwin]

Expected behavior

Admin UI should load pretty quickly.

Actual behavior

Admin UI can take over 15 seconds to load.

Steps to reproduce the behavior

See here - "[admin UI] was visible after 14761 miliseconds". Compare that to this older build which only took 1748ms to load the admin ui.

Alternatively, start the test server and log in, it'll take a while to load the admin ui the first time.

What caused this? Is there anything we can do to speed things up?
Related to #2824, but I think different, since #2824 is about startup performance, whereas this is about page load times.

[JedWatson]

I've done some research into this and our bundles are taking about 10-15 seconds to generate (all three). Stripping it back to generate one at a time doesn't improve performance significantly; on my top-spec MacBook Pro Signin.js on its own takes 4s, Admin.js takes 9s and FieldTypes takes 9s.

Given how little code is actually being bundled, the only thing I can think of that's taking the time is the babel compilation step (may have slowed down due to new features or plugins we're using?)

To put that in perspective, Signin.js is 14k and includes two files. So I have no idea why it's spending 4s to generate it, that seems ridiculous!

[jstockwin]

I think this might have been mentioned before, but can we not generate the adminUI at startup?
I understand that we stopped that to improve standard startup times, but can we not do the normal startup so that the webpage is up and running, and then immediately trigger an admin UI build?

That way, by the time the user has navigated to the admin UI page, it'll probably already be built?

[JedWatson]

I think that's going to be an improvement but we don't currently have enough flexibility to wait until the web server has started listening before kicking it off. I'm planning to fix that next, now the bundles are optimised. Also given how slow it is to generate I think we need to look at an on-disk caching system that is still dynamic but persists between startups.

[mxstbr]

Yeah something seems way off here, do we know which changes prompted the much longer compilation time?

[jstockwin]

It starts between travis build 4242 and 4281 if that helps....
I'm sure if you trawl through enough logs you'll find it :)

[jstockwin]

Having said that, it's probably just whenever we switched from building the admin UI at start up to building it the first time it is viewed. So tracking it back to a problem commit is going to be very hard.

[mxstbr]

Ahh, that makes sense…

[webteckie]

Shouldn't this be closed? I thought this was addressed via https://github.com/keystonejs/keystone/commit/62f2a54c35a515e21844a5a460d1f45a9930c2f9 ?

[jstockwin]

That helps with the e2e tests, sure. But as a general User Experience issue, it's still pretty slow to load - especially as most users probably won't set the pre-build environment variable.

[VinayaSathyanarayana]

Can we have the "pre-build environment" set by default

[jstockwin]

I think there was a discussion about it at some point, and we decided false should be the default. Can't remember why though.

Regardless, that's just shifting the problem from the admin UI to the general start up time. We should really try to reduce the time to _fix_ the problem if possible.

[wmertens]

if you set the pre-build environment, is the server accessible while the UI builds? If so I don't see why we can't make it the default…

[jstockwin]

I believe the answer to that is no. Keystone itself will just take longer to start the server when you run it.

[wmertens]

@jstockwin @VinayaSathyanarayana with this branch the admin UI is prebuilt and minified: npm i keystonejs/keystone#webpackify

This uses webpack to build all the client code at install time. I would love some testers. Everything should work exactly as before, just faster and with a smaller install size.

If you build in keystone itself, you can use npm run build, npm run build-dev or npm run build-dev-watch after changes to the admin ui code.

[jstockwin]

@wmertens Nice! I'm currently working on client stuff, and everything is unlinked right now. But I'll try and set that all up again and do some testing tomorrow!

[jonnyasmar]

Sorry to resurrect an old thread, but I wanted to share my findings here in case anyone else is experiencing this issue despite the workaround in https://github.com/keystonejs/keystone/issues/3548 as I was.

I was experiencing extremely slow first load on Admin UI off a base install. The Yeomen install doesn't seem to prompt for any sort of DB credentials, yet KeystoneJS will still run just fine (until a restart of MongoDB, which ended up breaking it for me due to failed authentication). After explicitly setting up a user for my db and setting those credentials in .env my load times for Admin UI sped up considerably.

In case anyone needs some direction on how to do this:

1. Log into your MongoDB with admin credentials
   mongo -u adminUsername -p adminPassword --authenticationDatabase admin
2. Select your KeystoneJS db
   show dbs (if you don't know what your KeystoneJS db-name is) use db-name
3. Add a new user to the db with readWrite permissions
   db.createUser({user: "username",pwd: "password",roles: [{ role: "readWrite", db: "db-name" }]})
4. Add the following line to your .env file
   MONGO_URI=mongodb://username:password@db-address:27017/db-name
5. Restart KeystoneJS!

Hope this helps!

[export-mike]

Keystone takes a while to load on the first time you visit the admin UI as its running browserify. I was discussing just the other day with a few guys at thinkmill. How Ideally it could ship with a bundle instead. Seen as the the admin UI is static.

[jonnyasmar]

Yep - I realize that was the direction of this conversation and agree in that regard. My issue was different however yet my symptom is the same and all of my searches led me to this thread, so I hoped anyone with the same issue as me might find this useful.

[dfinton]

I found this thread after noticing the same problem with the admin interface taking up to a full minute to load up after a restart. I use nodemon for development which restarts the node process when it detects a file change event. Because of this, the slow load times for the admin interface were becoming a real roadblock, but after seeing the note about browserify being run on reload I found a workaround. I found the build.js script in the root directory of my keystone instance in my project, so I commented out every line in that file (it's only 7 lines long). That seemed to have helped the situation immensely and hasn't negatively impacted the performance of the admin interface in any way. If I do see any issues I can always uncomment out that script or just reload the framework via npm.