Hi Terence,
Over time, better standards have been put into effect by both the WordPress community and Facebook, among the few. I learned to program PHP through extending the Genesis Framework, and that framework is very solid.
As a perfectionist, I strive to opt out of the easy way.
Many people have the attitude of “if it isn’t broken, don’t fix it”. I’d like to ignore that, and just continue to improve when possible, even if it only saves 15 CPU cycles.
Many programmers don’t think on hardware level. I did some calculations on the code of The SEO Framework which I have applied and therefore improved The SEO Framework’s performance up to 20% in version 2.5.2.
2.6.0 will add a lot of new requested and planned features, but will also contain further improvements to the already working code :).
Back to your question, why is it faster?:
First improvement:
It’s faster because it uses a little stronger Regex expression, but that only s(h)aves microseconds.
Second improvement:
The real improvement lies in that this plugin is trying to find the title in parts. Which is done with three checks.
From here, when the title has been found before wp_head is run (which is really early), the plugin stops and clears its buffer.
The content buffer might get huge if you continue searching until the footer.
The second buffer captures the wp_head action, some premium themes add the title within this action, which can cause problems.
If that fails, the rest of the page until the footer is put inside the buffer, which might be a little more intensive, but it’s very acceptable. The footer isn’t captured, which might contain a lot of scripts, capturing this might slow down things too.
Furthermore, the three checks are always run. But the second and third one run on already cached code from the first one.
Third improvement:
These checks will only run if the theme doesn’t support the latest standards. These standards have been introduced in WordPress 4.1.0 and they are easy to check for.
Fourth improvement:
The SEO Framework captures the title doing it wrong at execution, and saves it inside a transient, which is then cached on PHP level.
The only issue is is that when you switch your theme, the transient might be incorrect at first load. I’m looking for ways to improve this, but at the moment this issue is very minor.
Fifth improvement:
Other than that, this plugin is written to be perfect in every way, so instead of just looking for “does it exist”, we look for “is it exactly a boolean and is it true?”
E.g. when checking if the Output Buffer has started:
//* Multiple checks, checks if it's not false, '', 0, '0', array(), etc.
if ( $this->ob_started )
//* Is the same as, multiple checks:
if ( true == $this->ob_started )
//* This is fastest, three = signs, checks if it's exactly true.
if ( true === $this->ob_started )
It is not so easy to read, but it’s byte-code optimized. This is perfect when compiled, and even noticeable when using Opcode caching.
This way of programming is also done in The SEO Framework :). It might be more prone to bugs, but at the end of the day it might even save you time debugging.
In conclusion:
It took me 18 hours programming this, which could’ve been done in 3, but it’s worth it!
A wall of text, and I hope other programmers may find this useful :).
