I have considered moving the site on a separate plan, but not sure if this would fix the problem.
I'm not an expert so maybe I'm missing some signs in the reports that could help me fix the problem.
I would appreciate some help if possible

Better hosting should improve the problem (not sure if another plan on the same host would accomplish that or not). The reason the admin/edit UI is crazy-slow is that most caching software will bypass the cache for logged-in users (which includes admin and editing) because the content isn't the same.

Basically, the caching hid the underlying performance issue but you still see it if you are logged in. The only way to fix it for everything is to get to the root of the performance issues and actually fix them (likely caused by slow shared hosting).

I don't think this is a logged in request ( I don't see any of the WordPress logged in cookies set for the initial page request ). While the references Patrick made to caching layers being bypassed for logged in requests are correct ( if they didn't there would be really bad security consequences ), that doesn't apply in this case.

The really slow request in that test - http://imageskin.com.au/wp-admin/admin-a...3059122921 - is for the WordFence plugin. That plugin has options that will trigger database writes on every page request ( doesn't matter if visitor is logged in or not, it will write to the DB on every page request ). If you get lots of traffic or have a very minimal server hosting MySQL, it can easily crush your database. Unless you really need the additional data that WordFence writes to the database for every page request I recommend turning it off.

Beyond that the rest of the results show the typical issues when making lots of requests for JavaScript, CSS, and images. Reducing the number of different files being requested will help improve performance.

(11-06-2014 08:36 AM)josephscott Wrote: I don't think this is a logged in request ( I don't see any of the WordPress logged in cookies set for the initial page request ). While the references Patrick made to caching layers being bypassed for logged in requests are correct ( if they didn't there would be really bad security consequences ), that doesn't apply in this case.

The really slow request in that test - http://imageskin.com.au/wp-admin/admin-a...3059122921 - is for the WordFence plugin. That plugin has options that will trigger database writes on every page request ( doesn't matter if visitor is logged in or not, it will write to the DB on every page request ). If you get lots of traffic or have a very minimal server hosting MySQL, it can easily crush your database. Unless you really need the additional data that WordFence writes to the database for every page request I recommend turning it off.

Beyond that the rest of the results show the typical issues when making lots of requests for JavaScript, CSS, and images. Reducing the number of different files being requested will help improve performance.

Hi,
Thanks for that. I am aware that Wordfence takes up lot of data. My concern is for the security of the site. Would you suggest another "security" plugin?