/
Navigation
Chronicles
Browse all articles
Explore
Semantic exploration
Research
Entity momentum
Nexus
Correlations & relationships
Story Arc
Topic evolution
Drift Map
Semantic trajectory animation
Posts
Analysis & commentary
Pulse API
Tech news intelligence API
Browse
Entities
Companies, people, products, technologies
Domains
Browse by publication source
Handles
Browse by social media handle
Detection
Concept Search
Semantic similarity search
High Impact Stories
Top coverage by position
Sentiment Analysis
Positive/negative coverage
Anomaly Detection
Unusual coverage patterns
Analysis
Rivalry Report
Compare two entities head-to-head
Semantic Pivots
Narrative discontinuities
Crisis Response
Event recovery patterns
Connected
Search: /
Command: ⌘K
Embeddings: large
TEXXR

Chronicles

The story behind the story

← → days · ↑ ↓ browse · Enter similar · o open

An in-depth look at the latencies introduced at various points, from input devices to what is displayed on the screen, that make apps feel slow

You spend lots of time waiting on your computer.  You pause while apps start and web pages load.  Spinner icons are everywhere. Tweets: @marcedwards Tweets: Marc Edwards / @marcedwards : “Hardware gets faster, but software still feels slow. What gives?” “...action latencies should be ~100ms or less to avoid user perception of delay.” Slow software: https://www.inkandswitch.com/ ...

inkandswitch.com Mark McGranaghan

Context & Ripple Effects

Ink & Switch's breakdown arrives amid a stretch of coverage showing that raw hardware speed is no longer the bottleneck users feel: Apple's slow Mac refresh cycle was already blamed on diminishing PC hardware gains, while Microsoft confirmed Spectre patches imposing single-digit slowdowns, with outsized pain on older chips and I/O-heavy servers.

Two months before this piece, Apple's first Marzipan iOS-on-Mac apps were called out as sluggish and non-standard — concrete evidence that software layers, not silicon, were where responsiveness was being lost. The article gives that complaint a framework: an inventory of every latency between input device and lit pixel, against the ~100ms perception threshold Marc Edwards cites.

First-order effects

  • App developers gain a diagnostic map of where delay actually accumulates — input devices, event handling, rendering, display — replacing vague 'slow app' complaints with per-stage targets under the ~100ms action-latency budget.
  • Platform vendors are directly implicated: the sluggish Marzipan ports and spinner-laden startup paths the article describes are now measurable failures against a published standard rather than matters of taste.

Second-order effects

  • Hardware makers face pressure to demonstrate end-to-end responsiveness rather than benchmark wins — a pressure Apple answered two years later with the M1's extraordinary performance-and-efficiency gains, which attack exactly the software-feels-slow gap this piece documents.
  • Network-side players join the effort from the other direction: the L4S standard finalized in January 2023, backed by Apple, Google, Comcast, and Nvidia, extends the same latency-reduction agenda to the transport layer, since web-page load waits are among the delays the article catalogs.

Third-order effects

  • If the pattern holds, competitive differentiation in computing shifts from peak throughput to perceived latency across the full stack — input, OS, framework, network — making responsiveness budgets a first-class engineering constraint alongside power and cost.
  • Security and abstraction layers that add latency (as Spectre mitigations did) will increasingly be weighed against user-perceptible cost, forcing explicit trade-offs between isolation and interaction speed at the architecture level.

The trend: Computing is reorienting from maximizing hardware speed toward minimizing perceived latency across the entire stack, from input devices through frameworks to network protocols.