Wordpress Seem Slow? 76 Files Included Per Pageview

I noticed over the past couple of years Wordpress getting sluggish. Yesterday, I installed Wordpress on my home computer. It is pretty slow. As a little test, I put a call to PHP’s get_included_files() function in the very bottom of the Wordpress template (footer.php) so I could see how many files the script includes. There are a total of 76 files included with each pageview on a fresh installation of Wordpress using the default Twenty-Ten theme (77 on mine including a backup importer plugin).

One file that was included was not needed. I had to install Wordpress’ importer plugin because Wordpress has no ability to import its own XML backups unless you download and install the importer. Logged out and viewing the blog index and posts pages, I saw that Wordpress is including the importer PHP file even though there is absolutely no use for it. Subtracting the importer file that was included, that makes a total of 76 files included per pageview.

Most of us are aware that one of the slowest parts of generating a webpage is file access. Right? A powerful web server can compile and execute thousands of lines of PHP code in the time it takes to seek one file on a hard drive. The only thing slower than file access is pulling data from a database, which does its own file access.

Does anyone else think that 76 files included (or more depending on what plugins you have) for every pageview is excessive? Am I the only one who realizes that hard drive access is slow and tries to limit the number of files included to as few as possible?

If so, speak up and complain to Wordpress. Because code bloat is a serious performance issue. If they wanted to, they could stick most of the logic and template code into a couple of classes instead of including 76 files or more (some of which have only a few lines of code–take a look at wp-blog-header.php). If people don’t speak up, this bloat is probably only going to get worse. Wordpress will only get slower and slower.

WordPress › Support » 77 Files Included Per Page View! Insane!

I think that is a bit much. I haven’t touched my wordpress install since the last time I updated. Breaking down files into multiple ones drove me out because I wanted to edit something, and all that file did was essentially call one or two fuctions. Nothing in the Codex would tell me where to find this part, and I didn’t want to rip apart the core to do essentially what I was a few updates prior.

It is not the best practise to post the same question, using the same words in multiple locations. It would be interesting to see what the WP Mods say. I wouldn’t expect having a reply from Matt or Andy…

It is a bit excessive, but with appropriate caching it isn’t too bad.

I do a lot of Wordpress theme and plugin creation and, to be honest, I’d rather have 100 included files then to have them cram them all into 10 files.

I’ve been installing plenty of fresh Wordpress installs for various things and they run quite quickly, even on small systems. At the same time, I usually only have 3-4 plug-ins (max) running at any one time. I think this is pretty atypical, so I probably get better results then your average user.

(Also, just a note, it doesn’t look like it was posted in two places… it just looks a little weird in some of the lists.

I’m not as anywhere near as experienced with Wordpress as you, but I can say that I would rather have everything crammed into 10 files. One big logic class file, one big template class file, one database class file with queries, one config file, maximum code reuse and maximum efficiency. If you have one big 5 MB include file, the server can process that much quicker than seeking, reading, and compiling 50 separate 100 kb includes.

Disk access is the slowest part of generating a dynamic webpage and will probably be for many years to come.

At the very least, Wordpress should not be including files that are not needed such as the importer plugin when viewing the index and single post pages (and probably when viewing other pages). I am sure you will agree with that.

I do.

However, that’s actually on the plugin author to a large extent, not Wordpress’. For example, our current production site (which was built before I joined the company and is quickly being rebuilt by me) has about 70 files total (for the end user). About 30 of those are Javascript files (many redundant) included by plugins (many of which are redundant). This isn’t Wordpress’ fault, but the fault of the developers for not including them how they should be.

There are similar things on the server-side as well which happen. It’s a large part of the reason I usually end up with no more than three plugins in any installation (since stuff is under the GPL, I’ll usually merge stuff from a third-party plugin into a master plugin I optimize… if I use a third-party plugin which is rare).

Now that I think about it though, it wouldn’t be a bad idea if Wordpress did create a single “production” file which had all of the classes merged into one file. However, the flip-side to this is that you wind up including a lot of things that don’t necessarily need to be.

However, properly optimized (even without any real caching) I still think the performance is decent.

If you start digging into really using plugins for doing advanced things and have to go through the source code to find undocumented hooks (or just hooks that are tricky to figure out), you’d appreciate the split files more.

I’m kind of going back and forth, aren’t I? =p

I think the best solution would be if they merged some of the “core” files into one (for a production version) to reduce the number of files needed. However, I’d cry if I saw them merge everything into one (or a few) giant files.

WordPress was originally created by a guy who, by his own admission, at the time knew very little PHP. A lot of it looks awkward, like breaking into and out of PHP tags from one line to the next (with nothing in between), functions that echo directly, reliance on the global scope, minimal use of objects and the unusual while/endif syntax when the rest of the world was using curly braces.

I suspect that there’s also a lot more DB access than necessary.

WordPress took off because of its features and ease of use for bloggers, but its can be a pain to develop with.

Yes, if a single logic file with the core Wordpress logic, 90% of which was not used, were included on every page view, that would be including a lot of stuff that wouldn’t need to be. However, even with a larger include size, the compiler would compile it to less than the raw size of the file and the code that isn’t used wouldn’t be executed. It might take up a little more memory (a few hundred kb which is not significant), but it would result in much lower overhead than loading dozens of includes. Overall execution time would be many times faster than current. On a shared server or a high volume site without an accelerator, this would be a huge improvement in performance.

If one is on a server with an accelerator, I guess having 70+ files included on each pageview would not matter because the opcode would be cached and executed from memory. But what percentage of bloggers hosting their sites on shared hosts have accelerators which will execute their site from RAM instead of opening all 70+ files? The shared server I’m on does not have an accelerator. With hundreds of sites on a shared server, I don’t know how long an individual site’s code would remain resident in memory anyway.

Wouldn’t having everything all in one place in an object-oriented format make it easier for programmers and plugin authors? I don’t know, because I’ve never done anything more with Wordpress than make a few custom themes. I do know it makes for easier code reuse. For example, in Wordpress’ default Twenty-Ten template there are calls to generate navigation links (next and last) in multiple templates. If you want to make one change, you have to do it in multiple places.

The problem with having it all in one file, versus having split files, is similar to the reason you do split files in compiled languages, such as C++ and C#.

If you have 50 classes split into 50 files, all you have to do to find the class is open it’s corresponding file. If you have 50 classes in one file, you have to scroll through a file with 10,000 lines to find the class you want. Sure you can use a search feature, but that gets old very fast.

It also makes it a lot easier to find things when you aren’t sure exactly what you wanted. For example, not long ago I wanted to do some stuff with Wordpress’ relatively new Menu feature. I wasn’t really sure how this stuff was stored, but because of the separate files I was able to find what I wanted by going “hmm, this looks like it might have what I want”.

Now, for templates, that’s a slightly different story, but I still prefer the separate files. Getting portions of code in one or multiple places is all on the developer. Personally, if I have to do something twice, I move it into functions.php or in another file which I include in. When you get into really complex sites with multiple custom post types and taxonomies, it’s a lifesaver to be able to use multiple template files like they have.

The key difference is that C/C++ is compiled. So using 10,000 different source files is not going to matter if it is compiled down to one executable or dynamic library. Interpreted languages are a different breed than compiled languages entirely.

A decent code editor such as Notepad++ will wrap the code leaving only the function names exposed. It makes it easy to find what you are looking for and, as you mentioned, you can always use its search functionality to find what you are looking for instead of scrolling.

My experience with Wordpress has been just the opposite. I have to open a file where I think something is, only to find it contains only a few lines of code one of which calls a function somewhere in the global namespace and then I have to hunt down where the function definition resides.

You may use something only once now. But in the future you may decide you need to use it for other things.

When I code, I try to keep the number of includes between 5 and certainly less than 10. A stub file is requested by the browser which loads the logic that contains a controller (for rewrites) which then calls the appropriate logic function which loads any database or special functions classes if needed then loads the template class for output.

Not knowing C++, but prior to compiling and making an exe you work with all 10k? So during runtime you only deal with one…

This is new to WordPress in the last few versions. I have to agree I absolutely hate it and think it is a waste. I am considering downgrading because it is getting crazy, and I feel forced to used widgets now unless I rip apart the whole theme.

Really doesn’t shock me – it is the price of making a very hackable/themable/templatable/modifyable system. Changing it is going to be a nightmare without forking – they now have microsoft’s backwards compatibility problem. Finally, if you are using some reasonably intelligent archetecture, you are not banging the app server on every page load so your load should be lower.

Yes, it is a different situation, but the reason for keeping them separate is still the same (just a few more cons).

Yes, but you constantly have to re-close all of the functions and classes. It also reduces your ability to skim it looking for something specific without expanding everything.

There are those times, but more often then not I find what I want, or am at least able to work backwards pretty easily.

I agree. Many generalized things do go into functions, even if they are only used once. With plug-ins specifically, I always use OOP which gives me an added layer of flexibility.

Agreed. =)

Its no mystery that WordPress programming is steaming pile of sh*t. You use WordPress for ease of use and plug-in library, not because its a well programmed. Most people using it aren’t programmers so they could really care less about how well its programmed. That is until it breaks or needs customization to achieve a business goal. The only time I ever used it was when I could just install it and be done. I will live longer not having to crawl through WordPress “programming”. None the less the thing to worry about more so than includes is many of the half-ass, unoptimized queries that pile of crap spits out or uneducated “themers” create. That is were the most significant performance loss is going to lie, not with includes, but garbage queries. If you truly care about performance run some explains on common queries and see just well optimized and scalable they are. Its very likely that the issues are occurring because queries do not scale well rather than a few little includes.

I personally have to disagree in saying that Wordpress is not well coded.

Is it crazy optimized and absolutely perfect? Probably not.
Is it poorly coded? Definitely not.

If you compare Wordpress’ code to something else with about the same usage, like vBulletin, Wordpress is 10000x better (I should know, I work in the code of both on a daily basis).

TRUTH.

It’s even scarier how poor a programmers the people who created it in the first place are – much less all the stuff hardcoded into the output when it ALLEGEDLY has a skinning system. (see all the blasted ‘classes for nothing’ on anchors and lists and raging chodo for pointless full URL’s)

The biggest problem I have with it is that if often seems that rather than make a function, they just make another file… as if another file request is somehow better than having a function already loaded and parsed.

I mean, go through the ‘logic flow’ of it… (this is from 2.9, I’ve not bothered downloading anything newer since I don’t use WP)

Index.php (397 bytes)

one define, a require… and ‘done’???

Takes us into wp-blog-header.php (274 bytes)

if the define we JUST made is set, set a global, do a require, run ONE function, and then do ANOTHER require AFTER calling the function?

So we look at the first require in that, and it’s wp-load.php (2.28k) where it sets ANOTHER define that is nothing more than a alias to a split of a superglobal, an if statement that by all indications should NEVER trip unless some other code is repeatedly calling this same file (in which case why isn’t this in a FUNCTION), and then FINALLY they it actually loads the config file… only took three separate files to get to this point.

What type of idiocy justifies THAT?!?

It’s also chock full of “No ****” comments.

/** Define ABSPATH as this files directory */
define( 'ABSPATH', dirname(__FILE__) . '/' );

No, really?

if ( file_exists( ABSPATH . 'wp-config.php') ) {

	/** The config file resides in ABSPATH */
	require_once( ABSPATH . 'wp-config.php' );

Huh, is that why you’re requiring it from there?!? DOOEEY?!?

… and again, not a single function to be found in that file…

From there you have the total idiocy that is wp-config.php

BECAUSE PUTTING THE MYSQL USERNAME AND PASSWORD INTO DEFINES WHICH ENDS UP JUST LIKE SUPERGLOBALS MAKES THE SYSTEM SO SECURE!!!

That’s like driving a Caddy Escalade into South Central and leaving the doors wide open with the keys in the ignition.

It’s no wonder it won the 2008 Pwnie for M4ss 0wnage – things that are security BASICS they do the exact opposite at every step!

Secure information stored in defines?!? Sub-libraries that you can call directly and have it actually create output with most everything run outside of functions? So many entrance and re-entry points that it’s almost impossible to secure?!?

Much less when you get into the next file, wp-settings where it unregisters globals but then goes and screws around with storing a bunch of pointless nonsense in $_SERVER…

THEN of course you have this train wreck that is loaded EVERY time:

require (ABSPATH . WPINC . '/formatting.php');
require (ABSPATH . WPINC . '/capabilities.php');
require (ABSPATH . WPINC . '/query.php');
require (ABSPATH . WPINC . '/theme.php');
require (ABSPATH . WPINC . '/user.php');
require (ABSPATH . WPINC . '/meta.php');
require (ABSPATH . WPINC . '/general-template.php');
require (ABSPATH . WPINC . '/link-template.php');
require (ABSPATH . WPINC . '/author-template.php');
require (ABSPATH . WPINC . '/post.php');
require (ABSPATH . WPINC . '/post-template.php');
require (ABSPATH . WPINC . '/category.php');
require (ABSPATH . WPINC . '/category-template.php');
require (ABSPATH . WPINC . '/comment.php');
require (ABSPATH . WPINC . '/comment-template.php');
require (ABSPATH . WPINC . '/rewrite.php');
require (ABSPATH . WPINC . '/feed.php');
require (ABSPATH . WPINC . '/bookmark.php');
require (ABSPATH . WPINC . '/bookmark-template.php');
require (ABSPATH . WPINC . '/kses.php');
require (ABSPATH . WPINC . '/cron.php');
require (ABSPATH . WPINC . '/version.php');
require (ABSPATH . WPINC . '/deprecated.php');
require (ABSPATH . WPINC . '/script-loader.php');
require (ABSPATH . WPINC . '/taxonomy.php');
require (ABSPATH . WPINC . '/update.php');
require (ABSPATH . WPINC . '/canonical.php');
require (ABSPATH . WPINC . '/shortcodes.php');
require (ABSPATH . WPINC . '/media.php');
require (ABSPATH . WPINC . '/http.php');
require (ABSPATH . WPINC . '/widgets.php');

Much of which isn’t even used on most executions…

It’s spaghetti coding at it’s worst.

I’ve never experienced load time issues with Wordpress, but I have thought to myself that it could perhaps be coded / organised a little better.

At the end of the day it meets a need for a lot of people. A great free blogging platform that nothing else really compares to, and a simple way to turn a static site into a content managed site.

I’m pretty sure database access is faster than file access, for the simple reason that the database server caches a lot of results and queries in memory

Most OS have caching of normal disk access too; quite advanced in modern OS with file table cache, read ahead cache, write-back cache – and since database access IS disk access…

Net difference zero.

Yes, but database access is different to file access in the way the data is structured - it is quite specific in how things are stored, and a database server can be further optimised to take advantage of this specific method of storing things, especially in terms of caching queries. For the types of file caching you have stated, they don’t really apply in the same way as database caching.

There are a total of 76 files included with each pageview on a fresh installation of Wordpress using the default Twenty-Ten theme (77 on mine including a backup importer plugin). (…)

From the experiences I’ve had, this is the most common reaction of someone misunderstanding next-level systems. Themes and plugins are precursory levels of understanding, much like our nemesis “Hello World” is to us when we begin to learn some programming language. Few people on here can justifiably claim ownership of something equivalent to Wordpress (that has now been downloaded over 999,999,999 times). That said, it really boils down to business requirements… We can probably all agree that the 999,999,999 people could care less about the inclusions being used.

The point? Every system begins to get ugly when it begins to become successful. I call this the “Wolf_22 Principle”.