Why is WordPress backend so slow on Dreamhost?

You might want to run this plugin analyzer to see if a certain plugin is eating up your memory for your site and consider disabling the heavy ones. Feel free to stop by live chat at dreamhost.com for instant support. Also, check what php version you are running for wordpress. Try 5.3 fast cgi or 5.4 fast cgi php for wordpress sites.

https://www.ads-software.com/plugins/p3-profiler/

Thanks for your reply Rob,

Unfortunately, I have been there, done that, several times. One week I chatted with support four nights in a row. Same excuses, you have too many plugins (so I removed some), you should have only one user for each domain/subdomain (so I did that). During each chat, they finally restarted the apache instance and then the pages load normally. This happens over and over again. I requested to be moved to a new server, but since I had one day of good performance, the support person is hesitant to move me for fear I will have the same problem on another server. I will be leaving Dreamhost as soon as I find the time to search for another hosting company.

p3-profiler showed one plugin using more memory than the others, but nothing substantial. Using 5.3 fast cgi. First attempt using 5.4 fast cgi identified a couple of new php warnings in my code so I defaulted back to 5.3 to keep the site up. But, I am addressing the warnings on my localhost (because it takes hours to do any kind of “development” and “testing” on the Dreamhost server”.

But what I am really looking for right now is the technical details of what WordPress is doing when the edit page is trying to load or when the “update” button has been pressed. Does wordpress reload every plugin when you are editing or saving a page? I am trying to understand what WordPress is doing behind the scenes, so that I can have a better understanding of how my website is interacting with WordPress when WordPress is performing these types of operations. Before I go to the hassle of moving to another hosting company, I want to make sure I have covered all of my bases and there isn’t something obvious in how my code is interacting with WordPress that, if changed, would improve the performance during these operations.

So, still looking for the answer ….

What kind of Dreamhost account do you have? I use DH myself without any real issues, but configuring for “speed” is highly dependent on specific cases.

Does wordpress reload every plugin when you are editing or saving a page? I am trying to understand what WordPress is doing behind the scenes, so that I can have a better understanding of how my website is interacting with WordPress when WordPress is performing these types of operations.

WordPress is a stateless system. It reloads everything on every request to the server of any kind. This generally is not the source of visible slowdowns, though, for all sorts of reasons. The bottleneck is usually the database, although again, specific cases are all specific.

Hi Samuel,

I have a shared hosting account, and I have pagespeed turned on for this site. With pagespeed turned on there is a noticable improvement in front end peformance, but no change in backend peformance. In addition, I had tried a VPS account on trial, but there was no change in backend performance there either.

What kind of account do you have on DH?

I have their lowest tier of VPS. With a bit of configuration, it’s quite speedy for my purposes. Switching to nginx and using W3 Total Cache with the XCache support helped a lot.

Hi vmallder!

I’m sorry to hear you’re having a frustrating experience.

Have you always had this problem, even with a vanilla install of WordPress using the default theme and no plugins activated? Or is this a new problem that suddenly cropped up? Do you host multiple/other sites and if you do, do they also experience the same problem?

I actually host my WordPress sites on Dreamhost, too, and like you, I use shared hosting (been with them now for 5+ years using their shared hosting).

In my case, however, I seem to have little trouble or issues with slowness in regards to the backend/administrative side of WordPress. Additionally, unless my site is actually down or the connection isn’t good (seldom happens, but it does on occasion) or if my own connection isn’t good (like if I use public wi-fi or my home wireless connection is acting up), I never experience the timing out or really lengthy loading times you described.

Taking into consideration that I am accessing my live sites on Firefox 12 from a Windows XP machine with 2 Gigs of RAM and also the fact that my wireless signal isn’t always the best:

– Previewing Posts/Pages is Around 5-15 seconds

If I am loading in outside content (like embeds), my loading time takes longer (towards the 10-15 seconds).

– Clicking Edit and Going to the Post Edit Screen 5-10 seconds

That almost never changes much.

– Updating a Post/Page/Template file and Waiting for Screen Refresh 5-10 seconds

This also doesn’t seem to change much.

– Loading a Non-Cached Post or Page on my Site takes 5 seconds

Embeds or large file sizes can lengthen the time.

– Loading a Cached Post or Page on my Site takes less than 5 seconds

Embeds or large file sizes can lengthen the time.

I’m the sort of person who likes to do live Posting and live template development and debugging which means I’m constantly typing, saving, uploading, and refreshing. In which case, slowness and/or lag/something out of my ordinary would really hit me hard and it would be something I would hopefully take notice of quite quickly.

There HAVE been times where it has initially seemed that my WordPress backend has been more sluggish, but this slowness was proved to be a memory and resources issue with my own web browser and machine whereupon closing out my web browser and rebooting my machine always resolved the issue.

In other words, for me, if my backend was/is being ‘slower than normal’, so is my frontend and with it, my connectivity with every other site (including here on the forums and on Google, etc) because something on my end is affecting my browsing and working-in-the-web-browser experience.

But… that’s my own experience.