Support » Requests and Feedback » 77 Files Included Per Page View! Insane!

  • I’ve been using WordPress for about 4 years now. In the past couple of years I’ve noticed that WP has become noticeably slower than it used to be.

    I am working on a custom theme for WordPress, so I downloaded the latest version (3.1) and installed it, imported posts from my production WordPress blog (to my dismay I had to install an importer to import WordPress’ own XML files because WordPress does not have this functionality by default!), and got up and running.

    During the installation process it seemed slow to me on my home computer which is much less powerful than the shared web server I am on. I didn’t think much of it until I tried viewing the blog. Slow!

    As a little test, I called PHP’s get_included_files() function in the default theme’s footer to see how many file includes there are. There are 77 files included on index and post page views–including the WordPress importer file which is certainly not needed when viewing the blog.

    This is insane! While WordPress is a nice script with lots of great features, whoever is designing this thing needs to take some computer programming classes or something because including that many files–especially files that are not needed–creates a huge amount of overhead. Efficient coding IS important–especially with interpreted code.

    When I develop a site, I try to keep the number of includes as few as possible. Every file included requires the server’s hard drive to seek for the file and that takes time. Hard drive access is the slowest part of the entire operation. If everybody was on a server with an accelerator that cached the opcode to RAM (assuming the entire script was cached and executed from memory), this wouldn’t be too much of a big deal. But we are not.

    index.php includes wp-blog-header.php which does NOTHING but to see if the $wp_did_header flag is set and if not, requires two more files and executes a function.

    Do you people not see how ridiculously wasteful this type of coding is???

    You would be MUCH better off stuffing more code into fewer files than having to go through the time-consuming process of including a file for only a few lines of code.

    Thanks for reading.

Viewing 6 replies - 1 through 6 (of 6 total)
  • There are many things you can do to optimize your loading times. The first thing I would recommend starting with is WP Supercache. This will preload the pages that way it doesn’t have to process things on the fly every time for content that doesn’t necessitate it. The functionality available in WordPress just isn’t doable any other way. Sure, things can be done to optimize the code and improve it in the core that will be fixed over time, but again take a consideration of what kind of plugins your site has to run every single time you load the page…

    He is talking about the base wordpress install and I totally agree, 77 includes is ridiculous.

    The functionality available in WordPress just isn’t doable any other way.

    of course it is.

    From a software architecture point of view, wordpress is absolutely terrible. This is not the developers fault as when wordpress was first written php was not as advanced as it is today as an object oriented language so certain design decisions were not available at the time.

    Reducing the amount of included files by consolodating some files is micro optimisation, it won’t make a huge difference to most sites but it is still an improvement that can easily be made.

    Where is there any documentation on the get_included_files() function mentioned in the Forum topic by cheesedude ? Thanks


    get_included_files() is a PHP function, as denoted by cheesedude. I just misread the reference. The function is documented in the PHP Manual:

    Using this function seems to be a good tip for debugging WP themes! Any comments on this? Thanks

    WordPress is great from a blogger’s viewpoint. I happen to like it a lot. It can be slow loading from a reader’s viewpoint (and sometimes from the admin’s viewpoint). And from a coder’s viewpoint, WordPress is one giant platter of spaghetti code. It’s ugly!

    I’ve been using WordPress for a few years now. The last time I created a theme (template, whatever you want to call it), I had very little experience with PHP and really didn’t know the difference between well-written code and poorly written code. I make websites for a hobby. With many hundreds (if not a couple thousand) of hours of experience learning about, reviewing existing code, and writing my own code, I can now say with a bit of knowledge that WordPress is very poorly written. I’ve read similar comments on webmaster forums by experienced PHP developers.

    Using memory caching via an accelerator to reduce loading time is not an option for the majority of bloggers, and is not for me. My web host does not have caching as I am on a shared server. And I am not going to use up all my allotted disk space caching blog pages to disk. Most bloggers are not on dedicated servers. Even if an accelerator is offered on a shared web host, with hundreds or thousands of other websites on the server, the PHP code is probably not going to remain in cache for long. That means often all 76 files that comprise the basic core of WordPress are going to have to be loaded from hard disk and that takes a significant amount of time. In between loading files for one WordPress blog, the server very well may processing requests for other sites. So it isn’t like the server stops doing everything else to process 76 includes for your site.

    WordPress is in serious need of a rewrite from the bottom up. That doesn’t mean that all the existing WordPress code needs to be trashed. I’m sure a lot of it could be reused in an object-oriented format using classes.

    Some have pointed out elsewhere that WordPress needs to maintain backwards compatibility so existing plugins and other features continue to work or whatever. If that is the case, then WordPress is only going to get more and more bloated and slower loading as time goes on. If each page view requires the loading of 76 include files now, what will the number be in a few years???

    PHP is not like C++ or other languages and you cannot code for it the same way. Languages like C++ are compiled. You could have 1000 included files and it will not matter because the compiler is going to create only one executable file or library. PHP, on the other hand, is not compiled, it is interpreted. The code has to be read from hard disk or from memory (if you have an accelerator), compiled, and executed every time someone views a page. This alone is a huge amount of overhead. The most time consuming part of it is loading the included files from disk. A typical web server can compile and execute thousands of lines of PHP code in the same amount of time it takes to seek and read one file from the hard drive. So having 76 files included on every page view is very inefficient.

    With interpreted languages like PHP, programming efficiency is much more important than with compiled languages. The goal should always be to reduce overhead as much as possible. Since file access is the most time consuming part of generating a webpage, that must be the place to start when optimizing a PHP application. If the core installation of PHP could reduce the number of included files from 76 to say 10 (or even 15), that would mean that 66 files would not be included making the blog much faster loading for the majority of webmasters who do not have caching on their servers.

    Another area for optimization is to not include files that are not needed or used. I mentioned in my first post that the WordPress importer file was being included on every pageview even though it is not being used by visitors to the blog. There is no excuse for inefficient programming like this! I could go on and on about what I saw in WordPress’ code that makes me shake my head like accessing basic variable information using function calls instead of variables such as wp_header(). But I’m not going to do that now.

    If others think that 76 file includes to view a page using the basic core installation of WordPress is horribly inefficient and wasteful, I would suggest they speak up and make some noise. Because as time goes on, WordPress code will only get uglier, more bloated, and slower loading. 76 included files on every page view now, maybe 100 in a couple years, and maybe 120 a couple years after that. It’s ridiculous, really.

    Lulio Sr: I’ve been writing PHP code as a hobby for over 5 years now and still learn new things every day.

    cheesedude – I encourage you to help out 🙂

    Start by following

    Join the IRC chats.

    Consider poking around in and see if you can put in some fixes etc.

    It would be very welcome.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘77 Files Included Per Page View! Insane!’ is closed to new replies.