The WordPress admin is not fast. In fact, due to a variety of reasons, it can become quite slow even for relatively normal sites. And even a brand new install doesn’t have completely “snappy” page loads on the admin.
Put it through its paces, with a lot of posts/authors/comments/media, and it can get nasty.
Let’s use an example, which 4.4 lead Scott Taylor Tweetstormed recently:
1) at least 5 people came up to me in Napa and said same thing – they work for a media company, they have a million or more attachments …
2) loading the Edit Post screen takes many seconds – the reason is the queries that are made to determine if you have audio or video files
3) there is no index that contains post_mime_type, so it MySQL loads every attachment into memory and then looks for the first that matches
4) if you uploaded an a/v early on, query will be fastish, but if you didn’t upload one until 700,000 or slow, the query is “slow as balls”
5) typically, with 1,000,000 attachments, each query takes 3 seconds (2 queries are made: one for audio, one for video) – slower with more
6) just adding a type_mime index, the query goes from 3 seconds to 0.7 milliseconds #dark
7) I tried rewriting the query using every technique possible – NOTHING made it budge. Index was the immediate fix.
8) this is a quality of life issue for many people who work at real companies – we should fix this, would be pretty chill
9) here’s the ticket and relevant commits: https://core.trac.wordpress.org/ticket/27985
#dark indeed.
The admin can slow down for many other reasons as well, and it’s a liability for WordPress-the-platform.
WordPress has built in features that are incredible: user management, easy to deploy content structures, extensibility, a low barrier to entry, usability out of the box. But speed is not one of the strengths of the WordPress admin.
Can it be fast?
I wondered: is it even possible to make the WordPress admin fast? I asked Scott.
The only way to make it fast is to make the database schema fast – certain queries on the existing schema are always going to be slow with lots of content.
I’m not technical enough to know what kind of schema changes are possible in WordPress without blowing up everything, but Scott tells me that WordPress core could implement new database indices for various custom queries to help speed up requests.
I understand that the vast majority of WordPress websites are tiny, with little content. But I do think it’s a very common frustration amongst active WordPress users that the admin is slow.
The Basecamp example
One of my favorite posts on speeding up an application is the case study from Basecamp. If you’ve used Basecamp in the past couple of years, you know it is fast. Gloriously fast.
Now, WordPress isn’t hosted, so not everything is possible that Basecamp does; but we can learn from their mindset.
If actions still take 500ms to render, it’s not going to have that ultra snappy feel that Basecamp Next does. To get that sensation, your requests need to take less than 100ms. Once our caches are warm, many of our requests take less than 50ms and some even less than 20ms.
The only way we can get complex pages to take less than 50ms is to make liberal use of caching. We went about forty miles north of liberal and ended up with THE MAX. Every stand-alone piece of content is cached in Basecamp Next. The todo item, the todo lists, the block of todo lists, and the project page that includes all of it.
The sensation of fast
The sensation of fast is what I’d love to see with WordPress.
The lack of a speedy sensation is what prevents me — more than any other concerns — from thinking of WordPress as a good platform for certain types of web apps: project management, CRM, and invoicing come to mind. WordPress’s admin just isn’t speedy enough to handle that kind of web app well right now.
Not to mention, if we ever plan to really make the WordPress admin great on small screen devices, it must be faster. Whether the admin is accessible via an app-wrapper or a mobile browser, in its current form, it’s too slow for me to be able to stand while on a sub-optimal connection.
The admin should be an example
Some may be thinking about the WordPress REST API and how we may be able to utilize it to forgo the WordPress admin and make custom admins that are faster.
I think that the WordPress admin should be an example of a great experience on its own, not one that exists as a backup to new solutions. I think it is important that core development continues to focus on making a better admin experience: including visual appeal, ease of use, and speed.
Great strides have been made to make the admin more functional on small devices, more accessible to all types of users, and more user friendly. None of these are finished projects, and they never should be.
We should constantly strive to make WordPress the most user friendly application possible. It is why WordPress is the dominant CMS, I believe, beyond any other reason. We should prioritize admin speed as well, more than we do now.
