This is a meta-task to brainstorm actual tasks that could use Service Workers with the hope of improving performance.
Description
Related Objects
- Mentioned In
- T130779: [EPIC] Make Wikipedia pages available offline on mobile when ServiceWorker enabled
T106099: RFC: Page composition using service workers and server-side JS fall-back
T66721: mw.loader.store should not occupy all of localStorage - Mentioned Here
- T113066: [GOAL] Make Wikipedia more accessible to 2G connections
T117001: Increase mobile performance for 2G connections
T118041: Analysis data in MobileWebSectionUsage
T101732: Use Service Worker cache when available for ResourceLoader caching instead of LocalStorage
Event Timeline
I think we need to aim big here. I think we should be aiming to have a mobile site using the mobile API and service worker caching where available. Don't get me wrong, I think this is a big undertaking with many things to work out and trade offs to be made but I think it is doable as a stretch goal in a quarter.
T101732 seems a great way to get familiar with ServiceWorker and is more compact and achievable.
Would be great to dream up an even simpler low risk task than this to get all of us familiar with ServiceWorker (but I'm not sure what this would be yet).
For a simple getting started task to get us would stealing Jake's take offline button in his demo [1] work?:
- Could add a "take offline" button to all pages
- When clicked it generates a url to a special page that takes a parameter and uses ServiceWorker to intercept all our network requests from that page.
Benefits of this:
- isolated from rest of our infrastructure - so creates caching sandbox.
- Would feed nicely into the 'big goal'
See also T118041#1835201 : About 30% of our mobile web users currently have devices/browsers that could potentially support service workers.
@Tbayer that's pretty amazing already if you factor out iOS devices which I
think are around 45% of views.
The problem in mobile is going to be basically Apple. Without their support
the max % of SW enabled browsers will peak at around ~50% sadly.
There's also the point of enabling use of it to benefit millions and go to
the Webkit team to present a solid use case and see if we can play a part
in standardization of the technology.
If we use it in desktop, the support should increase highly soon when
Firefox rolls it out to stable.
Also it seems like Edge is considering implementation which is a good sign.
I can't fathom why this would be prioritized over T117001: Increase mobile performance for 2G connections.
Ori it's not and not sure where you got that impression - could you clarify? 2g is the goal and this is a soft dependency. It's linked as being blocked by this. (That's captured in T113066). The description even says this is a brainstorm.