How WordPress Plugins Should Handle Front End Resources

frontendplugins.md

How WordPress Plugins Should Handle Front End Resources

This is a WORK IN PROGRESS intended for fleshing out and feedback

It's very common for people to be unhappy with how a WordPress plugin adds front end resources to their site. If a plugin needs CSS, the plugin will add a <link> element to that CSS. If the plugin needs JavaScript, it will add a <script> to that JavaScript.

Plugins do this because it works. It's damn important for a WordPress plugin to work, even in adverse conditions. They rightfully want good ratings and little customer support.

But this comes at the cost of additional HTTP requests. In optimizing front end performance of a site, reducing the number of HTTP requests is a huge thing. Front end developers want to decide and control how front end resources are being handled, and WordPress plugins don't typically make this easy on them.

Here's an approach for plugin developers that can make everybody happy. The plugin still "just works" as well as it did before. But for people wanting to avoid those requests and deal with assets themselves, it allows that.

If the plugin needs CSS...

• Default to including it in the wp_head hook.
• Have a setting to not include it there, then provide the required CSS. Perhaps in a <textarea> for easy selecting and copy-and-pasting for the developer to put it somewhere in their own project.

If the plugin needs JavaScript...

• Default to including in the wp_footer hook.
• Have a setting to not include it there, then provide the required JavaScript. Perhaps in a <textarea> for easy selecting and copy-and-pasting for the developer to put it somewhere in their own project.

It might look something like this:

If the plugin needs images...

• Is it possible to not use images? If so, cool, do that.
• Can you use SVG? If so, cool, use inline <svg> where you can (e.g. you can use inline Data URI SVG in add_menu_page).
• If you need raster images (JPG, PNG, GIF), can you data URI them right into the code?
• Always optimize images with tools like SVGO for SVG or ImageOptim for raster images.

"Just use something to handle this for you!!"

There are plugins out there that concatinate assets for you. (examples: MinQueue and W3 Total Cache). I'm sure they do a pretty good job. But this shouldn't be the final answer. This isn't something automation is the perfect solution for in every case. What if they get the ordering wrong? What if you really need a particular as asset to load in a particular place? What happens on pages with a one-off script? Shouldn't it continue to use the presumably-well-cached script used on most other pages rather than make a new one?

A performance-focused developer can make the best decisions when it comes to what assets should be concatinated (and which shouldn't) for the best use of caching throughout the site.

Feedback

• Is all this factually correct?
• Is there anything that can be explained better? Is the terminology correct?
• Can we make an example plugin that demonstrates these concepts?

It's not a solution to this particular issue, but something that I think would help considerably, I'd like to see the 'Developers' pages on the WordPress plugin repo be opened up to allow plugin authors to add content to them using readme.txt.

Plugin authors could then use it to list all the assets their plugin loads to make it easy for another developer to un-enqueue them. They could also list any actions/filters provided, and anything else they think might help other developers/advanced users.

So essentially it's a one-page Codex for each plugin, so whenever I am working on a site and need to override or filter some stuff, the first place I'd check would be the developer page, rather than having to spend ages hunting around in someone else's code.

@NateWr Oh got it. I guess that makes sense. But if you were going to be extracting various styles or scripts and bringing them into your own process you might want a list of all scripts or styles that are loaded on any page. But that gets complicated quick I guess. I wonder if there is a way to quickly get any scripts or styles that are enqueued on the front-end from the back-end?

Random thought. Maybe the thing to do is have users dequeue scripts and styles from the front-end, and then have a list of Dequeued scripts on the back-end. So if I select a couple and remove them, I can hop over to a list in the back-end and click a "View Asset" link for each. What do you think? The user flow gets a bit confused I think, but for me that list with quick links would be essential.

I'm certainly not an expert plugin developer, but I can try to help out if you need it. Maybe I'll dig around sometime soon and see if I can make that happen.

But if you were going to be extracting various styles or scripts and bringing them into your own process you might want a list of all scripts or styles that are loaded on any page.

If I understood @chriscoyier before, this is precisely what he doesn't like about auto caching and minification scripts. He wants granular page-by-page info on the assets so that he can concatenate his assets in the way that he knows best. I'm no performance expert, but I think that means he probably wants that front-page asset load to be as small as possible (rather than including every possible asset), and then he can decide on a page-by-page basis what's the most efficient way to load other dependent assets.

Think, for instance, about a separate forum section on a site, which might have a large CSS load that is unnecessary for optimizing that first-time front-page load.

I'm hesitant to add a settings page to the admin panel when one isn't needed, simply because I feel the admin panel is already a giant sprawling mess of menu items. A debug tool should be as un-intrusive as possible. But I did run across a case for having some kind of admin-area fallback -- with the plugin its possible to dequeue jQuery, breaking the plugin and the admin bar and basically making it impossible to requeue it while the plugin is activated. So it may be worth having some kind of "restore default" option, but that could even just be added to the plugin links page.

If MinQueue gets the ordering wrong, it's not MinQueue's fault, is it? The enqueueing is done by the plugin and tf so are the prerequisites, so if it's an ordering issue, would that not fall back on the plugin dev?

Noting Jason's article so it's referenced here: http://tidyrepo.com/plugins-and-front-end-performance/

@NateWr is right, you can't access frontend assets in the admin area.
My solution was to scan plugins folders to find all JS and CSS files. It kinda works, but the list was really huge (with non-minified and minified versions of files).

I'm now working to put the existing plugin logic on front: https://dl.dropboxusercontent.com/u/4181800/lassets.png

@NateWr

I think that means he probably wants that front-page asset load to be as small as possible (rather than including every possible asset), and then he can decide on a

I don't see this as a big problem. The assets are downloaded once and then get 304 not modified, so the performance penalty is the first download, where gzip helps a ton to keep the size down, and of course parsing the JS and applying the CSS. Modern JS engines with JIT shouldn't have any lasting performance issues from this approach.

@theMikeD

If MinQueue gets the ordering wrong, it's not MinQueue's fault, is it? The enqueueing is done by the plugin and tf so are the prerequisites, so if it's an ordering issue, would that not fall back on the plugin dev?

I have seen some edge cases where minified JS does not execute properly with MinQueue. Generally those issues stem from improperly enqueued files or non-standard code practices, such as not waiting for document.ready in jQuery.

I think the solution to these issues is that plugin devs integrate with MinQueue (or a similar plugin like BWP Minify) through filters - that way the devs could have perfect control and be able to test that their plugins work properly when using the minification plugin.

When working with MinQueue, I have been able to get a site down to just 4 requests:

• 2 css requests (1 in header, 1 in footer)
• 2 js requests (1 in header, 1 in footer)

In theory, this is what every site could optimized down to!

@zoontek That plugin looks awesome, feel free to share it on GitHub! 👍

By the way, if you want to grab my previous work (that list everything in the admin section), you can find it here: https://dl.dropboxusercontent.com/u/4181800/lassets.zip
Feel free to add two search inputs and release it (without it, it's really hard to use) .

@zoontek, I like the layout in your screenshot. How are you determining which plugins an asset is enqueued by? How would you handle situations where an asset might be enqueued by two separate plugins (eg - dashicons)?

No reason for us to duplicate our work if we have the same objectives. The only thing that strikes me as problematic about the minimal menu UI you're using is that you can't really provide any contextual information. My UI was quite a bit heavier, but it gave me an opportunity to point out important things about some assets (like those that may only be enqueued by the admin bar) and provide a full-path.

ui-screenshot

Perhaps similar context data or options could be available in your UI via a modal?

@NateWr I'm just checking the plugin src to read the plugin folder, and only dequeuing plugins assets (you don't have to think about deps - you currently can't dequeue WordPress internal assets).

The path is available too, via a simple title: https://dl.dropboxusercontent.com/u/4181800/lassets2.png
The only utility i find for it is when a plugin enqueues two assets with the same name, but from differents folders.

@NateWr - I tried it out and it's pretty sweet!

I did manage to get myself into a situation where I had to go into the DB and manually edit the options. I dequeued the Open Sans and it kinda screwed up the admin bar to the point I couldn't use the plugin anymore =)

But this should do the trick I think!

@khromov

"I have seen some edge cases where minified JS does not execute properly with MinQueue. Generally those issues stem from improperly enqueued files or non-standard code practices, such as not waiting for document.ready in jQuery."

This also seems to come back to the original dev, right? It seems to me that creating a system like this is something that knowledgeable/responsible devs would use...but those aren't the problem IMHO.

It's a great tool to see what is being loaded in every page, no doubt. But if the author is not using wp_enqueu_*, that should be logged as a bug.

I wrote a plugin that uses modernizr and lets you adjust any properly loaded WordPress JS resources in how they're loaded (either not at all, via standard plugin/theme config or via modernizr). It will also let you force load a resource. https://github.com/nullvariable/advanced-modernizr

I'm just checking the plugin src to read the plugin folder, and only dequeuing plugins assets

Ah, I see. You can dequeue things like jQuery. And I imagine that's probably something the performance experts would want to do, if I'm not mistaken.

I did manage to get myself into a situation where I had to go into the DB and manually edit the options. I dequeued the Open Sans

Hehe, I did add a big scary warning when dequeueing jQuery, so I'll add it to the Open Sans as well. I'll also add that "reset to default" option I was talking about.

@NateWr - This is looking pretty good. I think you're probably right about wanting specific control, page by page. If anything, the back-end component is something that can be built out later.

Maybe as a simple fix, maybe it's a good idea to add the "View Asset" link to dequeued scripts as well. That way, even after they are dequeued, you can still easily go grab the asset and copy and paste it. Looking pretty solid.

Also, might as well tack dashicons css to the list of scary warnings, this can break the admin bar as well.

@NateWr - Maybe I'm over-thinking it, but it might be helpful to have some sort of export / import capability. Some plugins are just notoriously sloppy in their enqueue'ing. Or perhaps there can be a library (XML?) of suggested settings for any plugin that has been encountered and add to the list?

@webbelow said "The way I see it, all plugins should be designed for a perfect and clean HTML output."

How about a more view-y standard? Shouldn't / couldn't it be easy to do custom views for a given plugin? Especially for front-end facing, how many times have we heard "we like X and Y but can you change Z in the sidebar widget?" But changing Z more or less entails forking the whole plugin.

Sorry, if that just swerved a bit off-topic but if you can change Z then perhaps something needs to be denquue'd and then something else enqueue'd?

Asset Queue Manager is now available on the WordPress.org plugin repository. Please report bugs and feature requests at the GitHub repo.

@jasonhoffman I got the View Asset link back in there for dequeued assets.

@jasonhoffman @chriscoyier I chose to change how I handle the warnings/fallbacks a bit. There's no big scary popup when dequeuing a valuable asset, but there is a discoverable fallback when you disable jQuery or something vital. You can reset at any time from a link under the plugin in your list of installed/activated plugins. There's probably room for development on this front, but I'd like to see if people actually use the plugin much before sinking more time into it.

I have no idea how plausible this would be, but maybe it would be cool to offer the option to disable the included scripts & stylesheets (at least for the front end), and have the SASS, CSS, and JS available as a bower asset. Now, this wouldn't solve the problem for everyone, but it would allow sites with custom themes to bring the plugin assets in via bower and get it into their theme workflow so they can process it all as they wish.

Granted, even as I think of it now, I can think of all kinds of issues this could cause considering the varying workflows developers have. This also takes management out of the realm of WordPress and adds outside factors to influence 3rd party plugins and such. It could be hell to manage as the plugin developer and the end user. Especially so if the process gets too complex or convoluted.