Follow-up To Loading CSS And JS Conditionally
| Share |
First of all, I'd like to thank everyone who read and gave their 2 cents about the [Wordpress Plugin Development] How To Include CSS and JavaScript Conditionally And Only When Needed By The Posts post. The article was well received and will hopefully spark some optimizations around loading styles and scripts.
Here are some discussions and mentions around the web:
- an article on Weblog Tools Collection
- a forum post on WP Tavern
- twitter retweets
Sure, there are drawbacks to this method and it does require some more processing on the backend and it's not for everyone, which is why we should always strive for an even better solution.
I stand by my point of view that, for instance, my dedicated gallery shouldn't load for people who will never even go see my photos.
I think an ideal solution would be for WP core developers, who had a lot of experience designing Wordpress' internals and who know what can work and what can't, perhaps Matt included, to get together and think about a better solution really hard.
Conditional loading similar to the one discussed here is already possible in the admin area, which creates dynamic hooks by appending page ids to 'admin_print_styles' and 'admin_print_scripts'. It is, however, still not good enough to be used more generically because those hooks rely on the page you are on, rather than the content of that page.
Another possibility is using a PHP technique called output buffering (ob_start(), ob_flush(), etc) that grants second chances to data that had already been echoed. It intercepts all echo and print calls and redirects them into a memory buffer, so instead of printing data to the page right away, you can now modify the header even if it had already been processed. It's like giving it a second chance.
Would it work for Wordpress? I am not sure but I sure could use your feedback, devs.
His approach doesn't handle CSS which is why I decided to seek another solution but it doesn't require an extra pass through the posts and it benefits from using the shortcode API instead of stripos() or some hacky regex you'd need to come up with.
It's a great compromise for developers who do not want to take the approach I outlined in the article linked at the top of this page.
Artem Russakovskii is a San Francisco programmer, blogger, and future millionaire (that last part is in the works). Follow Artem on Twitter (@ArtemR) or subscribe to the RSS feed.
In the meantime, if you found this article useful, feel free to buy me a cup of coffee below.
beer planet is a blog about technology, programming, computers, and geek life. It is run by Artem Russakovskii - a local San Francisco geek who currently works at 
Artem loves commenting on other people's blogs and reading comments on his own, so go ahead and leave one.
*Always* avoid output buffering if you possibly can. It has a massive negative effect on page load times in most cases, and it's a memory and CPU hog to boot.
And yes, there are cases where it makes sense to not include your script code on every page. Like if you have a dedicated gallery system or something. Sure, that makes perfect sense.
But I think that *most* plugins will probably have some kind of impact on every page. You have to weigh the costs vs. the benefits. If you're only going to not load the code on 1 out of 10 pages, then it makes no sense to add expensive PHP loops to determine that.
Figure out your use cases first, don't just assume that this will always be faster, because it won't.
By all means – I never said it should be done all the time.
I think ideally, the plugin author would provide an option to do so, clearly explaining the trade-offs.
I use the wp-poll feature one time here, and yet it loads on every page – it could be better to optimize it.
However, if you run polls on the sidebar or on every other posts, you wouldn't benefit from this.
Again, I'd like to repeat: I don't think it should be white and black – there are clearly design decisions that need to be made by the authors and it's up to them to provide us with additional options, but if they don't know how to do it, they'll never even know to think of them, which is why discussions like this one here are invaluable.
Thanks for the feedback about output buffering. Do you have any benchmarks to back up the "massive" part?
I avoid output buffering like the plague because I'm on shared hosting & I know if I do that I will go over my CPU & memory limits very quickly. I only played with it on my computer.
Damn you, PHP!
This in the results from a very small test that I ran, just as an idea of how much of an issue this is. I displays a form & then parses the results. The time didn't really change much for the form but the memory did go up for buffering in all tests as I expected.
I remember in the books I've read that they suggest avoiding buffering like the plague, & to dump the buffer soon & often if you must resort to using a buffer at all.
Display form
no buffer
Memory usage in bytes 127416
Script executed in 0.0001 seconds.
with buffer
Memory usage in bytes 127840
Script executed in 0.0001 seconds.
display results
no buffer
Memory usage in bytes 129120
Script executed in 0.0067 seconds.
with buffer
Memory usage in bytes 129528
Script executed in 0.0766 seconds.
[...] I have posted a follow-up in response to some comments received around the [...]
[...] This post was prompted by this question from [...]
[...] This post was mentioned on Twitter by ArtemR, ArtemR. ArtemR said: Just posted Follow-up To Loading CSS And JS Conditionally: http://ping.fm/VVLbw [...]