WordPress requests (that is, page requests) are something that can become a bit of a hot topic for those who are concerned about the performance of web applications.

Case in point: Last week, I was having a conversation with a friend who, at one time, was doing a lot of work with WordPress and has since moved into another industry of web application development.

During the conversation, he made the following comment:

And the fact that it doesn’t min / cat files instead of [25] network requests is just plain dumb. And when a person has 23 plugins, that’s 26 files not even including the theme and core.

I adjusted the number above to reflect how this particular site performs with my current theme and my [admittedly small] set of plugins.

Page Requests: 25 for this site alone.

25 Wordress requests for all resources for this site alone (along with a JavaScript error).

And though the comment is meant to be humorous and a bit facetious, I don’t think it’s worth dismissing.

In fact, I believe that it’s something worth considering even if we’re simply building things on top of WordPress (versus working on WordPress core).

The Reality of WordPress Requests

The first two points I’d like to make are this:

  1. HTTP/2 should help improve the number of requests that any site makes to the service, and this will ultimately change how we minify and concatenate our files. But for now, it’s not the standard. We shouldn’t dismiss the problem on account of something that will eventually [and hopefully] come to pass.
  2. This is in no way an attempt to structure any argument like “Well WordPress may do it this way, but look at what [whatever other] piece of software does!” This isn’t about anything other than WordPress.

With that said, I’ve said – in various posts and several times over – that when it comes to working with WordPress as a foundation for project development, I believe that it helps to look at it as a black box.

Sure, there are parts regarding WordPress core that can be changed and should be optimized and all of that. And there are the usual statements about backward compatibility that remain valid.

All of that aside, I still look at WordPress as a black box that provides a set of APIs that allow me to call into the application (and, by necessity, the database) and read and write data from it. This is no different than how I looked at the .NET framework or the Ruby on Rails library even though the latter was open source, too.

WordPress Requests and Ruby on Rails

Ruby on Rails on GitHub

Ultimately, when someone hires me or my team to work on a solution for them, then it’s about the quality of what I can build on top of it. They aren’t looking for me to educate them on the performance of WordPress – I assume they’ve made the choice to use it already and are now looking for additional work. And that’s my responsibility.

So when it comes to the number of requests for a given page or set of pages in WordPress, the responsibility falls on me to make sure that I’m creating the least impact as possible. That doesn’t mean I won’t have many JavaScript files, but I can combine and minify them into a single file so that it results in just one more request.

I can’t worry about what other plugin developers are doing. I can’t worry about that other theme developers are doing. I can get irritated about it, but what will that accomplish?

And though they may be polluting the amount of network traffic required to get a site to render or function, or though they may be working to optimize the amount of network traffic, I have to treat my work as somewhat of an island within the larger world of the CMS.

I can control only things that are within my parameters. And such is true for anyone who is building a solution that runs on WordPress

WordPress is For Us

As far as WordPress core is concerned, I do not believe that the core developers do not care about the number of requests.

In fact, I think the opposite. I think that the core team cares about the optimization of the application and work very hard to make sure that it’s as performant as possible. Take, for example, the implementation of system fonts in the last release.

You can also choose to use SCRIPT_DEBUG if you’re working in development so you get the unminified versions of JavaScript (thus shows that scripts are minified in core applications).

So passing the buck further upstream doesn’t hold any water.

Is there room for improvement? Sure. But I’ve yet to see a piece of software that doesn’t have room for improvement. Could there be fewer requests on a given page load? Sure. But that doesn’t mean that we’re not working towards it.

Accepting Our Responsibility

Ultimately, the point I’m trying to make is two-fold:

  1. In the comment that opened the post, I don’t believe my friend is wrong. Empirical data shows just how many requests a given page requires. But I also know that it’s a problem that’s being resolved.
  2. When it comes to providing solutions for others, we have a responsibility as developers to be responsible for the amount of data our solution needs to function. High-bandwidth internet access and caching is not an excuse for poor development practices. We need to focus on optimizations in the areas in which we can control.

When it comes to shipping products for WordPress, there are always going to be those that win out, because they offer every feature possible. And it’s a shame we can’t educate customers about this.

But we’re not in the business of customer education. At least, we’re not in that business outside of the solutions we’re providing for them.

So when it comes to working with WordPress, you have to accept that there’s already overhead in the application but it’s getting better. And we have to accept the burden – for lack of a better term, really – of being responsible developers with respect to the requests our solutions make.

Category:
Articles
Tags:

Join the conversation! 5 Comments

  1. Hey Tom,

    The main issue I see with WordPress is that it does not have a centralized assets pipeline. It has a very limited system to enqueue scripts and styles, but nothing to optimize these, or to add other stuff to the pipeline like images, fonts, etc…

    So, plugins cannot really provide assets in a way that creates an optimized end result for the site as a whole. You need to either eliminate all plugin additions and provide one custom, optimized pipeline yourself, or you need to rely on third-party optimization techniques “after-the-fact”, concatenating, minifying, uglifying, etc… in the hopes that you don’t break something.

    Something similar to Assetic would be needed that is made available by the WordPress Core, so that each plugin can provide the source files of its assets, and WordPress could then optimize them into a coherent whole.

  2. Hey guys,

    I believe there have been multiple attempts to address this pain point, one I’ve personally worked on in the past was Dependency Minification[1] plugin by Weston Ruter, it does collect the source files, pipe them to the popular Minify library ( and can probably be instructed to include more stops in the pipe to ), and get them in as few resulting files as possible, in a quite intelligent way taking into consideration the position and dependencies of each script.

    I wish WordPress Core would someday include the same functionality though, can’t think of any installation that might not benefit from such performance enhancements.

    [1] https://wordpress.org/plugins/dependency-minification/

  3. Really useful article, despite me not being the most savvy reader in terms of requests and protocols.

    One suggestion, your pull quote is really hard to read on mobile – might benefit from a bit of contrast!

    • Really useful article, despite me not being the most savvy reader in terms of requests and protocols.

      Thanks!

      One suggestion, your pull quote is really hard to read on mobile – might benefit from a bit of contrast!

      I’m planning to update themes soon and that should fix this problem.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.