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