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?

@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.