Open MichaelArestad opened 7 years ago
I think technically we need to make this an opt-in, although maybe we could make the opt-in be part of the initial connection flow ("By connecting you agree to load stuff from WordPress.com..."), or just enable this as part of Jump Start/defaults that users do actually opt in to.
We would also need to be very careful about managing versions still. While we could make changes on our end without doing a new Jetpack release, we'd have to be sure that those changes were compatible with every possible version of Jetpack+WordPress that's loading those JS files remotely (e.g. if it relies on a new endpoint, or some new feature, or whatever, then we need to handle that in the update, and won't safely know that "version x of Jetpack contains y and z features").
The initial message from @MichaelArestad for posterity:
## The plan
Serve both our React JS bundle(s) remotely as well as the accompanying CSS. Serving these remotely could speed up the loading of the React bundle on sites, decrease load on hosts, allow for bug fixes without the need for a point release (also decreasing load on hosts), and allow for us to make/undo changes depending on feedback from the people using Jetpack.
## Requirements
- [ ] Needs to serve JS bundle from our CDN.
- [ ] Needs to serve admin CSS from our CDN.
- [ ] Need to be able to manage versions (and cache bust)
- [ ] Needs to be a way to opt out of using the remote bundles.
- [ ] Needs to have fallbacks for both that are bundle with JP. Fallbacks should be used in dev mode, if our CDN is down/blocked, or if a user opts out.
## Project management
We may use one of these new fangled Github projects to manage this. I'll leave that decision up to those assigned to work on this task.
## Designs
TBD. We need to design a way for people to opt out. It's probably going to be a setting somewhere. *shudder*
@beaulebens:
I think technically we need to make this an opt-in, although maybe we could make the opt-in be part of the initial connection flow ("By connecting you agree to load stuff from WordPress.com..."), or just enable this as part of Jump Start/defaults that users do actually opt in to.
Yep, I think that enabling it on connection is 👍 (no reason for it to rely on Jump Start, we're not changing anybody's front end)
We would also need to be very careful about managing versions still. While we could make changes on our end without doing a new Jetpack release, we'd have to be sure that those changes were compatible with every possible version of Jetpack+WordPress that's loading those JS files remotely (e.g. if it relies on a new endpoint, or some new feature, or whatever, then we need to handle that in the update, and won't safely know that "version x of Jetpack contains y and z features").
Agreed, the ONLY time we should alter the JS file that we're serving for a given version is if we're patching a security release.
I'm imagining endpoints like: http://i1.wp.com/jetpack/4.5.0/js/admin.min.js http://i1.wp.com/jetpack/4.5.0/css/admin.min.css
We could perhaps kick this off as a pilot to take the place of the beta program?
Agreed, the ONLY time we should alter the JS file that we're serving for a given version is if we're patching a security release.
@samhotchkiss Can you elaborate? Would this mean we couldn't fix some UI without pushing an update to the plugin (or things like that).
Not too optimistic we'll have time to get to this in time for 4.5, as we have other priorities still pending that take precedent.
While this is a good idea, I don't think it's realistic to have it on our docket ATM.
Moving it out of current focus, but hopefully we can come back around to it later in the year.
This is a year old issue and there have been different proposals for this admin page codebase. Relabeling as low priority.
This ticket conflates three very different things:
As such, it should be three different tickets IMO.
Serving assets from a CDN should be a photon-like module, perhaps one people can pay for. We can include some real smarts, for example by automatically identifying critical CSS by rendering the page above the fold using a headless browser and then splitting the CSS rules accordingly.
This issue has been marked as stale. This happened because:
No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.
This issue has been marked as stale. This happened because:
No further action is needed. But it's worth checking if this ticket has clear reproduction steps and it is still reproducible. Feel free to close this issue if you think it's not valid anymore — if you do, please add a brief explanation.
The plan
Serve both our React JS bundle(s) remotely as well as the accompanying CSS. Serving these remotely could speed up the loading of the React bundle on sites, decrease load on hosts, allow for bug fixes without the need for a point release (also decreasing load on hosts), and allow for us to make/undo changes depending on feedback from the people using Jetpack.
Requirements
Project management
We may use one of these new fangled Github projects to manage this. I'll leave that decision up to those assigned to work on this task.
Designs
TBD. We need to design a way for people to opt out (or in). It's probably going to be a setting somewhere. shudder
.