WordPress is fairly sluggish compared to other CMSs, but the biggest problem is poor standardization of plugin architecture. Some plugins add excessive overheads to the system and adding too many plugins can bring the site to its knees. In addition I've seen that some plugins leave lots of debris behind including DB tables and configs. This is a real problem for novices that play with lots of plugins to 'see what they can do' Dealing with the leftovers once they have been deactivated is often more than they can cope with. In addition the lack of proper uninstall after deactivation is a clear problem that WP should really address.
Make it faster
-
houseofstrauss
MemberPosted: 5 years ago # -
SilverFirefly
MemberSome of the more popular plugins should be integrated into WP anyway, so that would help reduce the number of plugins people are having to use.
I think WP core files needs a complete rewrite to bring it all up to date, including adding better functionality, speeding things up, improving the overall useability of the admin area and bringing the style up to date, maybe Web 2.0 style.
Posted: 5 years ago # -
alanft
MemberI've been using Safari's web inspector network view to check our site's response. (we're on a vanilla linux server running multiple other sites)
with wp-cache the main HTML comes back a lot faster of course around 1 second. without it can take from 2 to as much as 10 seconds! slowish but it actually compares favourably with the other elements that are then pulled down. so i'm putting a lot of it down to the server.
for example with wp-cache the HTML comes back quickly (<1 s) but then what about the JS and CSS pulled down from the HEAD? prototype.js 4 seconds. CSS from one plugin - another 3. is prototpe.js dependent on running any PHP? I don't think so, but the CSS from the plugin may well be.
and the body won't render until all the HEAD elements are pulled in. a lot of these JS files could be deferred til the footer - if they don't change a sites appearance. and that would speed up things as much as using WP-cache!
my advice is check your HEAD for junk JS and CSS it will make it seem quicker
Posted: 5 years ago # -
karimun
MemberA lot of useful tips.
I have made excellent experiences with loading query results into arrays.
Instead of multiple query_posts followed each time by the output I use just one query, filter and sort things in the loop and finally push the results into arrays. The output takes place outside the loop. This decreases my page load time almost to the half!
I apply this technique on page templates that mainly list posts categorized by different parameters without interactivity like comments, ratings or such.Thinking further, these arrays could be saved to a database and be called from there, static. Cache plugins do similar things but sometimes also break functionality of other, maybe more essential, functions.
Posted: 5 years ago # -
allenskd
MemberWell, I don't think queries plays much on this, more like the way wordpress is structured, it's a recursive hell which makes CPU go high.
Not much of a suggestion but here goes nothing:
1) Recode with interfaces
2) Use a framework *ZF, CodeIgniter, PLEASE NO PHPCAKE*Posted: 5 years ago # -
whas27
MemberOne quick way to speed it up a good bit is to comment out the ENTIRE innards of the function "wpautop" in /wp-includes/formatting.php. It contains about 20 regular expression (regex) matching/replacing calls, each on potentially the entire post content for e.g. each post on the blog index page.
Regex is resource intensive, and this can be 200 such calls for someone that has e.g. 10 posts showing.
Here is the line in default-filters.php that does this call: add_filter('the_content', 'wpautop');
1) It's really not necessary to filter what amounts to a syntax check EVERY TIME the post gets displayed. If anything, call it on update... if you must...
2) In general, I have found 0 adverse effects from cutting out this big-brotherly rummaging through the HTML (and there are a few unintended errors in there where some of the "greedy operators" run amuck and replace valid div tags with p tags, stripping put valid embeds on etc. when using the post editors, which is what first alerted me to this function).
Everything seems to work faster and better...
If people use the editor, they can't really screw up the HTML compliance to badly anyway, if they use hand-coded inserts, etc. just let them be... if they screw things up, that's their problem... and they'll likely know right away anyway...
Posted: 5 years ago # -
saltlakejohn
MemberFor the most part, I'm happy with WordPress's response time.
From time to time I've used var_dump and get_defined_vars(), get_defined_functions(), and get_defined_constants() while developing and trouble-shooting personal WordPress utilities. The quantity of data loaded into memory per page view is shocking. Took me aback, I'll say.
However, without core changes amounting to a total rewrite -- a back to the drawing-board rewrite -- we'll live with it. Servers these days are able to cope obviously. I try to help by getting rid of unused themes and plugins. Not much help, but any overhead I can eliminate, I do.
Posted: 5 years ago # -
HealthCareOnline
MemberWordPress speed and response time seems fine for me.
I think removing plug-ins and optimizing themes helps with page load times.
... but I don't have a site getting hammered with a ton of traffic to really deal with server load.
Posted: 5 years ago # -
palPalani
MemberPlease optimize CPU usage!
Posted: 5 years ago # -
Pinoy.ca
MemberMost of the previous posts cite back-end improvements. (For example, entries in the wp_options table left over by previous plugins.) I should mention here that only 20% of the user-response time is in the back-end. The bulk is spent downloading and interpreting the Flash, images, stylesheets and scripts. Read "Yahoo Developer Network: Best Practices for Speeding Up Your Web Site", which says,
Our performance golden rule is: optimize front-end performance first, that's where 80% or more of the end-user response time is spent.
WP Cache won't speed up a bloated webpage.
In this vein, authors of plugins who require additional images, stylesheets and scripts to work should consider putting these components inline instead and putting the scripts on wp_footer and not wp_head. Having .css.php or .js.php components is worse because these aren't immediately cacheable.
But... if we're talking about the v.2.3.3 "Write Post" page, well, yeah, THAT page has 15-20 external scripts, 4-8 external stylesheets and 11 external CSS images. I noticed that it even loads and evaluates fat.js twice! Yeah, that page needs improvement.
Posted: 5 years ago #
Topic Closed
This topic has been closed to new replies.
