I take most things with a grain of salt. One thing in particular keeps popping up and because of my web experience I just have to question and test what I’m being told. The tip in question is converting particular PHP tags into static HTML to speed up your site. It was #2 on Pro Blog Design’s post 10 Ways to Speed up Your WordPress Blog, but also an entire post in 13 Tags To Delete From Your Theme, on the same site. At first it seams like a valid tip… less PHP means faster processing and that leads to a faster load time, but I’m a theme developer and I love my code.
To test out this tip, I setup a quick test to see how long each method took. Being a developer, I actually new quite a few ways PHP could be mixed in with HTML, so I setup the four most common methods. They are: only static HTML, echo-ing static HTML, PHP only where needed, and echo-ing everything (static and PHP parts). The results were how it first seamed, static HTML is faster… 200 times faster to be honest. So… I thought it would be faster, it turn out to be faster, and yet I still questioned the tip.
Here’s why I questioned it. A page loading time is made up of a few factors, one of them is the server processing the PHP, but the code is going to be processed at a rate of billions of commands per second. Although one PHP command never equals one command in the CPU, that’s besides the point. Removing these suggested lines of code is not going to change the speed up your website at all, because it’s only a couple of commands.
The truth is, while it may be 200 times faster to use static HTML instead of PHP, the total time of the slowest one is 1/10,000th of one second. If you are worried about that amount of time, I’d like to point out that the human reaction time is 1/10th of one second. But I will not stop there, here is the biggest factor that kills this tip… caching. If you have any caching turned on, such as in Apache or a WordPress Plugin, then it doesn’t matter if your page is a HTML document or generated through PHP, because a static copy is going to be saved in memory and the actual line of code you changed is never going to be processed. Using caching is one of a dozen ways to really speed up your site and doesn’t require hunting through a WordPress Theme.
Nothing against Pro Blog Design, just against that one bad tip that I’ve seen around the web. Sometimes it’s a matter of calling out tips and seeing if they hold up to what they clame.
6 Comments
Hi Dan,
You’re absolutely spot on with the caching angle, that makes it a non-argument.
However, if you’re not using caching, then I’d try to limit the amount of PHP commands used. For one visitor, there won’t be any discernible difference, but if you get a lot of traffic and you’re on shared hosting, then every little bit counts.
Don’t forget that most of the ‘PHP commands’ that Pro Blog Design are talking about actually make database calls. It’s one thing if you’re using PHP to echo text, but another thing if you’re accessing the DB each time.
My two cents anyway…
@Stephen,
If their not using caching, then that’s what they should try and get, rather that changing their theme. Of course a lot of these methods depend on the options available.
As far as the PHP commands accessing the database each time, that’s not entirely correct. WordPress has its own cache built into the get_options function, meaning only one database request is made for each visitor, which is done by the wp_cache_get function. This don’t exclude the process time, but I think this single tip does little to nothing when compared to the other tips in terms of performance.
Hi Dan,
I understand what you’re driving at (“the original article isn’t correct, you shouldn’t be concerned with trivial details like that”) which I agree with, but I don’t understand what it is you tested, or what your environment was.
One thing stands out that makes me wonder what it is you measured — that you had a service time of 1/10000 second. This means whichever method that was, it can sustain 10K requests/second. 200 times that is then 2 million req/sec. If that’s complete page loads then that’s just insane performance.
Can you lend some insight into your testing methods?
Thanks,
Sean
@Sean,
I used the PHP microtime function to time how long that single line of code took to process. So it wasn’t the total time to process the page or to serve the page, but to process a single line of code.
Thanks Dan,
I’m not sure I agree with the testing method, but the conclusions and your comments about page caching are on the mark.
There’s a lot of misinformation out there about website scalability and speed, glad to see some people take it seriously.
Sean
Hey Dan
Thanks for testing that out – interesting to see what actual difference it makes. But, I’ll stand by what I said on PBD; the difference may be negligible or nothing, but hey, at least it’s good practice!