Google's Alex Russell Warns Heavy JavaScript Paralyzes Mobile Web

Chrome for Developers

Thermal throttling and volatile cellular networks make desktop-style framework bundles unusable on median smartphones, requiring developers to adopt granular loading and cache-first architectures to avert load-time collapse.

AI-assisted summary of Progressive Performance (Chrome Dev Summit 2016) — original source. Check the original for full context.

Source published: 2016-11-11

Key ideas

The average mobile web page takes 19 seconds to load, while 53% of mobile users abandon sites that take longer than three seconds. (4:48)
Mobile CPU performance is throttled by strict 10-watt-hour battery limits and passive cooling envelopes that conduct heat 1,000 times less effectively than aluminum, causing mid-tier phones to execute JavaScript up to 10 to 25 times slower than desktop machines. (12:28)
Cellular network latency regularly exceeds 400 ms RTT in emerging markets, turning the web's traditional model of discovering dozens of sub-resources into a severe performance bottleneck. (23:41)
Server-side rendering on mobile often triggers an 'uncanny valley' where visible content renders quickly but remains entirely unresponsive to touch input while massive client bundles parse and execute on weak CPUs. (29:19)

Detailed notes

## Background Published by Chrome for Developers on YouTube on November 11, 2016, this Chrome Dev Summit 2016 session features Google engineer Alex Russell. The presentation focuses on essential mobile performance realities, highlighting techniques for building great web experiences across slow, inconsistent cellular networks and low-power hardware.

## TL;DR Alex Russell delivers an urgent reality check to web developers, arguing that the industry is in a mobile performance crisis caused by forcing desktop software architectures onto constrained handheld devices. He reveals how physical thermal limits, sluggish mobile flash storage, and volatile cellular radios crush performance, making synthetic desktop DevTools emulation dangerously misleading. Russell critiques oversized JavaScript bundles and server-side rendering workflows that trap budget devices in an unresponsive 'uncanny valley.' To build truly interactive Progressive Web Apps, he calls on developers to adopt the PRPL pattern, implement cache-first Service Worker shells, and rigorously profile on physical low-end hardware using tools like Lighthouse and Chrome tracing.

## Atmosphere & style The presentation carries a blunt, sobering, and urgent tone that deliberately contrasts with conventional developer conference cheerleading. Russell speaks with candid, almost exasperated intensity, walking the audience through an engineering grief curve using striking physical props like a disassembled Nexus 5X and a benchmark-boosting ice pack. The atmosphere feels like an essential industry intervention, balancing unvarnished critiques of popular frontend practices with rigorous, physics-grounded systems analysis.

## Bulletin - [04:48](https://www.youtube.com/watch?v=4bZvq3nodf4&t=288s) The average mobile web page takes 19 seconds to load, while 53% of mobile users abandon sites that take longer than three seconds. - [12:28](https://www.youtube.com/watch?v=4bZvq3nodf4&t=748s) Mobile CPU performance is throttled by strict 10-watt-hour battery limits and passive cooling envelopes that conduct heat 1,000 times less effectively than aluminum, causing mid-tier phones to execute JavaScript up to 10 to 25 times slower than desktop machines. - [23:41](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1421s) Cellular network latency regularly exceeds 400 ms RTT in emerging markets, turning the web's traditional model of discovering dozens of sub-resources into a severe performance bottleneck. - [29:19](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1759s) Server-side rendering on mobile often triggers an 'uncanny valley' where visible content renders quickly but remains entirely unresponsive to touch input while massive client bundles parse and execute on weak CPUs.

## Key takeaways - [00:05](https://www.youtube.com/watch?v=4bZvq3nodf4&t=5s) The web ecosystem fundamentally underestimates mobile difficulty by attempting to run desktop-scale architectures on constrained handheld devices without adapting toolchains. - [01:27](https://www.youtube.com/watch?v=4bZvq3nodf4&t=87s) To achieve acceptable performance, web applications should target full interactivity within three seconds on a 3G first load and under one second on repeat loads from the home screen. - [03:01](https://www.youtube.com/watch?v=4bZvq3nodf4&t=181s) Most web apps fail the RAIL performance model, which requires input responses under 100 ms, 8 ms JavaScript frame execution budgets, idle work chunked under 50 ms, and loads completed within one second. - [06:36](https://www.youtube.com/watch?v=4bZvq3nodf4&t=396s) Synthetic network and CPU throttling in desktop DevTools mask the mechanical bottlenecks of actual mobile hardware; real-device traces are the only source of ground truth. - [09:56](https://www.youtube.com/watch?v=4bZvq3nodf4&t=596s) Global smartphone adoption is driven by sub-$100 and sub-$300 hardware, making testing on high-end flagship phones a distorted reflection of real-world user conditions. - [12:28](https://www.youtube.com/watch?v=4bZvq3nodf4&t=748s) Power equals heat in compute physics; desktop cooling assemblies can dissipate 60 watts continuously, while smartphones must aggressively scale down voltages or shut off cores to prevent overheating. - [15:35](https://www.youtube.com/watch?v=4bZvq3nodf4&t=935s) Dark Silicon constraints and asymmetric ARM big.LITTLE architectures mean mobile devices operate primarily on lower-power cores, spooling up high-performance cores only briefly via heuristics like touch boosting. - [19:47](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1187s) Mobile operating systems optimize CPU clock boosts for native application launches, whereas web loads spend critical initial seconds waiting on networks while CPU cores throttle down to idle. - [21:47](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1307s) Mobile flash storage heavily lacks the multi-chip parallel controller throughput found in laptops, rendering mobile I/O speeds roughly comparable to 2008-era mechanical spinning disks. - [23:41](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1421s) Radio Resource Control state transitions on cellular networks can take seconds just to wake the hardware, meaning mobile networks inherently undermine desktop TCP protocol assumptions. - [27:11](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1631s) Monolithic client-side JavaScript Single Page Application bundles bypass native browser parser optimizations like speculative CSS parsing and off-thread document preloading. - [29:19](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1759s) Threaded background scrolling is not real interactivity; true interactive status requires responding to user taps within 100 milliseconds without main-thread jank. - [30:37](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1837s) The PRPL pattern avoids monolithic script execution by serving only the exact slice of code needed for the immediate view and chunking work into small, non-blocking tasks. - [31:56](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1916s) The primary performance benefit of service workers is not offline capability, but acting as a consistency engine that renders application shells instantly from cache to bypass network volatility. - [33:28](https://www.youtube.com/watch?v=4bZvq3nodf4&t=2008s) Engineering teams must test directly on real median hardware—such as a Moto G4 or Android One device—and enforce performance standards automatically via Lighthouse in continuous integration.

## Detailed walkthrough ### [00:05](https://www.youtube.com/watch?v=4bZvq3nodf4&t=5s) The Reality Check on Mobile Web Performance

Alex Russell opens his talk by warning the audience that this will not be the usual presentation he delivers. While he typically takes the stage to advocate for Progressive Web Apps—a term he and Frances Berriman coined the previous year—he clarifies that PWAs represent the culmination of years of deep architectural investment. He has worked alongside Jake Archibald on Service Workers for roughly four years, and his team has spent multiple Chrome Dev Summits building and standardizing the platform capabilities powering this movement. Maintaining and standardizing those primitives is a full-time endeavor, but the focus of this session shifts toward what happens when those capabilities collide with the messy realities of production.

For the past year, Russell has been collaborating with Thao Tran’s team, consulting directly with partner engineering organizations preparing to launch production Progressive Web Apps to ensure high quality. That advisory work provided an unfiltered view into how the broader web industry builds for mobile today. The findings were stark: aside from rare, disciplined standouts like Booking.com and Flipkart, the industry at large remains fundamentally out of touch with the operating environment of mobile devices. As Alex Russell puts it: “What I can say with only a few exceptions-- exceptions like booking.com and the great work that the Flipkart team did-- is that most of us don't really understand how hard mobile actually is.”

---

[01:27](https://www.youtube.com/watch?v=4bZvq3nodf4&t=87s) Clashing with Frameworks and the Birth of the PRPL Pattern

Speaking candidly about mobile performance has not won Russell many friends in the JavaScript framework ecosystem. However, he explains that his public warnings are simply the mild, "PG version" of blunt internal arguments he spent eighteen months having with Google's own Polymer team. Those engineering reviews were frequently tense. Russell would dissect performance traces and repeatedly push back on heavy runtimes, urging them to make execution more asynchronous, reduce payload sizes down to budgets like 12 KB, and break up monolithic script blocks that tie up the CPU.

Eventually, the Polymer team pushed back on the prescriptive micromanagement, asking him to stop dictating implementation details and instead provide concrete performance targets. That shifted the dynamic. Russell established a crisp, demanding baseline: a web application must achieve full interactivity within roughly three seconds on a first load over a 3G network, and become interactive within one second when launched from the home screen. The Polymer engineers subsequently traversed the classic five stages of grief—moving through denial, anger, bargaining, and quiet cube-bound depression before ultimately embracing the challenge and designing the PRPL pattern. Yet while internal teams adapted, the broader web development community continues to build without acknowledging these physical constraints.

```mermaid flowchart LR accTitle: Evolution to the PRPL Pattern accDescr: The progression from strict performance constraints to the stages of grief and finally the PRPL pattern architecture.

subgraph Constraints["Performance Target"] A["1st Load: <= 3s on 3G"] B["Repeat Load: <= 1s from Home Screen"] end

subgraph Grief["Stages of Grief"] C["Denial & Anger"] --> D["Bargaining & Depression"] D --> E["Acceptance"] end

subgraph Outcome["Architectural Pattern"] F["PRPL Pattern (Push, Render, Pre-cache, Lazy-load)"] end

Constraints --> Grief Grief --> Outcome ```

---

[03:01](https://www.youtube.com/watch?v=4bZvq3nodf4&t=181s) The Performance Crisis and the RAIL Budget

Addressing his reputation on social media, Russell clarifies that his sharp critiques and desperate-sounding tweets do not come from hostility toward JavaScript or UI libraries. He has invested years serving on TC39 to evolve JavaScript into a more capable language, championed extensibility to give web authors lower-level primitives, co-designed Service Workers to build client-side networking logic purely in JavaScript, and previously worked on the Dojo Toolkit alongside Scott Miles and Steve Orvell. His alarm stems from a genuine systemic failure across the ecosystem: “It's just that we're really in the midst of a crisis, and collectively, we don't understand how bad that crisis is.”

```mermaid flowchart TD accTitle: The RAIL Performance Model accDescr: Visual breakdown of the four pillars of the RAIL performance model and their respective timing thresholds.

subgraph RAIL["RAIL Performance Model"] R["Response Respond to user input in < 100 ms"] A["Animation 60 fps target (&sim;8 ms per-frame budget; 120 fps for WebVR)"] I["Idle Work Chunk background tasks into ≤ 50 ms blocks"] L["Load Deliver complete interactive user actions in < 1 s"] end ```

When evaluating real-world client applications through the lens of the RAIL performance model, virtually all incoming telemetry shows critical failures: - **Response (R):** UI events must process and deliver visual response to user input within 100 milliseconds. - **Animation (A):** Running at 60 frames per second requires maintaining an 8-millisecond JavaScript execution budget per frame once browser rendering and compositing overhead are deducted (a challenge that becomes drastically harder at the 120 fps required for WebVR). - **Idle (I):** Background execution must be scheduled in discrete chunks of no more than 50 milliseconds to keep the main thread available for unpredictable user gestures. - **Load (L):** Applications must complete user actions in under one second; exceeding this window breaks user flow and task focus, requiring immediate visual acknowledgement if execution takes longer.

---

[04:48](https://www.youtube.com/watch?v=4bZvq3nodf4&t=288s) The 19-Second Average and the Desktop Hangover

The business cost of ignoring these budgets is quantifiable and severe. Referencing DoubleClick research cited earlier in the keynote, Russell highlights the steep commercial penalty for slowness: “53% of users bounce from mobile sites that take more than three seconds to load.” In spite of this cliff, real-world field data indicates that the average mobile web page takes an astonishing 19 seconds to reach completion. Rather than an anomaly, trace reviews consistently expose sites that function as outright performance disasters.

Russell attributes this failure to a fundamental industry refusal to respect mobile constraints. The web stands alone among major software ecosystems in attempting to take its entire desktop architectural stack and cram it onto handheld hardware without adjustment. Native platforms never attempted such an inheritance: - Developers do not take desktop Java Swing JARs and run them directly inside an Android application. - Desktop macOS Universal Binaries are not ported directly to an iPhone. - Legacy Win32 desktop binaries were not dumped straight onto Windows Phone.

Across native ecosystems, changing the physical form factor and runtime envelope forced developers to adopt entirely new architectures, languages, and runtime paradigms. As Alex Russell observes: “Everybody else switched their tools when their form factor and their constraints changed.” The web development community skipped that pivot, leaving standard toolchains and popular frameworks emitting software that is unacceptably slow by default.

---

[06:36](https://www.youtube.com/watch?v=4bZvq3nodf4&t=396s) DevTools Emulation vs. Real Hardware: The I/O 2015 Benchmark

A major factor behind this blindness is that software engineers rarely develop or profile on actual mobile hardware. Surveying the audience, Russell notes that while nearly everyone uses Chrome DevTools responsive emulation, far fewer profile against remote devices via WebPageTest, and only a tiny minority regularly use `chrome://inspect` over USB for on-device debugging. He warns that software CPU and network throttling inside desktop DevTools are mere approximations that mask the true mechanical bottlenecks of mobile silicon. As Alex Russell emphasizes: “It turns out that DevTools emulation is nothing like real devices.”

To illustrate this disparity, Russell analyzes the Google I/O 2015 web application—a cutting-edge Polymer 0.5 Progressive Web App that pioneered early push notifications. When running on high-end desktop hardware (a MacBook Pro) over conference Wi-Fi, the app delivers a stellar user experience: - `DOMContentLoaded` and meaningful paint fire at 700 milliseconds. - `onload` occurs shortly after, kicking off an aesthetically pleasing, buttery-smooth transition animation. - Total JavaScript execution time is kept to approximately 500 milliseconds. - The interface achieves full interactivity around the 4-second mark, including the runtime of the intro animation.

Running that exact same web application on the exact same Wi-Fi network using a mid-range mobile device—a Nexus 5X—completely shatters performance: - `DOMContentLoaded` is delayed until the 2-second mark. - `onload` stalls until 6 seconds into the session. - A massive, blocking JavaScript evaluation ties up the single main UI thread for nearly two uninterrupted seconds. - Overall script execution balloons to four seconds, causing dropped frames and choppy animations. - Time to Interactive (TTI), as recorded by Lighthouse, stretches out to 7 seconds.

Russell notes that when engineering teams see traces pulled directly from real mobile hardware, they are uniformly shocked. Most engineers assess performance through the lens of the high-end flagship iPhone in their pocket, remaining completely unaware of the thermal limits, sluggish mobile flash storage, and weak single-core CPU speeds governing the median global device—compounded by the erratic behavior of real-world cellular radio networks.

[09:56](https://www.youtube.com/watch?v=4bZvq3nodf4&t=596s) The Truth Is in the Trace and the Reality of Global Hardware

Alex Russell reflects on spending the past year breaking hard truths to fellow software engineers, easing them along an emotional grief curve so they can eventually make it through to the other side. Confronting the reality of real-world device performance requires serious work, but without making fundamental changes to development practices, the web simply will not work for the next billion users entering the digital ecosystem. For Alex, cutting through developer optimism comes down to an essential rule: the trace is the only source of ground truth. Desktop emulators and synthetic assumptions fall completely flat; the only meaningful performance data comes from attaching DevTools and Chrome tracing directly to physical, low-spec hardware running on constrained networks.

To stay anchored to this reality, Alex carries a dedicated bag of test hardware inside his daily bag at all times. Except for a single high-end Pixel XL, every phone on his desk retails for under $300 new, and data from Nigerian e-commerce platform Konga shows that the median device in their market costs less than $100 brand new. Alex places zero faith in desktop profiling unless software is actively verified on real, sluggish hardware with emulated 3G connections. Furthermore, vendor marketing sheets actively mislead developers: comparing a MacBook Pro clocked at 2.8 GHz against a Nexus 5X clocked at 1.8 GHz suggests a modest difference on paper, yet JavaScript execution runs ten times slower on the phone despite both machines utilizing flash storage. Dismissing the temptation to test solely on flagship Silicon Valley hardware, Alex reminds developers that rich consumers already own smartphones, and median global adoption is driven by aggressively cheap devices. As Alex puts it: “If you think the $700 iPhone in your pocket is what people are going to be adopting in the next couple of years at the median, you're delusional.”

- Worldwide average selling prices for smartphones are trending down rather than up because first-time buyers purchase strictly at the lowest economic margin. - Global network connections and median hardware profiles are becoming slower on average, making modern mobile hardware testing essential to prevent building what Bruce Lawson termed the "Wealthy Western Web."

[12:28](https://www.youtube.com/watch?v=4bZvq3nodf4&t=748s) The Physics of Compute: Power, Heat, and the Ice Pack Experiment

To demonstrate the massive gap between mobile and desktop execution, Alex examines MotionMark, a graphics and JavaScript-heavy benchmark released by Apple earlier in 2016. On identical desktop hardware running macOS, Chrome ties or beats Safari, demonstrating that the browser engine itself is not inherently slow. However, running that exact same benchmark on the mobile Nexus 5X reveals that the desktop version executes 25 times faster. Curious about device variability, Alex managed to boost the Nexus 5X's MotionMark score by a staggering 15% with a single physical modification: strapping a makeshift ice pack to the back of the phone. The hack was inspired by his colleague Victor, who had observed massive variance between benchmark runs while investigating performance optimizations.

The ice pack works because of basic computing physics: computers are networks of wires with electrical resistance, voltage, and current that release heat every time a transistor switches state. Generating computation inevitably generates excess thermal energy measured in BTUs. Under identical microarchitectures and transistor budgets, the chip that can dissipate the most heat is the chip capable of performing the most mathematical operations per second. While a desktop processor can rely on a large finned heat sink, thermal paste to eliminate air gaps, and chassis fans to comfortably evacuate roughly 60 watts of power under load, a mobile device cannot replicate that environment. As Alex explains: “When it comes to computing, power is literally power, and power equals heat.” Mobile devices cannot operate at desktop speeds because holding a 60-watt heat source in the palm of one's hand would cause physical burns.

- Apple's MotionMark benchmark exercises graphics rendering pipelines but remains heavily constrained by raw JavaScript execution speed. - Desktop-class cooling assemblies rely on direct thermal paste seating to eliminate insulating air gaps, which would otherwise cause the silicon to overheat and fail. - A standard 60-watt desktop thermal dissipation envelope is physically impossible on handheld smartphones without scorching the user.

[15:35](https://www.youtube.com/watch?v=4bZvq3nodf4&t=935s) Inside the Mobile Guts: Thermal Throttling, Dark Silicon, and big.LITTLE

Dissecting a dead Nexus 5X that recently failed and emitted "the magical blue smoke," Alex exposes the severe mechanical limitations of mobile hardware. Unlike desktop computers where the CPU, GPU, and system memory occupy separate boards or distinct areas of the motherboard, the smartphone places its entire system-on-a-chip (SoC) beneath an aluminum heat spreader on the reverse side of the power supply. The CPU module is not even visible because it is stacked directly underneath a Samsung RAM chip. For thermal energy to escape the processor, heat must conduct through the RAM package, cross an internal air gap to a thin aluminum shield, and finally seep out through two completely separated layers of polycarbonate plastic casing—a material that dissipates heat 1,000 times less efficiently than aluminum. Without active cooling, sustained heavy computation quickly pushes core temperatures toward destructive thresholds, forcing chip designers to rely on dynamic voltage and frequency scaling (DVFS) and aggressive core shutoffs.

```mermaid flowchart TD accTitle: Nexus 5X Internal Thermal Dissipation Path accDescr: Step-by-step physical path heat must travel to escape from the mobile CPU to the surrounding air. subgraph ChipAssembly["Internal Stacked Assembly"] CPU["Mobile CPU Die"] -->|"conductive heat"| RAM["Samsung RAM Package"] RAM -->|"traverses package casing"| Shield["Thin Aluminum Shield"] end subgraph ExteriorCasing["Chassis Layers"] Shield -->|"radiates across"| AirGap["Internal Air Gap"] AirGap -->|"trapped heat"| Plastic["Polycarbonate Back Cover (2x Layers)"] Plastic -->|"1,000x slower dissipation"| Ambient["Ambient Air / User Hand"] end ```

These physical bottlenecks validate the predictions of a 2011 research paper titled *Dark Silicon and the End of Multi-core Scaling*, which foretold that substantial fractions of mobile silicon would have to remain unpowered due to thermal and power constraints. Furthermore, mobile form factors are limited by battery energy density: a standard phone battery holds only about 10 watt-hours of energy. If depleted at the rate of a 60-watt desktop chip, the battery would die in minutes or violently explode. Because that small battery must simultaneously sustain the CPU, GPU, cellular radio, Wi-Fi, Bluetooth, NFC, screen backlight, and touch digitizer for an entire day, modern mobile architectures rely heavily on ARM big.LITTLE configurations. Mobile operating systems employ complex kernel schedulers, such as the Global Task Scheduler, to aggressively offload background tasks to low-frequency cores while utilizing heuristics like "touch boosting" to temporarily spool up high-power cores the instant a user's finger touches the glass. Reflecting on the predictive accuracy of the dark silicon research, Alex observes: “While perhaps not intended to be, it reads like a prophecy from half a decade ago about the experience that we're all carrying around in our phones, where a huge percentage of the silicon in our devices isn't actually available to be used, thanks to the power and thermal constraints.”

- Polycarbonate plastic conducts heat approximately 1,000 times less effectively than aluminum, trapping thermal energy inside the handset. - A standard smartphone battery contains roughly 10 watt-hours of total energy, making power conservation the primary constraint for all processing tasks. - Mobile systems rarely feature symmetric multiprocessing; instead, kernel schedulers constantly migrate threads across asymmetric high-power and low-power CPU clusters to conserve energy and reduce heat. - Touch boosting heuristics preemptively ramp up clock speeds on primary high-performance cores the moment input is detected on the digitizer to keep touch interactions and fling animations smooth.

[19:47](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1187s) Why Mobile CPUs Don't Match Web Workloads

Mobile operating systems optimize their central processing units around launching native applications. When a user taps an icon on the home screen, the operating system aggressively powers up the high-performance CPU cores so the application launches instantly. The web's workload behaves in the exact opposite manner: a user taps a URL, the device sits idle waiting on network responses, the processor cores scale back down into low-power states to preserve battery, and only then does content arrive to be processed. This creates a severe mismatch between how mobile hardware is designed and how web browsers actually operate.

```mermaid flowchart TD accTitle: Mobile Workload Mismatch accDescr: Comparison between native app launch behavior and mobile web page loading stages.

subgraph Native ["Native App Launch"] N1["User taps app icon"] --> N2["Big cores scale up immediately"] N2 --> N3["Fast app launch"] end

subgraph Web ["Web Page Workload"] W1["User taps URL"] --> W2["Device waits on network"] W2 --> W3["Cores throttle down to idle"] W3 --> W4["Content arrives / parsing starts"] end ```

Benchmark figures that equate mobile CPUs to desktop performance fail to reflect reality because they ignore thermal throttling and power scaling. While a laptop or desktop computer can dissipate heat through dedicated fans and large heat sinks, mobile devices cannot maintain maximum clock speeds under prolonged load. As Alex points out: “The idea that your mobile phone CPU is as fast as a desktop CPU may be true in the limited case, but not in the common case.”

- A MacBook Pro carries a 100 watt-hour battery—the maximum capacity permitted on a commercial flight by the FAA—and its fan-cooled architecture can dissipate between 40 and 60 watts continuously across four active cores. - Mobile phones rely on ARM big.LITTLE architectures; even an octa-core device like the Moto G4 rarely runs more than three cores simultaneously under real-world conditions. - Core counts and raw megahertz ratings mask huge disparities in cache size, pipeline depth, memory bandwidth, and in-order versus out-of-order execution dispatch.

[21:47](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1307s) The Reality of Mobile Storage: Spinning Disks from 2008

Developers often assume solid-state flash memory inside an Android device running a Linux kernel delivers desktop-caliber I/O performance. In reality, mobile storage relies heavily on Multi-Level Cell (MLC) flash packaged in high-density, low-cost configurations. Solid-state drives achieve high throughput through parallelism—distributing read and write operations across multiple independent chips connected to an intelligent memory controller.

Because mobile phones face intense physical volume constraints and strict thermal limits, manufacturers consolidate storage down to minimal chip packages, often routing all operations through a single die. This absence of multi-chip parallelism devastates storage throughput: while a MacBook Pro solid-state drive can read data at 2 gigabytes per second, a contemporary phone like the Nexus 5X manages roughly 400 megabytes per second. Alex summarizes the practical consequence: “Basically, what you should think about the median mobile phone having is spinning disk from 2008.”

- MLC architectures stack silicon layers inside a single physical package to minimize production costs at the expense of raw random access speed. - Consolidating storage into fewer chips reduces power consumption and saves board space, but bottlenecks drive latency and bandwidth. - Mobile operating system file systems have not caught up to overcome these hardware constraints, leaving flash I/O on mobile comparable to vintage mechanical hard drives.

[23:41](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1421s) Mobile Networks Are Kryptonite to the Web

While mobile storage speeds are disappointing, cellular networks represent an even more acute bottleneck. Referring developers to Ilya Grigorik’s book *High Performance Browser Networking*, Alex explains that modern cellular networks fundamentally undermine the core architectural assumptions of TCP and the World Wide Web. Protocols designed for stable, predictable copper and fiber connections break down in environments characterized by continuous fluctuations in latency and packet loss.

Cellular radios constantly transition between power states and cell towers, causing round-trip time (RTT) and available bandwidth to gyrate from millisecond to millisecond. The web's traditional model of discovering and hot-linking dozens of external sub-resources completely falls apart when users ride public transit or travel in cars. Alex summarizes the friction: “Cell networks are basically kryptonite to the protocols and assumptions that the web was built on.”

```mermaid flowchart LR accTitle: Cellular Radio State Wake-Up Latency accDescr: The step-by-step latency barrier from cellular radio handshake to web request dispatch.

subgraph RRC ["Radio Layer"] A["Low-Power / Idle State"] --> B["RRC Handshake (Up to seconds)"] B --> C["High-Power Radio Active"] end

subgraph WebStack ["Network Protocols"] C --> D["DNS Lookup"] D --> E["TCP Handshake"] E --> F["TLS Negotiation"] F --> G["HTTP Request / Response"] end ```

- US cellular LTE speeds actually degraded year-over-year as networks absorbed heavier user loads, refuting the idea that LTE upgrades solve performance issues on their own. - While DevTools defaults 3G network emulation to a 100 ms RTT (standard in the United States), median RTT in major emerging markets regularly exceeds 400 ms. - Severe RTT balloons the bandwidth-delay product, meaning long latency suppresses data transfer rates regardless of nominal channel capacity. - Under Radio Resource Control (RRC) protocols, waking a cellular radio from a low-power state on a 3G network can take multiple seconds of physical-layer handshaking before DNS, TCP, and TLS handshakes can even begin.

[27:11](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1631s) The Heavy Framework Trap and Using the Platform

Compounding volatile radio connections and slow storage with oversized client-side JavaScript packages produces disastrous user experiences. Data from the HTTP Archive indicates that the top 1,000 websites routinely serve almost a megabyte of uncompressed JavaScript to mobile clients. The outcome is a widespread user perception that the mobile web is fundamentally sluggish and broken.

Alex argues that attempting to build Progressive Web Apps by transplanting desktop Single Page Application patterns—shipping massive bundles that show a loading screen before rendering—fails on mobile devices. Single-threaded JavaScript execution stalls the main thread, prevents the browser's native preload scanner from discovering nested sub-resources, and stops the browser engine from speculatively parsing HTML or constructing the DOM. Alex issues a direct challenge to mainstream development choices: “Except for the tiny club of fast-enough-by-default tools, like the Polymer App Toolbox and Preact, with some good webpack foo, today's framework's are mostly a sign of ignorance, or privilege, or both.”

- Progressive Web Apps must prioritize loading less code overall, loading code strictly when needed, and delegating work to native browser capabilities rather than large JavaScript polyfills. - Heavy JavaScript architectures that mimic full-screen desktop applications like Gmail impose massive upfront execution delays that cannot be compensated for by subsequent client-side navigation speed. - Relying on runtime JavaScript rendering bypasses built-in browser optimizations such as off-thread parsing, speculative CSS parsing, and the native document preload scanner.

[29:19](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1759s) The SSR “Uncanny Valley” and the True Meaning of Interactive

When code has to execute on a single core of a mobile phone that is thermally throttled or stuck in a low-power state, the developer's odds are grim. In response to these mobile performance bottlenecks, the industry has turned heavily toward server-side rendering (SSR)—alternatively rebranded over time as "isomorphic rendering" or "universal JavaScript." Alex pokes fun at the constant churn of buzzwords, asking the audience with a laugh whether there is already a new name for it. The core mechanic of SSR remains the same: run JavaScript on the server to generate a pre-computed HTML snapshot, ship that markup down, and then deliver a gargantuan client-side JavaScript bundle behind it while crossing your fingers that everything works out.

While SSR delivers an acceptable user experience on high-powered developer hardware like a modern MacBook Pro, an iPhone on high-speed connectivity, or a high-end Pixel, it creates an unbearable "uncanny valley" for the global median user on budget hardware and spotty networks. The moment that massive script bundle finally downloads and hits the main thread, the browser locks up completely. Although text and imagery might appear on screen, the page remains completely unresponsive until the JavaScript parses, compiles, and completes execution. Alex rejects the industry argument that threaded scrolling constitutes interactivity, pointing out that background compositor scrolling is just browser magic. True interaction requires low-latency responsiveness to user touch. As Alex sharply puts it: “If I can't put my finger down and tap on your UI, and have it start responding and doing work for me under 100 milliseconds, it isn't loaded.”

```mermaid flowchart TD accTitle: Server-Side Rendering Uncanny Valley on Mobile accDescr: Flow diagram showing how server-rendered HTML displays static content before a massive JavaScript bundle blocks the main thread.

subgraph Server["Server Phase"] A["Execute Universal / Isomorphic JS"] --> B["Generate pre-computed HTML snapshot"] end

subgraph Client["Client Execution on Budget Hardware"] B --> C["HTML displays on screen (Visible content, threaded scroll works)"] C --> D["Download gargantuan JS bundle"] D --> E["Main thread locks up entirely (Parse & compile on weak CPU)"] E --> F["Uncanny Valley: Taps drop & UI breaks"] F --> G["Fully interactive (> 100ms response)"] end ```

[30:37](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1837s) PRPL, Granular Loading, and Mobile-First Architecture

To overcome this trap, applications must deliver progressive interactivity. This is achieved via the PRPL pattern (Push, Render, Pre-cache, Lazy-load), an architecture championed by Sam Saccone and demonstrated in the Polymer App Toolbox. The core architectural philosophy is simple: transmit only the precise slice of code required for the current view immediately in front of the user. By combining granular resources, HTML Imports, and HTTP/2 Push instead of shipping monolithic bundles, applications can finally avoid over-bundling and implement true mobile-by-default performance.

Alex illustrates this contrast by examining the Polymer team's Shop demo app (`shop.polymer-project.org`). On a desktop browser over Wi-Fi, the app achieves interactivity within milliseconds using negligible script time. On a mid-tier Nexus 5X running on that same Wi-Fi connection, the app reaches an interactive state in under two seconds despite the weaker CPU. Although the total execution time across the entire app run reaches nearly 1.5 seconds of script, that work is never dropped onto the main thread as a single monolithic block. Instead, it is sliced into tiny, granular execution segments. Because each component loads and executes in micro-slices, whatever content is already rendered on screen never freezes up, preserving touch responsiveness throughout the load lifecycle.

[31:56](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1916s) Service Workers for Reliable Speed and Enforcing with Lighthouse

Alex emphasizes that developers fundamentally misunderstand the primary value of service workers. While the offline fallback capability is technically impressive, it is not the main benefit for real-world end users. The real value lies in providing completely predictable, reliable performance. By taking control of top-level document requests and serving the application shell instantly from cache, a service worker completely neutralizes network latency and bandwidth volatility.

```mermaid flowchart LR accTitle: Service Worker Caching Architecture accDescr: A comparison showing how a Cache-First Service Worker eliminates unpredictable network swings compared to a Network-First pass-through.

subgraph Good["PRPL App Shell (Recommended)"] A1["Top-level Navigation"] --> B1["Service Worker Cache"] B1 --> C1["Instant App Shell Render (Zero network dependency)"] end

subgraph Bad["Network-First Anti-Pattern (Discouraged)"] A2["Top-level Navigation"] --> B2["Network Request Pass-through"] B2 --> C2["High latency variability & stalls"] end ```

Alex references performance data compiled by Eric Bidelman from the Google I/O Progressive Web App (built with Polymer 1.0). In that dataset, enabling the service worker caused the entire distribution of load times to shift sharply to the left, concentrating user loads in the fastest performance tier. Alex issues an urgent plea against treating service workers as simple network-first transparent proxies: “Use the PRPL pattern, and make sure that your top-level app shell never depends on the network.” Adopting this cache-first app-shell structure is the only way a web application can achieve the instant launch times of native applications—a milestone Darren demonstrated earlier in the summit keynote with the CNET Tech Today PWA.

- Service workers should be treated as performance consistency engines rather than mere offline fallbacks. - Never use a network-first, pass-through strategy for top-level application navigation shells. - To ensure apps do not regress on Progressive Web App requirements, developers should integrate Lighthouse directly into their CLI workflows and continuous integration (CI) pipelines.

[33:28](https://www.youtube.com/watch?v=4bZvq3nodf4&t=2008s) Embracing the Hardware Reality and Overcoming Slow-by-Default Tools

Mobile web performance is significantly more challenging than the developer ecosystem has traditionally recognized. Meeting this challenge requires teams to alter their priorities, update their tooling, and look directly at ground-truth operational metrics. The fastest way to shatter desktop-centric illusions is to test on actual mobile hardware. Alex urges every developer to acquire a mid-range device representative of the global median, recommending a circa-2014 Android phone like the Motorola Moto G4. Inspecting sites running on a physical phone via `chrome://inspect` in Chrome DevTools forces developers to experience the friction real users face every day. For teams wanting an even clearer view of market conditions, Alex brandishes an entry-level Android One device from the previous year, advising developers to find the slowest hardware they can, or use the real device pools hosted on WebPageTest (`webpagetest.org`).

Alex closes by acknowledging that his message may sound like a downer compared to typical optimistic talks celebrating PWAs, but insists that facing reality is necessary to unlock the modern web's true capabilities. Achieving world-class performance will require teams to abandon or aggressively overhaul "slow-by-default" frameworks and patterns, noting that Addy Osmani's upcoming session will dive into the heavy elbow grease required to make today's mainstream frameworks run adequately on mobile. He leaves the audience with a challenge: now that the true scope of the mobile hardware constraint is exposed, developers have the knowledge and tools—such as PRPL, Lighthouse, and Chrome telemetry—to build genuinely great, resilient web experiences.

## Notable quotes > [29:19](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1759s) If I can't put my finger down and tap on your UI, and have it start responding and doing work for me under 100 milliseconds, it isn't loaded. — Alex Russell

> [23:41](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1421s) Cell networks are basically kryptonite to the protocols and assumptions that the web was built on. — Alex Russell

> [09:56](https://www.youtube.com/watch?v=4bZvq3nodf4&t=596s) If you think the $700 iPhone in your pocket is what people are going to be adopting in the next couple of years at the median, you're delusional. — Alex Russell

> [06:36](https://www.youtube.com/watch?v=4bZvq3nodf4&t=396s) It turns out that DevTools emulation is nothing like real devices. — Alex Russell

> [21:47](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1307s) Basically, what you should think about the median mobile phone having is spinning disk from 2008. — Alex Russell

> [31:56](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1916s) Use the PRPL pattern, and make sure that your top-level app shell never depends on the network. — Alex Russell

> [19:47](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1187s) The idea that your mobile phone CPU is as fast as a desktop CPU may be true in the limited case, but not in the common case. — Alex Russell

## Mentioned Alex Russell, Frances Berriman, Jake Archibald, Thao Tran, Scott Miles, Steve Orvell, Victor, Ilya Grigorik, Sam Saccone, Eric Bidelman, Addy Osmani, Bruce Lawson, Polymer, Polymer App Toolbox, Preact, Webpack, Dojo Toolkit, Chrome, Chrome DevTools, Lighthouse, WebPageTest, MotionMark, Service Worker, PRPL pattern, RAIL, Dark Silicon and the End of Multi-core Scaling, High Performance Browser Networking, Booking.com, Flipkart, Konga, CNET Tech Today, Google, Apple, DoubleClick, TC39, Nexus 5X, Pixel XL, Motorola Moto G4, Android One, MacBook Pro

## Video description Alex shows us the important things to focus on in performance, and how to run great experiences on slow, inconsistent networks and low-power devices.

Links: Kevin Schaaf's talk on the PRPL pattern: https://goo.gl/vgaup0 Documentation on how to use chrome:inspect for testing on real-world devices: https://goo.gl/T1C4xe The "Dark Silicon and the End of Multi-core Scaling" paper (PDF): https://goo.gl/3ogsHD Ilya Grigorik's essential "High Performance Browser Networking": https://hpbn.co/

Watch more recordings from Chrome Dev Summit '16 at: https://goo.gl/TkgXYM Subscribe to the channel: https://www.youtube.com/chromedevelopers Music by Terra Monk: https://goo.gl/xolmTV

[Source](https://www.youtube.com/watch?v=4bZvq3nodf4)

中文简报

谷歌工程师 Alex Russell 警告：庞大的 JavaScript 正在瘫痪移动端网络散热节流与不稳定的蜂窝网络导致中端智能手机无法承受桌面级框架包，开发者须采用细粒度加载与缓存优先架构以避免加载崩溃。 Alex Russell 向 Web 开发者敲响警钟，指出该行业正面临移动性能危机，原因在于将桌面软件架构强加于受限的掌上设备。他揭示了物理散热限制、缓慢的移动闪存以及不稳定的蜂窝网络如何重创性能，使得基于桌面 DevTools 的模拟测试具有危险的误导性。Russell 批评了体积过大的 JavaScript 包和让廉价设备陷入无响应“恐怖谷”的服务端渲染流程。为了构建真正具备交互能力的渐进式 Web 应用（PWA），他呼吁开发者采用 PRPL 模式，实现缓存优先的 Service Worker 外壳，并借助 Lighthouse 和 Chrome tracing 等工具严格在低端物理硬件上进行性能剖析。移动网页平均加载时间长达 19 秒，而 53% 的移动用户会放弃加载超过 3 秒的网站。 (4:48) 移动 CPU 性能受到 10 瓦时电池上限和导热效率比铝低 1,000 倍的被动散热外壳的严格制约，导致中端手机执行 JavaScript 的速度比桌面电脑慢 10 到 25 倍。 (12:28) 新兴市场的蜂窝网络往返延迟经常超过 400 毫秒，使得 Web 传统的解析数十个子资源的模式变成了严重的性能瓶颈。 (23:41) 移动端的服务端渲染往往会引发“恐怖谷”效应，即虽然可见内容渲染迅速，但由于羸弱的 CPU 仍在解析和执行庞大的客户端代码包，页面完全无法对触控输入做出响应。 (29:19)

Reading summary

Alex Russell argues that the mobile web suffers from a systemic performance crisis because developers rely on desktop-oriented toolchains and emulators, ignoring the physical hardware, thermal, and network constraints governing median global smartphones. The Desktop Hangover and Emulation Blindness (4:48) Russell states that while native platforms transitioned to new architectures and languages when moving to mobile, web development attempted to port its desktop stack directly onto handheld devices. The commercial impact is severe: DoubleClick data shows 53% of mobile users abandon sites taking longer than three seconds to load, yet real-world mobile pages average 19 seconds. The web community often misses this gap by profiling through desktop Chrome DevTools responsive emulation rather than physical hardware. Contrasting the Google I/O 2015 web app across environments demonstrates this divide. On a MacBook Pro over Wi-Fi, the app achieved DOMContentLoaded at 700 milliseconds, executed roughly 500 milliseconds of JavaScript, and reached interactivity around four seconds. On a mid-tier Nexus 5X over the same Wi-Fi, DOMContentLoaded slipped to two seconds, an uninterrupted main-thread script evaluation locked the device for nearly two seconds, total script execution reached four seconds, and Time to Interactive stretched to seven seconds. Physical Constraints: Thermals, Silicon, and Storage (12:28) Mobile performance gaps stem directly from computing physics. While a desktop processor can evacuate roughly 60 watts of heat with finned heat sinks, thermal paste, and chassis fans, a smartphone is restricted by hand safety, thin polycarbonate casings that dissipate heat 1,000 times less effectively than aluminum, and approximately 10 watt-hour batteries. Apple's MotionMark benchmark ran 25 times faster on a desktop than on a Nexus 5X; strapping an ice pack to the phone boosted its score by 15%, demonstrating the onset of thermal throttling. These thermal limits validate 2011 research on 'dark silicon,' which showed that significant portions of mobile processors must remain unpowered. Mobile operating systems employ ARM big.LITTLE architectures and dynamic task schedulers that power up cores on touch input but scale back down while waiting on networks. Furthermore, mobile flash storage relies on consolidated Multi-Level Cell (MLC) packages that lack the multi-die parallelism of desktop solid-state drives. While a MacBook Pro SSD reads data at 2 GB/s, a Nexus 5X manages roughly 400 MB/s, leaving mobile I/O comparable to 2008 spinning hard drives. Cellular Network Realities and the SSR Trap (23:41) Cellular networks exacerbate hardware bottlenecks by destabilizing core protocol assumptions. Under Radio Resource Control (RRC) protocols, waking a cellular radio from an idle state on 3G can take multiple seconds of physical handshakes before DNS, TCP, and TLS negotiation begin. While DevTools defaults 3G emulation to a 100 ms round-trip time (RTT), median RTT in major emerging markets regularly exceeds 400 ms. These delays inflate the bandwidth-delay product and penalize top-1,000 sites that routinely ship nearly a megabyte of uncompressed JavaScript to mobile clients. Russell cautions that server-side rendering (SSR) often creates an 'uncanny valley' on budget hardware. Although SSR delivers visible HTML early, shipping a monolithic client bundle behind it locks up the weak, single main thread during compilation and evaluation. While users can see static content and invoke threaded scrolling, the interface drops tap gestures and fails the RAIL response budget until script execution finishes. True interactivity, Russell argues, requires responding to user touch within 100 milliseconds. Architectural Solutions: PRPL and Service Workers (30:37) To counter monolithic script execution, Russell advocates the PRPL pattern (Push, Render, Pre-cache, Lazy-load) developed during work with Google's Polymer team. In the Polymer Shop demo running on a Nexus 5X, slicing nearly 1.5 seconds of total script into granular execution units enabled the application to become interactive in under two seconds on Wi-Fi without blocking touch events. In addition, Russell emphasizes that service workers should be utilized as performance consistency engines rather than mere offline fallbacks. Relying on network-first pass-through proxies exposes applications to radio latency and bandwidth volatility. Implementing a cache-first app-shell structure ensures instant startup regardless of network conditions, which teams should continuously verify by integrating Lighthouse into automated continuous integration pipelines. Russell concludes that web teams must abandon slow-by-default frameworks and test against ground truth using physical, mid-range devices like the Moto G4 or WebPageTest pools. Relying on flagship hardware or synthetic desktop profiles conceals the thermal, storage, and radio bottlenecks experienced by the median global user.

精炼阅读摘要

Alex Russell 指出，现代 Web 开发界由于依赖桌面思维和高阶设备，严重脱离了全球移动硬件与蜂窝网络的物理现实，必须转向以 PRPL 架构和真实设备性能追踪为核心的渐进式性能实践。桌面惯性与移动性能危机的脱节 (0:05) Russell 强调，原生平台在转向移动端时全面重构了工具栈与架构，但 Web 开发社区却试图将庞大的桌面单页应用（SPA）技术栈直接塞入移动设备。DoubleClick 的数据显示，移动页面加载超过 3 秒会导致 53% 的用户流失，然而现实中移动网页的平均完成加载耗时高达 19 秒。HTTP Archive 数据亦表明，排名前 1,000 的网站常向移动端推送近 1 MB 未压缩的 JavaScript 代码，这直接违背了 RAIL 性能模型中加载需在 1 秒内完成、交互响应需低于 100 毫秒的基本指标。开发人员普遍依赖桌面 Chrome DevTools 的软件节流模拟，但这种模拟掩盖了真实的机械瓶颈。在测试 Google I/O 2015 渐进式 Web 应用时，高端 MacBook Pro 在 Wi-Fi 下的 JavaScript 执行时间仅约 500 毫秒，交互时间约为 4 秒；而在中端 Nexus 5X 上，同网络环境下的主线程脚本评估被阻塞近 2 秒，总脚本执行膨胀至 4 秒，Lighthouse 测得的交互时间延迟至 7 秒。多数工程师习惯使用 700 美元的高端手机，忽视了全球中位数设备性能偏低的常态。计算物理学：散热限制与不对称核心 (12:28) 移动计算的核心瓶颈受制于物理学：功耗即热量。桌面处理器拥有散热片、导热硅脂和风扇，能持续排出约 60 瓦的功率；而智能手机电池容量通常仅约 10 瓦时，若以桌面功率放电会导致电池在数分钟内耗尽甚至爆炸。拆解 Nexus 5X 发现，其系统级芯片（SoC）被堆叠在 RAM 下方，热量必须穿透铝屏蔽罩、内部气隙以及导热效率比铝低 1,000 倍的聚碳酸酯塑料外壳。在 MotionMark 测试中，桌面端执行速度可达 Nexus 5X 的 25 倍，而给手机加贴简易冰袋可将该基准跑分提升 15%，证实了计算受热节流的严重压制。由于散热和电量限制，移动芯片广泛遵循《Dark Silicon》论文的预言，大量芯片区域无法全功率供电。移动设备依赖 ARM big.LITTLE 异构架构与内核调度器在大小核之间频繁迁移线程，并依赖“触摸加速（touch boosting）”瞬时拉高频率。然而移动系统的优化是针对瞬时启动的原生应用，Web 工作负载却是“点击链接后等待网络——CPU 降频至低功耗空闲——内容突然到达导致单核被阻塞”，软硬件设计在此产生严重冲突。慢速存储与动荡的蜂窝无线电环境 (21:47) 开发者常误以为 Android 上的闪存能提供桌面级 I/O，但移动设备为了节省空间和成本，采用高密度单芯片封装的 MLC 闪存，缺乏桌面 SSD 依靠多芯片通道实现的并发吞吐能力。MacBook Pro 的 SSD 读取速度可达 2 GB/s，而 Nexus 5X 仅约 400 MB/s，其实际 I/O 表现相当于 2008 年左右的机械硬盘。这意味着移动端大体积脚本的文件读写与解析极为缓慢。蜂窝网络则是 Web 协议的“氪石”。无线电资源控制（RRC）协议在 3G 状态下从低功耗唤醒就需要数秒的物理层握手，随后才能展开 DNS、TCP 和 TLS 协商。DevTools 默认的 100 毫秒 3G 往返时延（RTT）仅反映美国标准，新兴市场的往返时延经常超过 400 毫秒，过长的 RTT 会严重压缩数据传输率。加之无线电功率切换与基站漫游造成的抖动，Web 传统贪婪拉取数十个外部子资源的设计在移动端极易崩溃。绕开 SSR 恐怖谷与落地 PRPL 架构 (29:19) 为缓解性能瓶颈，业界转向服务端渲染（SSR/同构 JavaScript），即先发送预渲染 HTML 快照再下发庞大脚本。Russell 指出，在弱算力设备上，这会导致严重的“恐怖谷”效应：页面虽呈现文本但主线程被长脚本解析编译锁死，无法在 100 毫秒内响应触摸，合成器滚动的平滑掩盖了界面无法真正交互的假象。庞大的客户端捆绑包还会阻碍原生预加载扫描器、推测性解析和跨线程优化。应对方案是由 Polymer 团队实践的 PRPL 架构（推送、渲染、预缓存、延迟加载）。以 Shop 演示应用为例，通过将代码拆分成极小片段并按需分片执行，即便在 Nexus 5X 上总脚本耗时近 1.5 秒，也能在 2 秒内达到可交互，且无长时间的主线程单次锁死。同时，Service Worker 不应仅视作离线容灾工具，而应作为消除网络波动的性能引擎，采用缓存优先策略加载顶级 App Shell，使 Web 应用拥有与原生一致的确定性启动速度。构建面向下一个十亿用户的现代 Web 应用，核心在于直面真实硬件的物理约束。Russell 呼吁工程团队放弃“默认缓慢”的重量级框架方案，配备如 Moto G4 或百元级 Android One 等真实低端设备，结合 Chrome 跟踪、WebPageTest 真机池以及 CI 流程中的 Lighthouse 审计，以追踪数据作为唯一基准来评估与优化真实用户体验。

Detailed notes — zh

## Background 该视频由 Chrome for Developers 官方频道于 2016 年 11 月 11 日在 YouTube 上发布。内容记录了 Chrome Dev Summit 2016 上 Alex Russell 的演讲，页面简介指出，Alex 重点探讨了性能优化的核心要素，并分享了如何在低速不稳定的网络与低功耗设备上打造极致的 Web 体验。 ## TL;DR Alex Russell 揭示了移动端 Web 开发所面临的严峻性能危机，直言全网移动网页平均 19 秒的加载时间已严重脱离 RAIL 模型。他从物理硬件底层切入，剖析了移动设备受制于散热瓶颈、暗硅限制、MLC 单通道闪存读写以及恶劣的蜂窝网络 RRC 状态机等现实约束。Alex 尖锐批判了当下盲目滥用重型 JavaScript 框架与同构渲染带来的“恐怖谷效应”，并强调开发者必须告别昂贵旗舰机测试的特权偏见。他呼吁行业全面拥抱 PRPL 架构模式与 Service Worker，以精细化代码切片与离线缓存保障确定性性能，真正服务全球中低端设备用户。 ## Atmosphere & style 整场演讲严肃、直接且极具警示意味，Alex Russell 毫不粉饰太平，直面行业痛点，自嘲充当了一次“扫兴者”。他带领听众经历了一段从直面真相、打破幻象到接纳现实的“悲伤之弧”，现场穿插着解剖手机、贴冰袋降温等生动硬核的物理学与硬件案例，既有理科生的严密推导，又有对前端社区盲目膨胀的辛辣批判。观看过程令人如坐针毡却又醍醐灌顶，最终在呼吁重构工具链与坚守工程底线中收尾，充满了呼唤全行业回归理性的力量感。 ## Bulletin - [03:01](https://www.youtube.com/watch?v=4bZvq3nodf4&t=181s) 移动端开发面临极其严峻的性能危机：全网移动端网页平均加载时长高达 19 秒，而超过 3 秒加载就会导致 53% 的用户流失。 - [09:56](https://www.youtube.com/watch?v=4bZvq3nodf4&t=596s) 桌面端与移动端存在巨大的物理硬件鸿沟，受制于散热上限和 10Wh 电池容量，中端手机即使标称主频相近，脚本执行速度也往往比桌面端慢 10 倍以上。 - [21:47](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1307s) 移动设备的闪存因低并发读写特性，实际 I/O 表现仅相当于 2008 年的机械硬盘，加之蜂窝网络 RRC 协议与高延迟，巨型 JavaScript 包在移动端注定引发体验灾难。 - [29:19](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1759s) 服务端渲染（SSR）在弱网和低配机上常陷入“恐怖谷效应”，即视觉虽有展现但主线程锁死导致无法交互，团队需转向 PRPL 模式以达成渐进式可交互。 ## Key takeaways - [03:01](https://www.youtube.com/watch?v=4bZvq3nodf4&t=181s) Web 是整个计算领域唯一试图将桌面开发工具链和范式直接生搬硬套到移动端的平台，引发了深重的体验危机。 - [06:25](https://www.youtube.com/watch?v=4bZvq3nodf4&t=385s) 桌面 Chrome DevTools 的网络与 CPU 模拟节流无法替代真机，必须通过 USB 连接中低端设备（chrome://inspect）抓取真实 Trace。 - [09:56](https://www.youtube.com/watch?v=4bZvq3nodf4&t=596s) 全球智能手机的平均售价呈下降趋势，面向“下一个十亿用户”的开发必须以 100 至 300 美元的中低端设备作为测试基准。 - [14:25](https://www.youtube.com/watch?v=4bZvq3nodf4&t=865s) 受限于无法在手持状态下散发数十瓦热量，手机内部缺少主动散热和充足导热路径，芯片会因过热保护而发生剧烈降频（DVFS）。 - [17:35](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1055s) 移动设备电池通常仅有约 10Wh，迫使系统广泛采用 big.LITTLE 异构大小核架构并极度激进地压低核心频率以保全续航。 - [21:47](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1307s) 移动端高度集成的 MLC 闪存缺乏桌面 SSD 的多通道并发读写能力，中端机 I/O 吞吐仅相当于 2008 年的旧式旋转机械硬盘。 - [23:36](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1416s) 蜂窝网络的底层无线资源控制（RRC）协议为了省电会使基带频繁休眠，物理握手延迟直接推高了真实往返时延（RTT）。 - [27:11](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1631s) 主流网站向页面推送近 1MB 未压缩 JS 的现状不可持续，深锁在庞大 JS 中的资源会破坏浏览器的预加载扫描器与并行解析能力。 - [29:19](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1759s) 服务端渲染在低端设备上易产生“恐怖谷”假象：若页面在点击后不能在 100 毫秒内做出响应，这种可交互性就是虚假的。 - [30:37](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1837s) PRPL 模式通过按需切片加载关键资源、结合 HTTP/2 Push 与延迟加载，确保已有视图能够在 2 秒左右持续保持完全可交互。 - [31:56](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1916s) Service Worker 的核心意义不在于单纯的离线访问，而在于彻底消除网络抖动，为顶层 App Shell 提供确定性且秒级返回的加载体验。 - [33:28](https://www.youtube.com/watch?v=4bZvq3nodf4&t=2008s) 团队应抛弃“默认缓慢”的开发模式，将 Moto G4 等老旧机型作为基准，并把 Lighthouse 和 Telemetry 纳入 CI 以守住性能红线。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=4bZvq3nodf4&t=0s) 艰难的坦白：移动端开发的严峻现实 Alex Russell 登台并向现场开发者坦言，今天的内容不同于他以往的常规演讲，其中会包含不少令人难以接受的残酷真相。通常情况下，他会站在台上大谈 Progressive Web Apps（PWA）。这个概念由他和 Frances Berriman 在前一年共同命名，凝结了他与 Jake Archibald 在 Service Worker 上投入的四年心血，也是他的团队多年来构建核心 Web 技术的结晶。但他今天并不打算直接讲 PWA 的好消息。在过去一年里，Alex 与 Thao 及其团队合作，为即将上线 PWA 的外部团队提供技术咨询，确保其产品质量。正是这段顾问经历，让 Alex 得以深入观察当今移动 Web 开发团队的普遍现状。除 Booking.com 和 Flipkart 团队等少数典范外，大多数团队的表现暴露了一个巨大认知盲区。Alex 直截了当地指出这一现实：“What I can say with only a few exceptions-- exceptions like booking.com and the great work that the Flipkart team did-- is that most of us don't really understand how hard mobile actually is.” ```mermaid flowchart TD accTitle: 移动端性能认知与现实的鸿沟 accDescr: 展示Alex Russell从PWA研发转入一线咨询，发现行业面临严峻移动性能危机的过程 subgraph Background["背景积累"] A["4年 Service Worker 研发"] --> B["与 Frances 命名并推广 PWA"] end subgraph Discovery["深入一线排查"] B --> C["深入外部团队开展 PWA 咨询"] C --> D["审查真实移动 Web 性能 Trace"] end subgraph Reality["行业现实"] D --> E{"直面真相"} E --> F["绝大多数团队不理解移动端有多难"] E --> G["极少数特例: Booking.com, Flipkart"] end ``` --- ### [01:27](https://www.youtube.com/watch?v=4bZvq3nodf4&t=87s) 与 Polymer 团队的交锋及 PRPL 模式的诞生因为公开指出前端框架的性能弊端，Alex 在 JavaScript 框架社区里树敌不少。即便是对同在 Google 的 Polymer 团队，这也绝非客套话。在长达一年半的时间里，双方开过多次气氛极度紧张的会议。Alex 在审查 Trace 时不断向他们施压：“代码必须更异步”、“必须少加载 JavaScript”、“12KB 的体积才算合理”、“拆分脚本，别让整个长任务把主线程卡死”。争执一度陷入僵局，直到 Polymer 团队打断他并表示：“别再教我们怎么写代码了，直接告诉我们应该达到的性能指标。” 这一转折打破了冷战。Alex 当即定下了硬性考核指标：在 3G 网络下的首次加载必须在 3 秒左右达到可交互状态；从主屏幕二次启动时，必须在 1 秒左右完成交互就绪。听到这个严苛的目标后，Polymer 团队经历了一轮典型的心理悲伤五阶段（否认、愤怒、讨价还价、沮丧到最终接纳）。他们最终接受了挑战，并探索出了 PRPL 架构模式。然而，整个前端 JavaScript 社区却远远没有建立起对性能限制的同等敬畏与认知。 - **3G 首屏交互目标**：首次加载交互耗时需控制在约 3 秒（Interactive in ~3s）。 - **二次启动交互目标**：从主屏幕再次启动，需在约 1 秒内完成可交互（Interactive in ~1s）。 - **PRPL 模式演进**：推送关键资源（Push）、渲染初始路由（Render）、预缓存剩余路由（Pre-cache）、按需延迟加载（Lazy-load）。 --- ### [03:01](https://www.youtube.com/watch?v=4bZvq3nodf4&t=181s) RAIL 性能模型与 19 秒的行业灾难 Alex 澄清自己并非憎恨 JavaScript 或否定前端框架。他常年在 TC39 委员会为改进 JavaScript 语言特性而奔走，倡导平台可扩展性，并且亲手主导了纯依赖 JavaScript 的 Service Worker 设计；早年他还与 Polymer 团队的 Scott 和 Steve 一起写过 JS 工具库。问题在于，前端生态正在陷入一场深重的性能危机，整个行业对此却毫无觉察：“It's just that we're really in the midst of a crisis, and collectively, we don't understand how bad that crisis is. If we did, we would have already modulated our behavior.” 根据 Chrome 团队提出的 RAIL 性能模型，优秀的 Web 应用必须遵循严格的时间预算： 1. **Response（响应）**：在 100 毫秒以内响应用户输入。 2. **Animation（动画）**：保证 60fps 刷新率；除去浏览器自身的排版绘制开销，留给业务 JavaScript 执行的时间每帧只有约 8 毫秒（WebVR 则更为苛刻）。 3. **Idle（空闲任务）**：后台计算必须切分为不超过 50 毫秒的代码块，以便随时让出主线程响应新输入。 4. **Load（加载与交互）**：必须在 1 秒以内完成用户操作或给出明确反馈，避免用户丢失注意力。真实世界的数据与这些标准相去甚远。DoubleClick 的调研报告显示，移动页面如果加载超过 3 秒，就会有 53% 的用户直接跳出放弃。而该报告同时揭示了一个触目惊心的事实：全网移动端网页的平均加载时间高达 19 秒。 Alex 剖析了导致这种失败的核心病根：Web 是整个计算领域唯一试图把桌面端的一切生搬硬套到移动端的平台。开发者不会把 Java Swing 的 JAR 包拷到 Android 手机上跑，不会把 macOS 的 Universal Binary 直接搬上 iPhone，也不会把 Win32 原生程序塞进 Windows Phone。其他所有技术栈在物理形态和硬件约束发生变化时都彻底更换了工具链，唯独 Web 开发者没有做出改变。 --- ### [06:25](https://www.youtube.com/watch?v=4bZvq3nodf4&t=385s) 虚拟模拟与真实真机：残酷的性能排查对照前端工具链产出的结果之所以如此糟糕，核心原因在于开发者从未真正在真实的移动设备上进行开发。Alex 现场向观众提问：大家普遍使用桌面版 Chrome DevTools 的 Responsive 视口来模拟手机；但使用 WebPageTest 在真实设备测试的人少之又少；而真正通过 USB 连接手机、使用 `chrome://inspect` 进行真机远程排查的人更是凤毛麟角。Alex 强调，DevTools 内部的网络节流（Network Throttling）和 CPU 降速降频（CPU Throttling）虽然比完全不测要好，但它们本质上只是一种模拟妥协，跟真实的移动硬件性能相差十万八千里。为了证明这一点，Alex 展示了 2015 年 Google I/O 官方大会网站在两台设备上的对比 Trace。该站点基于 Polymer 0.5 构建，是当时技术极度前沿的 PWA，甚至在上线前两周抢先集成了 Chrome 刚推出的 Web Push 通知： | 评估指标与阶段 | MacBook Pro（桌面电脑 / 优质 Wi-Fi） | Nexus 5X（真实中端机 / 相同 Wi-Fi） | |:--- |:--- |:--- | | **DOMContentLoaded / 关键渲染** | 约 700 毫秒（0.7 秒） | 拖延到 2 秒 | | **Onload 触发点** | 紧随 700ms 触发，随后平滑展开入场动画 | 延后到第 6 秒才触发并开始播放动画 | | **JS 执行与主线程耗时** | 脚本总耗时约 0.5 秒，处于预算之内 | 出现长达近 2 秒的长任务（Script Eval），总脚本耗时膨胀到 4 秒 | | **动画帧率表现** | 大部分时间维持 60fps 平滑渲染 | 主线程被锁死，掉帧严重，出现密集长帧卡顿 | | **可交互时间（TTI）** | 约 4 秒（包含完整出场动画时间） | Lighthouse TTI 指标长达 7 秒才可交互 | Alex 总结道，真实移动设备的 Trace 永远是一位残酷的严师：“Traces from real mobile devices are a harsh master.” 当他向各团队展示真机排查数据时，工程师们无一例外都会感到极度震惊。大家普遍习惯了自己口袋里价格昂贵的高配 iPhone，完全不知道市面上中位数水平的移动 CPU 性能有多低劣，不知道桌面与移动设备在磁盘及闪存 I/O 上的巨大差距，更对真实世界中移动无线蜂窝网络的恶劣程度毫无概念。如果不彻底正视硬件和网络上的巨大赤字，优化移动 Web 体验便无从谈起。 ### [09:56](https://www.youtube.com/watch?v=4bZvq3nodf4&t=596s) 性能现状的“悲伤之弧”与真实设备测试 Alex 坦言在过去的一年里，他一直在让许多工程师感到失望——有时直接猛烈，有时委婉温和。他形容自己像是在引导他们走入一段“悲伤之弧”（grief curve），期望最终能带他们走出低谷并取得成效，但这需要付出扎实的努力。他强调，除非我们彻底改变现有的工作方式，否则 Web 根本无法真正为“下一个十亿用户”（the next billion users）服务。在几乎每一次会议中，他都会重复一句话：“真相不在别处，就在 Trace 之中。”（the truth is in the trace）。这里的 Trace 指的是在真实设备上运行 DevTools 和 Chrome Tracing，除此以外的任何手段都远远不够。 Alex 展示了他平时桌面上放置的设备，除了最右侧的 Pixel XL 之外，所有手机的全新售价都在 300 美元以下。而据非洲电商平台 Konga 的团队反馈，他们市场上最常用的手机全新售价甚至低于 100 美元。Alex 随身携带一个专门装测试机的内胆包，装满了他戏称为“很慢的手机”。他之所以时刻带着它们，是因为他完全不相信在桌面端 Chrome 上做出的任何性能测量结果，除非将网页部署到真实手机上并模拟 3G 网络进行测试。同样，他深知手机厂商宣传的参数数字有多么不可信：即使 Nexus 5X 和 MacBook Pro 一样使用闪存介质，且表面主频为 1.8 GHz 对 2.8 GHz，但天真地只看主频根本无法解释为什么 JavaScript 脚本在 Nexus 5X 上的运行速度会比 MacBook Pro 慢上整整 10 倍。 “If you think the $700 iPhone in your pocket is what people are going to be adopting in the next couple of years at the median, you're delusional.” Alex 犀利地指出，全球智能手机的平均售价正在下降而不是上升，因为即将购入手机的人群并不是在换新机，而是人生第一次购买手机，所有富裕人群早就已经拥有了智能手机。下一个十亿用户买不起高端设备，他们处于市场边缘，只能购买廉价设备。从全球范围来看，手机的整体水平其实在变慢，平均网络连接也在变慢。测试设备必须反映这一残酷现实，以免开发者们最终构建出 Bruce Lawson 所称的“富裕西方网络”（Wealthy Western Web）。 - 桌面与真机的主频差距仅为 2.8 GHz 对 1.8 GHz，但脚本执行速度却相差 10 倍。 - 绝大多数新兴市场的主流机型售价在 100 至 300 美元之间，无法代表开发者口袋中的高价旗舰机。 --- ### [12:28](https://www.youtube.com/watch?v=4bZvq3nodf4&t=748s) MotionMark 基准测试与冰袋的启示为了探究移动设备性能差距的根源，Alex 引用了苹果公司当年早些时候推出的基准测试工具 MotionMark。虽然该基准测试主要评估图形性能，但在许多场景下高度受限于 JavaScript 执行能力。在完全对等的硬件环境下，运行在相同版本 OS X 上的 Chrome 和 Safari 互有胜负，Chrome 在大部分情况下甚至打平或击败 Safari，这证明 Chrome 在算法和执行效率上并不慢。然而，在 Nexus 5X 上运行完全相同版本的 Chrome 进行 MotionMark 测试时，桌面端的测试结果整整快了 25 倍。面对如此缓慢的 Nexus 5X，Alex 仅通过改变一个条件，就让 MotionMark 的跑分直接暴涨了 15%。他幽默地向台下发问这是否是魔法，随即笑着承认世界上并没有魔法，他只是用了一点科学手段：在手机背面贴上了一个自制的冰袋。这个灵感来自于他的同事 Victor，Victor 在年初优化这项基准测试时，发现各轮测试之间存在极其剧烈的性能波动。 “When it comes to computing, power is literally power, and power equals heat.” Alex 回归物理学本质解释道，计算机本质上就是一堆电线，导线存在电阻，电压和电流流过必然会散发热量；每当晶体管在开与关的状态之间翻转时，也会释放热量。计算伴随着能量消耗，并以 BTU（英国热量单位）的形式转化为废热。在相同制程、相似架构和相同晶体管数量下，能够耗散更多功率并转化为热量的芯片，才能完成更多的数学运算；而能算更多的数学题，设备才会运行得更快。 ```mermaid flowchart LR accTitle: Thermal and Performance Relationship accDescr: 解释芯片功耗、散热与计算性能之间的正向关联 subgraph PowerAndHeat["功率与热量"] P["输入功率 (Power)"] --> T["晶体管高频翻转"] T --> H["产生废热 (BTU)"] end subgraph CoolingAndPerformance["散热与算力"] H --> C["充分散热 / 冰袋冷却"] C --> M["持续更高算力 (做更多数学题)"] end ``` --- ### [14:25](https://www.youtube.com/watch?v=4bZvq3nodf4&t=865s) 为什么手机无法散热：桌面机与手机的解剖对比桌面级计算机之所以能够维持高速运行，是因为其物理散热结构极为完善。Alex 展示了桌面级芯片的内部构造：芯片上方覆盖着方形散热鳍片（heat sink），散热片与芯片金属外壳之间涂有导热硅脂以彻底消除空气间隙（否则极高的热量会导致芯片损坏炸裂），同时风扇在整个机箱内持续抽风排热。这种高规格的散热系统使桌面或高端笔记本芯片在满载下能耗散约 60 瓦的功率。Alex 调侃道，60 瓦的热量就相当于一个滚烫的 60 瓦白炽灯泡，没人会愿意一直用手攥着一个散发 60 瓦热量的东西。移动设备之所以无法达到桌面端的性能，首要原因就在于它无法在不灼伤用户手掌的前提下耗散 60 瓦的能量。随后，Alex 展示了他解剖的一部 Nexus 5X。这部陪伴他几年的手机在几周前冒出“神奇蓝烟”（magical blue smoke）彻底无法开机。拆解发现，与桌面端 GPU、内存分布在不同区域截然不同，手机的主板正反面极度拥挤： - **正面布局**：供电模块占据了一侧的大量空间。 - **背面与屏蔽罩**：主板另一面集成了整个 SoC（片上系统），外层仅覆盖了一层极薄的铝制均热板。 - **内部接触**：没有导热硅脂，没有风扇；取下金属屏蔽罩后，甚至看不到 CPU 模块本身，因为它被叠放在了三星制造的 RAM 芯片正下方。 “Think about that. To get heat off of this CPU, it has to go through another chip, and then through the casing of that chip, then to air, then to a thin aluminum thing to maybe spread some of that, and then out what?” Alex 发出质问。CPU 散发的热量必须穿透另一颗内存芯片及其外壳，进入空气，再到达薄铝片，最后只能往屏幕或背部的两层聚碳酸酯塑料壳传导。而塑料的导热效率比铝差了整整 1000 倍。热量无法排出，核心温度就会急剧升高并烧毁电路，最终导致手机彻底报废。芯片设计者早在十几年前就预料到了这种瓶颈，因而引入了动态电压与频率调节（DVFS），并允许操作系统彻底关闭过热的核心。Alex 推荐了 2011 年的一篇经典论文《Dark Silicon and the End of Multi-core Scaling》，该论文如同一则精准的预言，揭示了受制于功耗与散热约束，移动设备中有极高比例的硅晶片（暗硅）在实际运行中根本无法被全力调动。 - 桌面芯片在风扇与厚重散热器配合下可耗散约 60 瓦功耗。 - Nexus 5X 的 CPU 芯片深埋于 RAM 芯片底部，热传导路径极其受限。 - 聚碳酸酯（塑料）外壳的导热能力仅为铝金属的千分之一（1/1000）。 --- ### [17:35](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1055s) 电池极限与 big.LITTLE 调度机制除了散热困难，手机无法跑快的另一个核心约束在于电池容量。Alex 指出，手机电池通常仅能储存约 10 瓦时（Wh）的能量。如果以点亮一个 60 瓦白炽灯泡的速度放电，这块电池只能维持几分钟，而且如此暴力的放电速度会导致电池发生爆炸。然而，就是这样一块容量微弱的电池，必须同时维持 CPU、GPU、Wi-Fi、蓝牙、NFC、蜂窝网络基带、屏幕以及触摸屏数字化仪（touch digitizer）的运转，并保证用户单次充电能够满足一整天的使用。 “We can't dissipate power because we can't carry power.” Alex 强调，无法散热的根本原因之一在于我们无法携带更多电能。为了防止电量被迅速挥霍，现代移动芯片普遍采用了极为复杂的架构，其中最主流的就是 ARM 的 big.LITTLE 异构架构。该架构的策略是极其激进地将计算负载从高功耗的大核心迁移到低功耗的小核心上。负责在大小核之间分配任务的组件是操作系统的调度器（scheduler）。Alex 解释说，移动设备普遍放弃了对称多处理（SMP）模式，这意味着并非所有核心都能在同一时间拉满到相同的电压和频率全速狂奔。大多数现代手机运行着全局任务调度器（Global Task Scheduler），但在 Linux 内核中调整这套工作管理系统的难度极高，因此系统广泛依赖各种启发式算法（heuristics）。例如，许多厂商采用了“触摸加速”（touch boosting）机制：当用户的机敏手指触碰屏幕玻璃的瞬间，调度器会立即激活动力强劲的大核心，以提前预判接下来即将发生的动画渲染或滑动手势操作。通过这种瞬间提频后立刻降频的方式，系统在极度严苛的功耗与热量红线之间艰难寻找性能平衡。 ### [19:47](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1187s) 移动端 CPU 架构与桌面端的鸿沟：降频、温控与 big.LITTLE 手机操作系统在启动应用时，为了让用户在点击主屏幕图标后能瞬间看到应用启动，会瞬间唤醒大核心全力运转。然而，Alex 强调现代 Web 的工作负载与此完全不同：用户在移动端打开 Web 应用的过程，通常是先点击 URL，接着陷入漫长的等待网络传输；在等待过程中，刚刚启动的核心可能早已因为节能策略而降频；等内容终于下载完毕开始处理时，处理器早已进入低功耗状态。这种底层行为差异表明，Web 的运行模式在根本上就与移动硬件的优化逻辑脱节。更致命的是散热限制：如果将手机发热比作被困在狭小空间的灯泡，跑分软件中的极限峰值完全无法反映日常真实情况。桌面设备与移动设备在散热和功耗约束上有着天壤之别。Alex 以自己的 MacBook Pro 为例，该机器配备了 100 瓦时的电池——这正是美国联邦航空管理局（FAA）允许携带登机的单块电池容量上限。依靠这块大电池、内置的大散热片以及风扇，MacBook Pro 可以在高负荷下将四个核心持续保持在高速运转状态，并持续散发 40 到 60 瓦的热量。与之形成鲜明对比的是，图表中列出的手机全部采用了 ARM 的 big.LITTLE 架构，多数核心在绝大部分时间里都是关闭断电的。即便像底部的 Moto G4 宣称拥有八核心，在现实场景中只要能同时调用超过三个核心，就已经算极其幸运了。因此，单看标称参数会被硬件厂商完全误导。除了核心调度，流水线深度（pipeline depths）、缓存体系、顺序执行（in-order）与乱序执行（out-of-order）调度机制，以及内存带宽等硬件差异，都会对实际性能造成巨大打击。Alex 直言硬件厂商惯于用模糊的技术参数掩盖巨大的性能鸿沟，而在手机上，用户得到的性能和他们付出的设备成本完全挂钩。 > “The idea that your mobile phone CPU is as fast as a desktop CPU may be true in the limited case, but not in the common case.” —— Alex Russell - **MacBook Pro 供电与散热能力**：拥有 100 Wh 电池（FAA 乘机上限），依赖散热片和风扇可连续耗散 40 至 60 瓦热量，让全部 4 核心持续全速运转。 - **移动设备的 big.LITTLE 现实**：多核心多数时间处于休眠或断电状态；8 核心的 Moto G4 在实际负载中几乎极少能有超过 3 个核心同时工作。 - **基准测试的假象**：由于功耗与温控墙（throttling），移动设备会尽可能激进地下调频率、进入休眠，跑分数据脱离现实场景。 --- ### [21:47](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1307s) 移动存储的残酷真相：2008 年的机械硬盘与 MLC 闪存除了 CPU 的性能折损，移动设备在内存容量与存储系统上也远远落后于桌面端。在内存受限（Memory Pressure）且占用空间极小的移动设备上，浏览器无法像在桌面系统上那样激进地采用“以空间换时间”的缓存策略。有人可能会幻想固态闪存（Flash Storage）在 Linux（Android）环境下总该有不错的读写速度，但 Alex 现场询问听众是否有谁听过“MLC Flash（多层单元闪存）”，举手的仅有大约十个人。 MLC 闪存通过将多个芯片层层堆叠在同一个封装内部来压缩制造成本。然而，固态硬盘（SSD）想要获得极高的读写性能，根本秘诀在于并行化（Parallelism）：在执行大块读写时，主控芯片必须把负载并发分发到尽可能多的独立物理芯片上，因为单个芯片的数据传输延迟是固定的。MacBook Pro 能达到每秒 2GB 的读取吞吐量，正是因为它内部横向排列了多个闪存芯片，可以并行读写；而移动设备为了节省内部极为宝贵的物理空间与电量，不得不将闪存芯片高度集成化，通常只能依赖单一芯片来承担所有读写。这种极低的并行度直接扼杀了 I/O 性能，导致 Nexus 5X 的读取吞吐量仅有区区 400 MB/s。再加上移动端文件系统优化的滞后以及堆叠闪存本身更慢的访问特性，Alex 提出了一个让全场愕然的比喻：开发者在评估当代中端手机的存储性能时，绝不能把它当成高速 SSD，而应当直接把它看作一块来自 2008 年的旧式旋转机械硬盘（Spinning Disk）。 > “Basically, what you should think about the median mobile phone having is spinning disk from 2008.” —— Alex Russell ```mermaid flowchart TD accTitle: 桌面 SSD 与移动设备闪存架构对比 accDescr: 对比桌面端多芯片并行读写与移动端单芯片受限读写结构 subgraph Desktop["桌面端 SSD（MacBook Pro，~2 GB/s）"] D_Ctrl["高性能主控"] D_Chip1["独立闪存芯片 1"] D_Chip2["独立闪存芯片 2"] D_Chip3["独立闪存芯片 3"] D_Chip4["独立闪存芯片 4"] D_Ctrl --> D_Chip1 D_Ctrl --> D_Chip2 D_Ctrl --> D_Chip3 D_Ctrl --> D_Chip4 end subgraph Mobile["移动端存储（Nexus 5X / 中端机，~400 MB/s）"] M_Ctrl["紧凑型主控"] M_Pkg["单一多层堆叠芯片 package (MLC)"] M_Ctrl --> M_Pkg end ``` --- ### [23:36](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1416s) 蜂窝网络的背叛：RRC 状态机、巨大延迟与协议错配如果说移动端硬盘的低劣表现令人沮丧，移动网络的环境则更加恶劣。Alex 极力推荐听众阅读 Ilya Grigorik 的免费在线专著《High Performance Browser Networking》（高性能浏览器网络），并直言读完之后的唯一感触就是“蜂窝网络对你充满敌意”。传统的 TCP 协议和早期 Web 架构是建立在相对稳定的传输介质这一假设之上的，预设数据包丢失率和往返时延（RTT）基本恒定，同时假设网页子资源的链接下载在生命周期内网络是持续可靠的；然而现实中的蜂窝网络在毫秒级别上剧烈颠簸，设备不仅在不同蜂窝基站间频繁切换，还在各种不同的网络协议子类型之间实时跳变。任何乘坐过公共交通、坐过汽车或者只要拿着手机走动过的人，都亲身体验过这种假设是如何土崩瓦解的。底层网络介质的极端方差与波动是真正的杀手。尽管许多人寄希望于 4G LTE 能够解决一切，但数据显示美国 LTE 用户的平均网络速度不仅没有变快，反而在持续倒退。网络波动幅度之大，使得单纯称呼某个连接为“2G”或“LTE”变成了毫无意义的代号。在一些大型新兴市场，中位数 RTT 经常超过 400 毫秒；而 Chrome 开发者工具（DevTools）在模拟常规 3G 时默认填入的 100 毫秒 RTT，仅符合美国本土情况，在面对国际市场乃至运营商二次限速时完全脱离实际。这种高延迟对带宽时延积（Bandwidth Delay Product, BDP）造成了灾难性影响，管你有多大的信道容量，巨大的时延都会在瞬间将实际传输速度吞噬殆尽。更可怕的是，根据 Ilya Grigorik 的分析，“一个 4G 用户大部分时间根本连 4G 用户都算不上”。为了极限制约耗电量，移动设备的基带射频芯片（Radio）设计了一套极其复杂的无线资源控制协议（RRC Protocol），在后台无缝地于高功耗激活状态与低功耗休眠状态之间来回切换。当用户试图发起连接时，手机往往正处于低功耗或低连接状态。对于处于极低功耗状态的 3G 设备，光是完成物理层的无线电握手以建立传输信道，就需要耗费数秒之久。在此期间，浏览器甚至连 DNS 查询、TCP 握手、TLS 协商都无法开始，更别提发送 HTTP 请求头。 > “Cell networks are basically kryptonite to the protocols and assumptions that the web was built on.” —— Alex Russell - **基础假设断裂**：Web 与 TCP 假定网络连接稳定、丢包率恒定且延迟平稳；蜂窝网络却在毫秒级别实时抖动、网络频段和基站切换频繁。 - **跨国 RTT 现实差距**：Chrome DevTools 的标准 3G 预设为 100 ms RTT，而众多新兴市场的实际中位数往返时延高达 400 ms 以上。 - **RRC 协议开销**：在射频模块处于休眠或极低功耗状态时，单是建立物理信道握手就需要耗时数秒，在此之前所有网络协议层（DNS/TCP/TLS/HTTP）彻底阻塞。 --- ### [27:11](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1631s) 框架的特权与虚荣：单页应用在移动 Web 上的溃败当不可控的无线电握手与高延迟网络已经蚕食了宝贵的时间预算，开发者如果还向页面塞入数以百计的 JavaScript 脚本，其结果必然是一场灾难。根据 HTTP Archive 的数据，全球排名前 1000 的网站目前向每个页面推送了将近 1MB 未压缩的 JavaScript 代码。在低性能 CPU 和剧烈波动的移动网络双重夹击下，移动 Web 变得奇慢无比就完全不足为奇了。桌面时代遗留下来的构建思路与工具链已经彻底失效，开发 Progressive Web Apps（渐进式 Web 应用）必须遵循全新原则：加载更少的代码、在正确的时机加载，并尽可能让浏览器原生能力分担工作。 Alex 对当下的框架生态提出了极其尖锐的批评。他明确指出，除非使用极少数“默认快速”（fast-enough-by-default）的工具链，比如 Polymer App Toolbox 或者经过深度 Webpack 优化的 Preact，否则盲目套用市面上流行的主流 JavaScript 框架无异于主动拥抱失败。在他看来，在移动端无节制地使用这些庞大框架，本质上是技术人员缺乏全局认知的无知、或者是仅在高端设备上开发的“特权阶层”（privilege）偏见的体现。许多开发团队在构建 PWA 时走入了误区，把应用做成了类似桌面版 Gmail 的超重型单页客户端：首次加载时展示一个漫长的进度条以执行巨量脚本，寄希望于用前期的高昂代价换取后续界面的快速响应。这种前期集中加载的策略在移动设备上注定是输家，因为 JavaScript 在主线程上是单线程执行的。尽管现代浏览器引擎支持在辅助线程进行脚本的解析和编译，但只要子资源被深埋打包在厚重的 JS 脚本之中，浏览器的预加载扫描器（Preload Scanner）就根本无法提前嗅探并发起拉取；引擎也无法推测性地构建 DOM，无法提前解析和应用 CSS。团队一旦选择放弃与浏览器平台深度协同，实际上就是在用整个产品的用户体验做一场注定落败的豪赌。 > “Except for the tiny club of fast-enough-by-default tools, like the Polymer App Toolbox and Preact, with some good webpack foo, today's framework's are mostly a sign of ignorance, or privilege, or both.” —— Alex Russell - **代码体积现状**：HTTP Archive 统计显示，前 1,000 名的主流网站目前在页面上加载了近 1MB 的未压缩 JS 脚本。 - **重型客户端架构陷阱**：仿照 Gmail 的“重型前端打包 + 初始加载条”模式在手机端严重水土不服，沉重的前期执行成本极易劝退用户。 - **绕过原生平台的代价**：将资源逻辑深锁在 JS 中会导致预加载扫描器失效，主线程被单线程 JS 霸占，浏览器无法异步执行 DOM 构建、CSS 解析与样式应用。 ### [29:19](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1759s) 服务端渲染的“恐怖谷”与可交互性谎言在发热降频或处于低功耗状态的单核手机上运行庞大的脚本，开发者只能“自求多福”。为了解决前端首屏过慢的问题，业界掀起了服务端渲染（Server-Side Rendering，又称同构渲染 Isomorphic Rendering 或通用 JavaScript / Universal JavaScript）的浪潮。Alex 开玩笑地问全场：“我已经几个月没看前端圈了，这玩意儿现在有新名字了吗？”引来台下一阵笑声。同构的核心逻辑是在服务器上运行相同的 JavaScript 代码，生成预先计算好的 HTML 快照直接推给客户端，然后再加载那个极其庞大的 JS 打包文件（bundle），期盼着一切顺利水到渠成。然而这种方案在高端设备与现实世界之间划出了一条巨大的鸿沟。在顶配的 MacBook Pro、网络飞快的 iPhone 或 Pixel 手机上，体验确实不错；但对于使用平价手机和劣质网络的大多数用户，这会引发可怕的“恐怖谷效应（uncanny valley）”。当体积庞大的 JavaScript 资源下载完毕后，主线程依然会被彻底锁死。在脚本执行完成之前，屏幕上虽然展示着内容，却根本无法产生实质交互。Alex 驳斥了部分业内人士“能多线程平滑滚动就算可交互”的辩解，他斩钉截铁地指出，滚动绝不等于交互：“如果我把手指放上去点击界面，而它不能在 100 毫秒内做出响应并执行任务，那它就根本没有加载完——它就是坏掉了（If I can't put my finger down and tap on your UI, and have it start responding and doing work for me under 100 milliseconds, it isn't loaded. It's broken, OK?）。” ### [30:37](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1837s) PRPL 模式：真正的渐进式可交互与精细化切片业界真正需要的不是表面上的视觉快照，而是“渐进式可交互性（Progressive Interactivity）”。这就是 PRPL 模式所解决的核心诉求。它的核心思想极其克制：只在需要时加载当前视口真正需要的代码。结合 Service Worker 与 HTTP/2 Push，开发者完全可以在不进行巨石化过度打包（over-bundling）的前提下实现极致性能。PRPL 模式与 Polymer App Toolbox 证明了：一旦团队把“移动优先（mobile-by-default）”真正落到实处，所达成的效果与当今主流工具库相比简直是天壤之别。 ```mermaid flowchart TD accTitle: PRPL 模式对比巨石打包模式 accDescr: 对比传统巨石打包与 PRPL 模式在资源拆分和主线程占用上的差异 subgraph Monolithic["传统同构打包模式"] M1["大体积 JS Bundle"] --> M2["长时间独占主线程执行"] M2 --> M3["界面看似渲染完毕但不可交互 (恐怖谷)"] end subgraph PRPL["PRPL 模式"] P1["精细化 HTML 导入 / HTTP/2 Push"] --> P2["极小的执行时间切片 (Tiny Execution Slices)"] P2 --> P3["屏幕已有内容持续保持可交互 (< 2秒首屏)"] end ``` Alex 拿 Polymer 团队在 Google I/O 上发布的 Shop 示例应用（`shop.polymer-project.org`）进行了现场对比： - **桌面端 Wi-Fi**：首屏极速达成可交互，脚本执行仅耗时几毫秒。 - **低配 Nexus 5X 设备**：在相同的 Wi-Fi 下，尽管 CPU 性能较弱，但由于应用仅下发了当前视图所需的适量脚本，依然在 2 秒内实现了完全可交互。 - **执行切片优化**：整页脚本总执行时间接近 1.5 秒，但由于使用了精细化的 HTML Imports 和 HTTP/2 Push 替代全量打包，绝大多数组件都拆解成极小的微执行切片（tiny execution slices），确保屏幕上已有的内容全程不丢帧、随时响应触摸。 ### [31:56](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1916s) Service Worker 的核心价值：消灭网络波动的可靠性能针对 Service Worker 的定位，Alex 纠正了普遍的技术误区。许多人认为 Service Worker 仅仅是为了离线支持，但对于绝大多数最终用户来说，这并非最关键的收益。Service Worker 最强大的意义在于提供“可靠的确定性性能（reliable performance）”，因为它能够拦截顶层资源请求，永远优先从本地缓存秒级返回响应。一旦采用这种模式，真实网络环境带来的剧烈波动就会彻底烟消云散。 Alex 展示了 Eric Bidelman 从当年 Google I/O 官方网站收集的真实数据图表。该网站也是一个基于 Polymer 1.0 的 PWA 应用，数据显示：一旦 Service Worker 处于激活状态，页面加载时间的整体分布曲线呈现出极其陡峭且向左偏移的深绿色尖峰——这意味着加载耗时的大幅缩短和极致稳定，Alex 直言“这就是‘变快’在数据图表上最直观的模样”。他严厉告诫开发者，切勿把 Service Worker 当成透明的网络透传工具（network-first approach），并郑重警告：“千万别那么做。请使用 PRPL 模式，确保你的顶层 App Shell 永远不依赖网络（Don't do that. Please don't do that. Use the PRPL pattern, and make sure that your top-level app shell never depends on the network.）。”只有这样，Web 体验才能真正与原生应用平起平坐，正如早间主题演讲中展示的 CNET Tech Today PWA 那样；否则，Web 性能将永远无法企及原生体验。 - **质量检测与集成**：过去缺乏自动化手段来验证 Service Worker 安装及 PWA 指标是否合规，现在开发者应当将 Lighthouse 引入本地命令行（CLI）并集成进持续集成系统（CI），实现性能回归的主动把控。 ### [33:28](https://www.youtube.com/watch?v=4bZvq3nodf4&t=2008s) 回归现实：用低端硬件检验基准，打破“默认缓慢”的工具陷阱 Alex 坦言，移动端 Web 开发的难度远远超出了行业整体此前的认知。为了做出优秀的现代应用，团队必须从根本上重塑观念、重构工具链，并彻底调整研发优先级。而接触真实世界痛点最直接、最快的方法，就是亲自在真实硬件上测试调试。对于开发与测试装备，Alex 给出了一系列具体建议与行动指南： - **采购平价真机**：备一台 2014 年左右配置的典型 Android 手机，比如 Moto G4，搭配 Chrome DevTools 的 `chrome://inspect` 进行真机调试，这能让开发者切身体会全球中位数用户的真实感受。 - **挑战更极端的低配环境**：如果条件允许，去找一台性能更低劣的设备，比如前一年的 Android One 手机体验卡顿现实。 - **利用云端设备机架**：如果预算不足无法购买备用机，直接使用 `webpagetest.org` 上部署在物理机架上的真实移动设备阵列来测试线上 URL。 - **构建防倒退防线**：坚决落地 PRPL 架构，并将 Lighthouse 与 Chrome Telemetry 作为防止性能倒退的核心武器。在演讲尾声，Alex 向听众表达了些许歉意：“如果我今天听起来有点扫兴，我深表歉意（I want to apologize for being a bit of a downer today）。”他坦言平时的演讲都在描绘 PWA 带来的美好前景，那些优势确实存在，好消息是现代 Web 技术确实具备打造惊艳体验的能力。但前提是，行业必须彻底抛弃或大刀阔斧地重构目前那些“默认缓慢（slow-by-default）”的工具链。即便像 Addy 随后要分享的那样，在当下主流框架中需要付出巨大的苦工（elbow grease）去弥补性能缺陷，但既然如今大家已经看清了现实挑战的艰巨性，他坚信现场和直播间的开发者们能够直面真相，用正确的架构打造出真正卓越的移动体验。 ## Notable quotes > [00:00](https://www.youtube.com/watch?v=4bZvq3nodf4&t=0s) What I can say with only a few exceptions-- exceptions like booking.com and the great work that the Flipkart team did-- is that most of us don't really understand how hard mobile actually is. — Alex Russell > [03:01](https://www.youtube.com/watch?v=4bZvq3nodf4&t=181s) It's just that we're really in the midst of a crisis, and collectively, we don't understand how bad that crisis is. If we did, we would have already modulated our behavior. — Alex Russell > [09:56](https://www.youtube.com/watch?v=4bZvq3nodf4&t=596s) If you think the $700 iPhone in your pocket is what people are going to be adopting in the next couple of years at the median, you're delusional. — Alex Russell > [12:28](https://www.youtube.com/watch?v=4bZvq3nodf4&t=748s) When it comes to computing, power is literally power, and power equals heat. — Alex Russell > [17:35](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1055s) We can't dissipate power because we can't carry power. — Alex Russell > [19:47](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1187s) The idea that your mobile phone CPU is as fast as a desktop CPU may be true in the limited case, but not in the common case. — Alex Russell > [21:47](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1307s) Basically, what you should think about the median mobile phone having is spinning disk from 2008. — Alex Russell > [23:36](https://www.youtube.com/watch?v=4bZvq3nodf4&t=1416s) Cell networks are basically kryptonite to the protocols and assumptions that the web was built on. — Alex Russell ## Mentioned Alex Russell, Frances Berriman, Jake Archibald, Booking.com, Flipkart, Konga, Polymer, PRPL, RAIL, DoubleClick, Nexus 5X, MacBook Pro, MotionMark, Bruce Lawson, Dark Silicon and the End of Multi-core Scaling, Moto G4, Ilya Grigorik, High Performance Browser Networking, Preact, Webpack, Lighthouse, Service Worker, Eric Bidelman ## Video description Alex shows us the important things to focus on in performance, and how to run great experiences on slow, inconsistent networks and low-power devices. Links: Kevin Schaaf's talk on the PRPL pattern: https://goo.gl/vgaup0 Documentation on how to use chrome:inspect for testing on real-world devices: https://goo.gl/T1C4xe The "Dark Silicon and the End of Multi-core Scaling" paper (PDF): https://goo.gl/3ogsHD Ilya Grigorik's essential "High Performance Browser Networking": https://hpbn.co/ Watch more recordings from Chrome Dev Summit '16 at: https://goo.gl/TkgXYM Subscribe to the channel: https://www.youtube.com/chromedevelopers Music by Terra Monk: https://goo.gl/xolmTV [Source](https://www.youtube.com/watch?v=4bZvq3nodf4)

Source quotes

[0:00] Alex Russell: What I can say with only a few exceptions-- exceptions like booking.com and the great work that the Flipkart team did-- is that most of us don't really understand how hard mobile actually is. [3:01] Alex Russell: It's just that we're really in the midst of a crisis, and collectively, we don't understand how bad that crisis is. If we did, we would have already modulated our behavior. [9:56] Alex Russell: If you think the $700 iPhone in your pocket is what people are going to be adopting in the next couple of years at the median, you're delusional. [12:28] Alex Russell: When it comes to computing, power is literally power, and power equals heat. [17:35] Alex Russell: We can't dissipate power because we can't carry power. [19:47] Alex Russell: The idea that your mobile phone CPU is as fast as a desktop CPU may be true in the limited case, but not in the common case. [21:47] Alex Russell: Basically, what you should think about the median mobile phone having is spinning disk from 2008. [23:36] Alex Russell: Cell networks are basically kryptonite to the protocols and assumptions that the web was built on.

Source quotes

[29:19] Alex Russell: If I can't put my finger down and tap on your UI, and have it start responding and doing work for me under 100 milliseconds, it isn't loaded. [23:41] Alex Russell: Cell networks are basically kryptonite to the protocols and assumptions that the web was built on. [9:56] Alex Russell: If you think the $700 iPhone in your pocket is what people are going to be adopting in the next couple of years at the median, you're delusional. [6:36] Alex Russell: It turns out that DevTools emulation is nothing like real devices. [21:47] Alex Russell: Basically, what you should think about the median mobile phone having is spinning disk from 2008. [31:56] Alex Russell: Use the PRPL pattern, and make sure that your top-level app shell never depends on the network. [19:47] Alex Russell: The idea that your mobile phone CPU is as fast as a desktop CPU may be true in the limited case, but not in the common case.

Original transcript

[0:00] [MUSIC PLAYING] [0:05] ALEX RUSSELL: Hi, good afternoon. [0:07] I'm Alex Russell. [0:08] I'm an engineer on the home team. [0:09] And to set expectations, This isn't the talk I usually give, [0:11] so I hope you'll bear with me through some difficult content. [0:16] These days, I usually put this slide up [0:18] to talk about Progressive Web Apps, which Francis [0:20] Berriman and I named last year. [0:23] Progressive Web Apps are the culmination [0:24] of multiple years of my team's work. [0:26] I've been working with Jake on service workers for, I guess, [0:29] four years now. [0:31] And the team that I work on has been designing and building [0:34] the core technology for Progressive Web Apps, the stuff [0:36] that you've been hearing about for the last couple of Chrome [0:38] Dev Summits, and all day today, and probably all day tomorrow. [0:41] And I apologize a little bit, but not really. [0:43] But as you can imagine, building and maintaining [0:45] all of that stuff, and working on the standards for it, [0:48] is a full time job. [0:49] But I'm not going to talk about Progressive Web Apps today. [0:52] At least not directly. [0:54] You see, for the past year, I've also [0:55] been working with Thao and her team, [0:57] to partner with folks who are about to launch [0:59] their Progressive Web Apps, to make sure that they're really [1:02] high quality. [1:03] And this incidental consulting work [1:05] has given me a broad view into the practices [1:07] of many of the teams that are building for the mobile web [1:09] today. [1:10] What I can say with only a few exceptions-- exceptions [1:13] like booking.com and the great work [1:16] that the Flipkart team did-- is that most of us [1:18] don't really understand how hard mobile actually is. [1:27] I haven't exactly been making friends in the JavaScript [1:30] framework community by saying that sort of thing out loud, [1:32] it turns out. [1:34] But, as a Polymer team will tell you, [1:36] this is basically the PG version of what [1:37] I've been saying to them for something [1:39] like a year and a half. [1:40] We had some really tense meetings. [1:44] I kept saying things like, it needs to be more asynchronous, [1:46] or look at this trace, you really need [1:48] to load a lot less JavaScript. [1:50] And 12k sounds good to me, actually. [1:52] Or, you really need to break up your script, [1:54] so you're not executing this entire long block. [1:56] What the heck is going on here? [1:58] And at some point, they said, we get it. [2:00] Just stop telling us what to do and start [2:02] telling us what goal to hit. [2:03] And this was kind of a breakthrough [2:05] in the conversation. [2:06] We'd been at loggerheads for a while. [2:09] And so I put my finger in the air and said, [2:10] it would be really great if you could get me something that's [2:13] interactive in about three seconds on a 3G connection [2:16] on first load, and interactive in about a second when I launch [2:19] it from the home screen. [2:22] So the Polymers went off, and they went [2:25] through the stages of grief. [2:27] We had some denial, I'll admit. [2:30] There was some denial. [2:31] Anger, yes. [2:32] Bargaining, absolutely. [2:34] Depression, luckily they sit far enough away from me [2:37] that I couldn't actually see them sobbing in their cubes. [2:40] But I finally accepted the challenge, [2:42] and they came back with a PRPL pattern, which Sam is [2:44] going to talk a lot more about. [2:46] Meanwhile, the rest of the JavaScript community [2:48] hasn't internalized the same message to the same degree. [2:51] So I'm here to let you down. [2:53] Not easily. [2:53] This may be a little bit hard, and I apologize in advance, [2:56] but we need to get to the bottom of what mobile actually means. [3:01] When you see me tweeting things like this, [3:03] this is actually kind of desperate. [3:07] I have spent years of my life working in TC39 to make [3:10] JavaScript a better language. [3:12] I have spent countless hours persistently advocating [3:16] for extensibility, to give you more power when you're writing [3:19] JavaScript in the web platform. [3:21] I've designed features like service workers, [3:23] with Jake and a load of other folks, that are entirely [3:25] predicated on JavaScript in the first place. [3:28] Back in the day, I used to work on a JavaScript tool [3:30] kit with Scott and Steve from the Polymer team. [3:32] It's not like I hate JavaScript, or I don't like it, [3:35] or I think you shouldn't be using frameworks. [3:37] I don't hate them. [3:39] It's just that we're really in the midst of a crisis, [3:41] and collectively, we don't understand [3:43] how bad that crisis is. [3:45] If we did, we would have already modulated our behavior. [3:50] So what I'm seeing when I do reviews is almost [3:52] universally bad news, specifically in the context [3:55] of the RAIL performance model. [3:56] A quick recap of RAIL. [3:58] Basically, R stands for responding to input [4:01] in under 100 milliseconds. [4:03] Animating at 60 frames a second, which [4:06] means that, because the browser has to apply the things that we [4:08] hand it on every frame, we probably only [4:11] have about 8 milliseconds to do our work. [4:14] When you think about web VR, it gets-- 60 frames [4:17] a second's hard, 120, oof. [4:21] When we're doing background work, [4:23] we need to make sure that we're breaking up that background [4:25] work into 50-millisecond chunks, so that we [4:26] can respond to subsequent input and stay [4:29] under that 100-millisecond budget. [4:31] And we really want to complete actions for the user [4:34] in under a second. [4:35] Because over a second, research suggests [4:37] that users lose focus on the task [4:38] that they're trying to accomplish. [4:40] If we can't actually complete it, [4:42] we definitely need to acknowledge that work [4:44] in under a second. [4:45] Give users the sense that we're doing something for them. [4:48] So you've heard this number all day today. [4:50] Darren had it in the keynote. [4:52] But the DoubleClick folks went and did a bunch of work [4:54] to find out, what are the bounce rates for sites, [4:57] and does performance matter? [4:58] And the answer, of course, is yes. [4:59] 53% of users bounce from mobile sites [5:01] that take more than three seconds to load. [5:03] You leave real money on the table when your site is slow. [5:06] Yet most of the apps that I've traced over the last year [5:09] have been performance travesties. [5:11] My experience isn't an outlier. [5:16] That same report noted that the average mobile site [5:19] takes 19 seconds to load. [5:23] 19 seconds. [5:26] Collectively, we're failing. [5:28] Sam's got more data on this, and I actually [5:30] don't have time to go into it, because we're [5:32] going to talk about some of the reasons why. [5:34] But I think one of the key reasons that we are not [5:37] succeeding today, to put it kindly, [5:39] is a lack of understanding and respect for how hard mobile is. [5:42] I have faith that as a community, if we [5:44] understood and respected the limits, [5:46] we'd be doing much better. [5:48] Nobody here wants to make bad user experiences. [5:51] I think part of this is because we [5:53] are the only platform in the world that tried to take all [5:56] of our desktop stuff with us. [5:58] You don't take a Java JAR that was a swing application [6:01] and run it on your Android phone. [6:03] You don't take a Mac universal binary [6:05] and run it on your iPhone. [6:08] You don't take a win32 app and run it on your Windows Phone. [6:11] Everybody else switched their tools [6:13] when their form factor and their constraints changed. [6:15] We didn't. [6:16] We didn't make that switch. [6:18] And the proof is in the pudding. [6:19] It's in the traces that I'm looking at every day. [6:22] But that's not the only reason. [6:25] Why are most of the popular frameworks [6:28] and the tools that we're using, the tool chains that we all [6:30] wind up setting ourselves up with, [6:33] unacceptably slow by default? [6:36] Why are our tools producing such abysmal results? [6:38] It's not like we're bad people who want bad things for users. [6:43] I think, in part, it's that you all aren't actually [6:47] developing on mobile phones. [6:52] Paul showed you some really great DevTools. [6:53] They're awesome. [6:56] But I want to understand, who uses Chrome DevTools [6:58] to get their responsive view, and understand how [7:01] things will look on a phone? [7:04] OK. [7:05] Now, keep your hands up if you're using web page tests [7:09] for testing on real devices. [7:11] Oh, I like you. [7:12] Some of you are liars. [7:15] And keep your hands up if you use [7:16] Chrome colon Inspect over USB to do real on-device debugging. [7:23] OK, who's done it more than once? [7:26] That's what I thought. [7:28] It turns out that DevTools emulation [7:30] is nothing like real devices. [7:32] Network throttling, CPU throttling, [7:35] they're all kind of a fudge. [7:37] They're better than nothing. [7:38] Please use them. [7:38] Please set them on by default. Please use them all the time. [7:42] But they're not the real thing. [7:44] Not even close. [7:46] Let me give you a quick example. [7:47] This is the I/O 2015 website, which was a Polymer 0.5 [7:50] Progressive Web App. [7:51] It was super leading-edge. [7:52] It had push notifications, which I [7:54] think we had launched in Chrome like a week or two before. [7:57] There were bugs. [7:58] It was amazing. [8:00] On desktop, it felt super fast on this Wi-Fi connection. [8:02] We get DOMContentLoaded and a meaningful paint [8:05] at about 700 milliseconds. [8:07] On-load isn't far behind, and that [8:09] starts a nice swooping-out animation, which [8:12] is smooth most of the time. [8:15] Overall, we spend about a half a second [8:18] in script, which is well under our budget [8:20] for getting a good, responsive experience. [8:23] And we get interactive content in about four seconds, [8:25] including that long animation. [8:27] This is a really great experience [8:29] on a desktop-class device. [8:31] Which is to say, my MacBook Pro. [8:34] This is the same site, running on the same Wi-Fi network, [8:36] on the Nexus 5X. [8:38] DOMContentLoaded doesn't show up until two seconds. [8:42] On-load triggers at the six-second mark, which [8:44] is where that animation starts. [8:46] Part of that delay is down to this huge honking script eval. [8:49] That's locked up the main thread for nearly two full seconds. [8:53] Script execution balloons up to four seconds in total, [8:55] and for all of that work, we still don't even [8:57] get smooth animations. [8:58] Look at all those long frames. [9:01] Content doesn't become interactive until 7 seconds. [9:05] This is what TTI will tell you in Lighthouse, [9:08] and this is not acceptable. [9:12] Ouch. [9:13] So what did we learn? [9:15] Traces from real mobile devices are a harsh master. [9:19] And when I show folks their apps on real devices, [9:21] most have the same reaction. [9:22] And in fact, I do this a lot. [9:25] They're shocked at how slow the median mobile CPU actually [9:28] is, not the iPhones in their pockets. [9:31] They don't really understand the difference between desktop [9:34] and mobile disks and storage. [9:36] And most of us are super ignorant [9:39] about how crazy mobile networks are in the real world. [9:42] I think we theoretically know, at some level, [9:44] that they're bad. [9:46] Doesn't begin to cover it. [9:47] They're so bad. [9:50] It's important to understand the depth of the deficit, though, [9:53] so we can start to adapt. [9:56] I've been letting down a bunch of engineers for the last year. [10:00] Hard, soft. [10:01] I've just sort of been easing them into this grief curve, [10:05] and then hopefully we get out the other side. [10:07] And it goes well, but you have to put in the work. [10:10] But unless we do that work, unless we change [10:12] the way we're working, the web won't work for the next billion [10:15] users. [10:16] Not practically speaking. [10:18] So something I say in basically every meeting [10:20] is that the truth isn't the trace. [10:21] And by that, I mean DevTools and Chrome tracing [10:23] attached to real devices. [10:26] Nothing else cuts the mustard. [10:28] It doesn't get you there. [10:30] So this is what's sitting on my desk on a typical day. [10:33] And aside from the Pixel XL that's on the right hand side, [10:36] all those phones are less than $300 new. [10:39] The folks at Conga report that the most commonly used phones [10:43] in their market are in the sub-$100 range new. [10:48] I carry most of these phones around in this bag. [10:51] This bag is in my bag, my other bag. [10:54] With me all the time. [10:56] And these are some slow phones. [10:59] And I carry them because I have zero faith [11:02] that anything I trace in Chrome, on the desktop, [11:06] is going to be like the real world, [11:07] unless I've put it on the phone and emulated 3G. [11:11] And we'll talk about 3G. [11:14] I don't trust that unless I've done it on real hardware. [11:16] And you know what else also don't trust, [11:18] is the marketing numbers from phone vendors. [11:21] So here are some of the headline specs for the devices [11:23] that are in my bag. [11:24] All these devices have flash-based storage. [11:26] Naively, there's no reason to think [11:27] that script should run 10 times slower on my Nexus [11:30] 5X than it did in my MacBook Pro. [11:32] Especially if I looked at these headline numbers. [11:34] 2.8 gigahertz versus 1.8 gigahertz. [11:37] That's not a 10x difference. [11:41] Naively, there's no reason for that. [11:43] If we just looked at these numbers, [11:45] we wouldn't really understand what's going on. [11:47] It bears repeating. [11:48] If you think the $700 iPhone in your pocket [11:50] is what people are going to be adopting [11:54] in the next couple of years at the median, you're delusional. [11:57] The average selling price of smart phones [12:00] is going down, not up, because the next set [12:02] of people who are going to buy phones [12:03] are not replacing their current phone. [12:05] They're buying a new phone for the first time. [12:08] And all the rich people already have smart phones. [12:11] The next billion users aren't buying high-end devices, [12:13] they're buying at the margin. [12:14] And that margin is a cheap device. [12:16] Worldwide, phones are getting slower. [12:18] So is the average network connection. [12:20] Your test device needs to represent that reality [12:22] so that we don't wind up building what Bruce Lawson has [12:25] called the Wealthy Western Web. [12:28] So this is MotionMark. [12:29] It's a benchmark that Apple put together earlier this year. [12:34] And it tests a bunch of graphics performance, [12:37] but it's very JavaScript bound, in many cases. [12:40] On apples to apples hardware, with Safari and Chrome, [12:45] running the same version of OS X, [12:47] Chrome ties or beat Safari in most cases. [12:50] Basically, this is not something that we're actually slow at. [12:53] So here is the same benchmark, on the same version of Chrome, [12:57] on a Nexus 5X. [12:58] The desktop version is 25 times faster. [13:02] For as slow as the Nexus 5X is, I [13:03] was able to change just one thing [13:05] and get the MotionMark benchmark running 15% faster. [13:08] 15% for one change! [13:11] What the heck did I do? [13:13] Is it magic? [13:16] [LAUGHTER] [13:19] We're all adults here. [13:20] So I think it's safe to admit that magic isn't actually [13:22] a thing. [13:23] Instead, I used a little bit of science, [13:25] and I added this makeshift ice pack [13:27] to the bottom of the phone. [13:28] [LAUGHTER] [13:32] I got this idea from my colleague Victor, who's [13:34] been looking into optimizing this benchmark earlier [13:36] in the year, and was seeing massive variance across runs. [13:40] What the heck is going on here? [13:42] Going back to basics, recall that computers are basically [13:45] just a bunch of wires. [13:46] Those wires have resistance, and voltage and power [13:48] running through them, which means that they dissipate heat. [13:50] And we dissipate some more heat every time [13:52] a transistor flips from the on state to an off state, [13:54] or vice versa. [13:55] That same process generates computation, [14:00] but it also generates excess wattage in the form of BTUs. [14:05] So a chip built on the same process, [14:07] with roughly the same architecture, [14:08] with the same number of transistors [14:10] that dissipates more power and turns it into heat [14:15] is the chip that does more math. [14:17] And doing more math is how you go faster. [14:19] When it comes to computing, power is literally power, [14:23] and power equals heat. [14:25] So these are the guts of a regular desktop-class machine. [14:28] The chip in there is a slower version [14:29] of the one in my laptop. [14:31] The square fins on the top of that thing, [14:33] they're the heat sink. [14:34] And the job of the heat sink is to dissipate the heat coming [14:41] off of the chip. [14:42] Now, that heat sink is seated on top [14:44] of a metallic top of the assembly for the chip, [14:48] with a little layer of thermal paste between it, [14:51] so there's no air gap. [14:52] That air gap would cause a thing that would explode and break [14:55] the chip, because it gets so hot. [14:57] There's a fan that's running over the entire box, [14:59] extracting all that heat that's getting dissipated out. [15:02] And the result is that a desktop-class or high-end [15:04] laptop chip like this can dissipate something [15:06] like 60 watts under load. [15:09] This is what 60 watts looks like. [15:12] I don't know about you, but I haven't [15:15] chosen to hold 60 watts in my hand dissipating [15:18] more than once. [15:19] And-- [15:20] [LAUGHTER] [15:22] --this is the key reason that mobile phones don't run as fast [15:24] as desktops or laptops. [15:25] Even if they can include as many transistors, [15:27] or scale up to the same frequencies, [15:29] these chips, in these packages, just [15:31] can't dissipate 60 watts without burning your hand, [15:33] as Taylor said earlier. [15:35] So let's look inside the guts of one of these phones. [15:38] This is the remains of the Nexus 5X [15:41] that I used as my daily phone for a couple of years. [15:43] It gave off the magical blue smoke [15:45] and stopped booting a couple of weeks ago. [15:47] So now I get to dissect it. [15:49] And unlike desktop-class machines, [15:50] where the GPU and the memory might [15:52] be on different sections of the board, or different boards [15:54] entirely, the whole system on the chip [15:56] lives under the other side of this, [15:57] and that thing there is the power supply. [16:01] On the flip side of the same PCB is the entire system on a chip. [16:05] It's got an aluminum cover like this, sort of a heat spreader. [16:08] So when we flip it over, this is what you see. [16:11] There's no thermal paste. [16:13] No fans. [16:13] I took the shield off, but that's all. [16:15] In fact, the CPU module isn't even visible on this board, [16:18] because it's sitting underneath that Samsung-made RAM chip. [16:22] Think about that. [16:23] To get heat off of this CPU, it has to go through another chip, [16:28] and then through the casing of that chip, [16:30] then to air, then to a thin aluminum thing [16:33] to maybe spread some of that, and then out what? [16:35] The screen? [16:37] The two layers of polycarbonate plastic in the back? [16:39] Two layers. [16:40] Separate layers. [16:40] They aren't even connected. [16:41] Remember that polycarbonate plastic dissipates [16:45] heat 1,000 times less efficiently than aluminum. [16:48] If you can't evacuate the heat, then you [16:50] can't really generate a lot of that [16:51] without the core temperature rising to levels [16:53] that damage the circuitry. [16:55] And then the magic blue smoke escapes, [16:58] and your phone stops booting. [17:00] I wonder what I did to mine. [17:03] So chip designers saw this coming. [17:04] They've been putting dynamic voltage and frequency scaling [17:07] into chips for more than a decade. [17:09] And, more recently, they've started [17:10] enabling features that allow OSes to turn off cores [17:14] entirely. [17:15] All this reminds me of this paper [17:16] that I read a few years back, from 2011. [17:19] If you have some spare time, I recommend it. [17:20] While perhaps not intended to be, [17:22] it reads like a prophecy from half a decade ago [17:25] about the experience that we're all carrying around [17:27] in our phones, where a huge percentage of the silicon [17:29] in our devices isn't actually available to be [17:32] used, thanks to the power and thermal constraints. [17:35] And the power thing is real. [17:36] There aren't any heat sinks on your phone, [17:37] although I'm pretty sure that you wouldn't want a heat [17:40] sink and a fan in your pocket. [17:42] But imagine if you could have one. [17:44] Why don't those exist? [17:46] Why can't I get a bulky phone? [17:48] The basic reason is that this battery only contains [17:53] 10 watt-hours of power. [17:55] Think about that in terms of a light bulb. [17:58] You'd only be able to keep it lit for a couple of minutes [18:00] if you could drain the battery that quickly, [18:03] which you don't, because doing that causes [18:05] batteries to explode. [18:06] So just don't try. [18:08] Just FYI. [18:08] Not a fun experiment at home. [18:12] This is why mobile phones are slow. [18:14] We can't dissipate power because we can't carry power. [18:16] That battery has to deal with all sorts of stuff. [18:21] It has to deal with the CPU, and the GPU, and the Wi-Fi radio, [18:28] and the Bluetooth radio, and the NFC radio, and the cell [18:31] radio, and the screen, and the touch digitizer. [18:36] It has to power all that stuff and keep [18:38] you satisfied for a day's worth of use on a single charge. [18:41] On something that can't keep that light bulb [18:43] lit for more than a couple of minutes. [18:46] So to keep from wasting power, there [18:47] is a lot more complexity in modern phones. [18:50] Most of them today use what's called [18:51] a big.LITTLE architecture. [18:53] And that means that they try to move work [18:56] from high-power cores to low-power cords [18:58] very aggressively. [19:00] The systems that move that work around are called schedulers. [19:02] All kernels have schedulers, and the [INAUDIBLE] schedulers [19:06] are a bit all over the map. [19:07] The big thing to understand about them, [19:09] though, is that your phone probably [19:10] isn't using what's called symmetric multiprocessing. [19:12] That is to say, not all of the cores [19:14] are spun up to the same voltage and frequency, [19:16] running at the same rate, all the time. [19:18] There are different levels. [19:21] Most of the phones that you probably have have something [19:24] called a Global Task Scheduler, which [19:26] moves work around between those things. [19:28] The systems in Linux that wind up doing that work management [19:32] are notoriously hard to tune, and they [19:34] use all sorts of heuristics to do it. [19:36] Some do something called touch boosting, [19:38] and what that means is when you put your finger down [19:39] on the glass, they power up the big CPUs in anticipation of you [19:42] doing some work, like animating something or flinging it [19:44] around. [19:45] Some of them have special heuristics [19:47] for launching applications, so that when you launch something [19:49] from the home screen, they power up the big cores so that thing [19:52] launches very quickly. [19:53] Now, that looks nothing like the web workload. [19:55] The web workload, today, looks like tapping on the URL [20:00] and waiting for the network. [20:02] And maybe those cores got scaled down again. [20:05] And then your content comes in. [20:06] And then we start processing it. [20:08] Basically, the web is fundamentally not aligned [20:10] with the way mobile phones have been optimized to work, [20:12] because our workloads don't look like their workloads. [20:15] Lastly, remember that light bulb? [20:18] The light bulb is why you shouldn't [20:20] believe any of the numbers that you see in benchmarking. [20:25] The idea that your mobile phone CPU is as fast as a desktop CPU [20:29] may be true in the limited case, but not in the common case. [20:32] You're going to get scaled. [20:33] You're going to get throttled. [20:34] Things are going to move to a low-power state [20:36] as aggressively as possible. [20:37] That's not how the world works. [20:39] We don't keep things spun up the way we do on desktop. [20:42] So here's the chart again, but I added the details of the CPUs. [20:44] It looks a lot different now, doesn't it? [20:46] I'm not even going to get into the details [20:48] of the huge differences that come from caches, and pipeline [20:52] depths, and in-order versus out-of-order dispatch, [20:54] and memory bandwidth. [20:55] But all of that matters. [20:56] The tl;dr is that you actually get what you pay [20:58] for on a mobile phone. [21:00] Importantly, the MacBook Pro packs a 100 watt-hour battery. [21:03] That's the FAA maximum limit that you're [21:05] allowed to carry in a single battery onto a plane. [21:09] Design constraint. [21:10] But as a result of having that much power available, [21:13] and because of the heat sink and the fan in my MacBook Pro, [21:15] I can keep those four cores spun up under load, [21:18] and they can dissipate something between 40 and 60 watts. [21:21] All the phones in the chart are big.LITTLE devices. [21:23] And that means that many of the cores [21:25] are powered down most of the time. [21:26] That Moto 4G at the bottom has eight cores, [21:28] but if you get more than three of them [21:30] working for you at any point in time, you are really lucky. [21:35] So mobile CPUs aren't exactly what you thought they were. [21:39] I mean, since when would a hardware vendor ever use [21:41] an opaque number to mask a major difference in performance, [21:43] right? [21:44] [LAUGHTER] [21:47] And maybe memory pressure and smaller memory footprints [21:50] on mobile devices don't allow us to, on the browser side, [21:54] trade away space for speed as aggressively [21:56] as we do on desktop. [21:57] And maybe the storage systems are roughly as fast, though. [21:59] So maybe we could get something back there. [22:01] I mean, they're just solid-state flash devices on a Linux OS, [22:04] if you're running Android, right? [22:07] Who has heard of the term MLC Flash? [22:11] OK, it's like 10 people. [22:15] That's about what I expected. [22:17] MLC flash is multi-level chips. [22:19] Basically, they are chips on top of chips inside the same chip [22:23] package. [22:24] And that is how you make storage cheaper. [22:29] And it's a primary reason why Nexus 5X gets [22:31] 400 megabytes a second of read throughput, [22:34] and my MacBook Pro gets two gigabytes a second [22:36] of read throughput. [22:37] In SSDs, the way you get better performance is parallelism. [22:40] In order to read or write a block, you want to distribute [22:43] reads and writes-- for large reads and large writes-- [22:45] to as many different chips as possible, [22:46] because the latency for getting data to and from each [22:49] of those chips is constant. [22:50] So you have a controller in front, it's got some memory, [22:52] and then it distributes that work out to those chips. [22:54] Now, physical space is at a premium on mobile devices, [22:57] but so is power. [22:58] And so vendors have tried to consolidate those chips [23:01] as far as possible. [23:02] And that means that they're using [23:03] fewer and fewer-- usually one-- chip for all that reading [23:07] and writing. [23:07] And that means low parallelism, which means low performance. [23:14] We don't get that benefit that my MacBook [23:17] Pro does, of having many chips in a row on a mobile device. [23:20] MLC flash is also just a [INAUDIBLE] slower, [23:22] and file systems haven't really caught up. [23:24] Basically, what you should think about the median mobile phone [23:27] having is spinning disk from 2008. [23:31] Think of it that way. [23:32] That's probably a pretty good parallel. [23:36] OK, that's kind of a bummer, right? [23:39] Spinning metal. [23:41] And if mobile disks make you sad, [23:42] the state of mobile phone networks [23:44] will make you wish that mobile disks were [23:46] the problem you actually had. [23:49] If you hadn't, I recommend checking Ilya Grigorik's High [23:51] Performance Browser Networking. [23:53] it's free. [23:53] You can read it online. [23:54] And it goes over a huge amount of the total end-to-end network [23:58] stack that gets bits from your server to your phone. [24:02] Highly recommended. [24:04] If you spend some time with it, you'll [24:06] get to where I got to, which is that mobile networks hate you. [24:09] Cell networks are basically kryptonite to the protocols [24:12] and assumptions that the web was built on. [24:13] Where TCP in the web was built around the assumptions [24:16] of a relatively stable underlying transport condition, [24:18] cell networks gyrate wildly, and from millisecond [24:21] to millisecond. [24:22] Where TCP assumes relatively constant packet loss [24:25] and constant RTT times, cell networks [24:27] deliver anything but, transitioning [24:29] from one network type to another, or one subtype [24:31] to another, in real time. [24:33] And where the web's model of hot-linking sub-resources [24:35] assumes reliable networks for the duration of the page, [24:39] we kind of know how badly that breaks down in practice, [24:41] don't we? [24:42] At least those of us who use public transport, or ride [24:45] in cars, or, basically, use phones. [24:50] So this paper is a pretty good entry point, especially [24:54] its references, into why these networks hate you so much. [24:59] And they do. [25:00] They hate you a lot. [25:03] When you dig in, it turns out that what's really [25:05] killing you is the variance and the volatility [25:07] in the underlying network substrate. [25:09] Now, some of you might be thinking, [25:11] isn't LTE going to save us? [25:12] Well, yes and maybe. [25:14] Here's last year's performance for US LTE users, [25:19] compared to the year before. [25:21] These networks are actually getting slower. [25:25] In fact, the variance in mobile networks [25:27] is so massive that it feels like a farce [25:29] to call something 2G or LTE. [25:31] Some of the largest emerging markets [25:33] have median RTT times north of 400 milliseconds. [25:36] When you open DevTools and you do network throttling, [25:38] and you put in the regular 3G mode, [25:40] it sets the RTT to 100 milliseconds, [25:42] which is par for the course in the US, but wildly wrong [25:45] in other markets. [25:47] Especially when you think about how many carriers wind up [25:51] throttling things even further down. [25:54] The same network type may mean dozens of different things [25:57] for your users. [25:58] For the TCP geeks in the house, thinking [26:00] about what that sort of round chip time [26:02] does to the bandwidth delay product [26:04] can really bring you down. [26:06] Channel capacity be damned. [26:07] That sort of latency eats your transfer speed for breakfast. [26:12] But of course, this is mobile, so it's worse than that. [26:15] As Ilya said to me recently, a 4G user isn't even a 4G user [26:18] most of the time. [26:19] Cell radios are magical things, sure. [26:21] They try to preserve power too, though. [26:23] And they seamlessly transition between their high-power states [26:26] and their low-power states across different radio types, [26:29] different cell locations. [26:31] They do a ton of work to make sure [26:32] that we never see what's happening under the covers. [26:35] But that creates variance. [26:38] When users try to connect, their phones [26:40] might be in a low-connectivity or low-power state, [26:42] when they weren't just a minute ago. [26:45] In those cases, the radio resource control protocol [26:47] that Ilya's book goes into some detail on determines [26:49] how the connection gets made. [26:50] For users in very-low-power states on 3G connections, [26:53] it can take seconds to just start the radio handshake [26:56] at the physical layer, so that you [26:58] can start transmitting data. [26:59] If you want to get bits on screen in three seconds, [27:01] you're in a really tough spot. [27:03] You can't do DNS, TCP, TLS, or even start [27:06] sending those HTTP headers down the wire [27:09] until all of that is complete. [27:11] Now, consider adding hundreds of kilobytes of JavaScript [27:13] to the mix. [27:14] That's not theoretical. [27:16] The HTTP archive is showing that the top 1,000 [27:18] sites put almost a megabyte of uncompressed script [27:21] on their pages today. [27:23] On those networks, on these CPUs, [27:26] this is a recipe for disaster. [27:29] No wonder users have the pervasive feeling [27:31] that the mobile web is slow. [27:34] I think it's only reasonable to be sad about all of this. [27:37] The tools and techniques that we've [27:38] brought over from the desktop era really aren't serving us. [27:41] To make great Progressive Web Apps, [27:43] we need to do things differently. [27:45] We need to load less code. [27:46] We need to load it at the right times. [27:48] And we need to let the browser do work for us [27:51] whenever possible. [27:53] Use the platform isn't a nice-to-have. [27:56] On mobile, it's the only way to go. [27:59] Sam's going to go into a lot more detail about the depth [28:02] of the crisis that we're in, but make [28:03] no mistake, if you're using one of today's more [28:05] popular JavaScript frameworks in the most naive way, [28:08] you are failing by default. There is no sugarcoating this. [28:12] Except for the tiny club of fast-enough-by-default tools, [28:15] like the Polymer App Toolbox and Preact, [28:17] with some good webpack foo, today's framework's are mostly [28:20] a sign of ignorance, or privilege, or both. [28:25] The good news is that we can fix the ignorance. [28:28] So when we're armed with data, we can make better choices [28:31] and avoid those slow-by-default tools. [28:34] I've talked to a lot of teams who've [28:35] gotten a long way into the PWA development story, [28:39] and they've got very heavy clients, like JavaScript apps. [28:41] Their apps feel like Gmail, basically. [28:43] They get a loading bar, or something like it, [28:45] while a ton of script starts to execute. [28:46] And then, they get a fast UI. [28:48] All the subsequent interactions wind up [28:49] being fast because they've paid all that cost upfront. [28:52] But many developers find that this is kind of slow. [28:56] It feels slow to use. [28:58] Once everything is loaded, it's great, but as you saw earlier, [29:01] JavaScript execution on phones makes [29:03] this strategy kind of a loser. [29:04] JavaScript execution is single-threaded. [29:06] Sure, we can parse and compile off-thread, [29:08] but we can't use the preload scanner [29:09] to grab sub-resources if they're embedded in that script. [29:12] We can't speculatively build DOM, or parse CSS, or apply it. [29:15] When you go with one of these tools that [29:17] doesn't use the platform well, you bet the farm [29:19] on a single core, on a phone that [29:21] might be thermally throttled or in a low-power state. [29:25] Good luck. [29:27] So what we're seeing now is something called [29:29] server-side rendering, a.k.a. [29:30] isomorphic rendering, a.k.a. universal JavaScript. [29:34] I haven't looked in a couple of months. [29:36] Is there a new term for this? [29:37] [LAUGHTER] [29:40] I'll take that as a no, OK. [29:42] So the idea is to run JavaScript on the server-- [29:44] the same JavaScript on the server [29:45] that you run on the client-- and then [29:47] send down a pre-computed snapshot of the HTML [29:50] that you were going to send. [29:51] And then you load the gargantuan JavaScript bundle [29:54] and hope that it all works out. [29:55] On my MacBook Pro, or an iPhone with a fast connection, [29:58] or my Pixel, something like that, [30:00] this works out pretty well. [30:01] But for the vast majority of users [30:03] with less-expensive phones or less-good connections, [30:06] you get this crazy uncanny valley. [30:08] When the JavaScript arrives, the main thread [30:09] locks up all the same. [30:11] Until it starts executing and finishes, [30:13] the content might be displayed, but it [30:15] isn't meaningfully interactive. [30:16] Now there's a debate that starts. [30:18] Some folks think that, because maybe you [30:19] can start scrolling this stuff, because browsers are magic [30:22] and they do threaded scrolling-- scrolling actually [30:24] isn't interaction. [30:25] If I can't put my finger down and tap on your UI, [30:28] and have it start responding and doing work for me [30:30] under 100 milliseconds, it isn't loaded. [30:33] It's broken, OK? [30:37] What we really want is progressive interactivity, [30:40] and this is what the PRPL pattern that Sam will go into [30:42] delivers. [30:44] The insight here is that you should only [30:45] load the code that you need right now, if possible, [30:47] for the views that you're actually sending to users. [30:50] And combined with service workers and HTTP/2 Push, [30:54] it's possible to achieve this without over-bundling. [30:56] PRPL and the Polymer App Toolbox represent [30:58] what's possible, once we take that mobile-by-default thing [31:02] seriously. [31:03] And it's night-and-day from where most popular tools are. [31:06] So this is the shop app that you've seen before. [31:08] The Polymer team released it in I/O. [31:09] You can visit it right now at shop.polymer-project.org. [31:12] And here it is running on a desktop browser. [31:14] We get to interactivity very quickly on Wi-Fi, [31:17] and it only takes a few milliseconds of script overall. [31:20] So what? [31:21] You've seen this story before. [31:23] But what about mobile? [31:25] Again, Nexus 5X, same Wi-Fi connection. [31:28] Despite the slower CPU, the app sends down [31:30] an appropriate amount of script, so [31:32] that we get interactive performance [31:34] at under two seconds. [31:35] There's nearly a second and a half of script execution [31:37] overall, but thanks to the granular use [31:40] of HTML imports and HTTP/2 Push, in contrast [31:43] to the major bundling, most of the components load [31:46] with tiny execution slices, which [31:48] means that the content that's already on-screen stays [31:50] interactive. [31:51] This is what mobile-first looks like, [31:53] and it's radically different in a good way. [31:56] The other thing that the PRPL pattern adds [31:58] is a service worker. [31:59] You might be thinking that service workers are [32:01] about handling offline, and while it [32:02] does allow you to do that, that's [32:04] not the primary benefit for most end users. [32:06] Service workers matter because they [32:07] let you deliver reliable performance, [32:10] because they can handle the top-level resource [32:12] and always return something from the cache. [32:14] You can dramatically improve the performance of your apps [32:17] when you use service workers this way. [32:19] That huge variability in network conditions? [32:21] It evaporates when you've done this. [32:24] So this is a chart that Eric Bidelman gathered [32:26] from this year's I/O site. [32:28] It's also a Progressive Web App, but with Polymer 1.0. [32:30] But as you can see from the giant dark green spike, when [32:33] the service worker is active, the distribution of load times [32:36] moves hard to the left. [32:37] And that's a good thing. [32:38] This is very literally what "faster" looks like. [32:41] I'm seeing a lot of teams try to add service workers [32:43] as some sort of transparent pass-through thing, [32:45] using a network-first approach. [32:47] Don't do that. [32:48] Please don't do that. [32:49] Use the PRPL pattern, and make sure [32:51] that your top-level app shell never depends on the network. [32:54] If you do that, you can compete with native apps [32:57] on the experience that you deliver. [32:58] If you saw Darren's keynote this morning, [33:00] you saw exactly that with the CNET Tech Today PWA. [33:05] If you don't do that, though, you [33:07] will never match their performance. [33:09] Until recently, it's been difficult to verify [33:11] in an automated way that your service worker is installing, [33:14] and the rest of your Progressive Web App properties [33:16] are actually met correctly. [33:17] You've heard a lot about Lighthouse, [33:19] but please put it in your CLI, put it [33:23] in your continuous integration system, [33:25] and let it tell you how you're doing. [33:28] So I think it's safe to say that mobile is much, much harder [33:32] than we've collectively understood it to be. [33:35] To make good apps in this environment, [33:37] we need to change our outlook, our tools, and most [33:40] of all, our priorities. [33:42] And the fastest way I know to get [33:43] in touch with that, that ground truth, [33:46] is to test on real hardware. [33:49] So please, if you don't already have a circa 2014-ish Android [33:53] phone, go out and buy something like a Moto G4. [33:56] If you can use one of these, and Chrome Inspect on DevTools, [34:04] you'll find yourself in touch with how it really [34:07] feels to be at the median. [34:09] If you can, get something worse. [34:11] Like, this is an Android One from last year. [34:14] You probably can't buy one. [34:15] But get something worse if you can. [34:17] And if you can't afford any of those, [34:19] please use webpagetest.org to select [34:21] from the list of real mobile devices that [34:24] are sitting in a rack, at your disposal, to test your URLs. [34:27] And whatever you do, implement as much of the PRPL pattern [34:29] as you can. [34:30] Sam will fill you in on the details, [34:32] so stay tuned for that. [34:33] And lastly, Lighthouse and Chrome telemetry [34:35] are potent weapons in your ability to not regress, [34:40] on keeping sure that you're doing the right thing. [34:44] I want to apologize for being a bit of a downer today. [34:47] Usually, I'm telling you about how good PWAs are, [34:49] or how great the experience is that you can deliver. [34:51] And that's all true. [34:53] And there is good news. [34:55] It's that modern web technology makes [34:56] it possible to build truly amazing experiences. [34:59] But it will require a ditching, or radically reworking, [35:02] the way that we're using the slow-by-default tools. [35:05] Addy's got a whole talk tomorrow about what kind of elbow grease [35:08] you really do have to put in if you've [35:10] bought into one of today's major frameworks, [35:12] but I think now that the challenge is much larger [35:16] than you probably thought it was. [35:18] Now that you know, I'm actually very [35:19] confident that the folks in this room and on the live stream [35:21] are going to internalize this, and use it to make [35:23] really great experiences. [35:25] So thank you. [35:25] [APPLAUSE] [35:26] [MUSIC PLAYING]