search

Automattic / jetpack

Security, performance, marketing, and design tools — Jetpack is made by WordPress experts to make WP sites safer and faster, and help you grow your traffic.
https://jetpack.com/
Other
1.58k stars 799 forks source link

Serve React bundle and admin CSS bundle remotely #5425

Open MichaelArestad opened 7 years ago

MichaelArestad commented 7 years ago

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

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

.

updated Wed Oct 26 17:01:07 PDT 2016

♜ ♞ ♝ ♛ ♚ ♝ ♞ ♜
♟ ♟ ♟ ♟ ♟ ♟ ♟ ♟
… … … … … … … …
… … … … … … … …
… … … … ♙ … … …
… … … … … … … …
♙ ♙ ♙ ♙ … ♙ ♙ ♙
♖ ♘ ♗ ♕ ♔ ♗ ♘ ♖

♚'s turn.
beaulebens commented 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").

samhotchkiss commented 7 years ago

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*
samhotchkiss commented 7 years ago

@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

rickybanister commented 7 years ago

We could perhaps kick this off as a pilot to take the place of the beta program?

MichaelArestad commented 7 years ago

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

dereksmart commented 7 years ago

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.

samhotchkiss commented 7 years ago

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.

oskosk commented 6 years ago

This is a year old issue and there have been different proposals for this admin page codebase. Relabeling as low priority.

gravityrail commented 6 years ago

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.

stale[bot] commented 6 years ago

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.

stale[bot] commented 5 years ago

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.