JS in Extreme Conditions: WebApps for the Refugee Aid Movement
summary
Production web app for refugee aid groups focuses on concrete wins: targets of <2s time to first paint (initial) and <5s to interactive, tested on a simulated 400 ms latency 400 kbps bad‑3G profile. Stack uses jQuery, Elixir/Phoenix, webpack, HTTP/2 and brotli, plus service workers and cache‑busting. Changes—gzip/brotli, HTTP/2, bundle splitting, image lazy‑load, offline caching—cut payloads and latency, achieve about 60% improvement, first paint ≈2s and interactive ≈4.5s then ~0.5s online and ~100ms offline; deployed and used to coordinate large shipments.
AI-written summary · about
chapters (13)
- 0:00Start
- 1:11The Refugee Aid Movement
- 12:12Slow Connection Warehouse - Office
- 13:28Performance Goals
- 14:22Product Goals
- 15:03'Business' Goals
- 16:38Our Stack
- 17:51Strategy - Minimize Power Use
- 20:24Strategy - Minimize Data Use
- 21:23Strategy - Improve Speed
- 25:00Baseline: Initial Load
- 28:00Speed Improvements: Initial Load
- 28:50Speed Improvements: Subsequent Loads
related talks
32mPractical Performance Tips Building Progressive Web Apps
41mHow we make Web Apps lightning fast at Microsoft!
01h 03mSpeed up your Web Application
42mBuilding quick apps in 2018
23mPerformance Optimizations for Progressive Web Apps
49mUX Patterns for Web Developers
32mComplex JS-heavy Web Apps, Avoiding the Slow
31mWeb Performance: The African Case