Improve loading of Customizer from front-end by leveraging `customize-loader.js`

[celloexpressions]

The Customizer loads "instantly" from the themes screen via customize-loader.js (loading via an iframe and displaying an animation as soon as it starts loading). This also means that the customizer can be exited instantly. With #25457, we're looking at doing this throughout the admin.

It turns out, we can also load the customizer more seamlessly from the front-end with customize-loader. It's just a matter of enqueuing the necessary (<10kb) resources for users who can customize and adding the customize-loader class.

This is a good first step that would enable us to better consider:

• Making the customize link more prominent in the admin bar (front-end and back-end, potentially), with a top-level text and icon placement.
• Changing the customize-load animation so that the controls slide-in, or similar, to better show the purpose of the customizer's front-end context (along with #28655).
• Improving customize-loader on the front-end by showing the existing page DOM in place of the iframe until the iframe loads (making it feel much quicker).

[celloexpressions]

Make customize-loader work on the front-end; a bit hacky.

[celloexpressions]

We could probably do it more elegantly (not sure what the best approach would be), but 28661.diff​ does this and shows how little it would require.

[celloexpressions]

Screencast demonstrating this: ​https://cloudup.com/cYpS76qTAk5.

As you can see, this is a good first step and my points above would make the experience much better once this is in place (especially temporarily treating the existing page as the preview, but preventing users from interacting with it).

[westonruter]

Using customize-loader to load up the Customizer is similar to #28602 (Transparently route frontend browsing through Customizer for logged-in editors).

Making the customize link more prominent in the admin bar (front-end and back-end, potentially), with a top-level text and icon placement.

I did something like this in the ​Customizer Everywhere plugin, at least in the admin bar.

[celloexpressions]

We probably shouldn't use the old DOM that triggered/loaded the Customizer if we do this. It won't have any of the customizations applied to it, so a new pageload would be necessary. Might as well do a full reload when exiting the Customizer, and switch to the most-recently-previewed page.

That being said, this is still a viable shorter-term solution while work on more experimental approaches like #28602 progresses.

[westonruter]

Replying to celloexpressions:

We probably shouldn't use the old DOM that triggered/loaded the Customizer if we do this. It won't have any of the customizations applied to it, so a new pageload would be necessary. Might as well do a full reload when exiting the Customizer, and switch to the most-recently-previewed page.

Actually, I don't think so. When you first load the customizer, the settings haven't been changed yet so they should be the same as the settings that were already applied to the page without the customizer being loaded. So I think the DOM can be re-used as the initial state for the Customizer preview, if possible.

[valendesigns]

This is something that would be very nice to have, but is not a priority right now. I'm also going to assume that the patch needs a refresh due to the age of it. We can circle back for an in-depth discussion after some of the more important features of 4.3 are sorted.

[westonruter]

Closing since I think we've concurred that we want to see less of customize-loader, not more (see #28536).