# High Perf Browser > Browser networking performance optimization — an AI agent skill based on *High Performance Browser Networking* by Ilya Grigorik. Published 2026-02-23 · Updated 2026-08-17 · Architecture & Systems · Free and MIT-licensed Canonical: https://skills.wondel.ai/skills/high-perf-browser/ Source: https://github.com/wondelai/skills/tree/main/high-perf-browser **Install:** `npx skills add wondelai/skills/high-perf-browser --global` ## What is the High Perf Browser skill? High Perf Browser packages Ilya Grigorik’s High Performance Browser Networking as an AI agent skill. It teaches your agent what actually costs time between a click and a painted pixel — DNS, TCP and TLS round trips, HTTP/2 and HTTP/3 behaviour, connection reuse, and the critical rendering path — and how to shorten it. ## Key concepts from High Performance Browser Networking your agent applies - **TCP & TLS Optimization** — Tune TCP settings, minimize TLS handshake overhead, and leverage connection reuse for faster page loads. - **HTTP/2 & HTTP/3** — Use multiplexing, header compression, server push, and QUIC to eliminate head-of-line blocking and reduce latency. - **Resource Loading** — Optimize the critical rendering path — preload, prefetch, and prioritize resources that block first paint. - **Mobile Network Performance** — Design for high-latency, variable-bandwidth mobile networks — radio state management and battery impact. - **WebSocket & SSE** — Choose the right real-time transport — WebSocket for bidirectional, Server-Sent Events for server-to-client streaming. ## When to use High Perf Browser — and when not to Reach for it when: - Largest Contentful Paint is poor and a smaller bundle has not helped, because the time is going on round trips. - Time to first byte looks fine but the page still paints late, and you cannot tell which requests block rendering. - You are choosing between WebSocket, Server-Sent Events and polling for a live feed and guessing at the trade-offs. - The site is fast on your desk and slow on a phone on cellular, and nobody can explain the gap. Reach for something else when: - The bottleneck is a query plan or a saturated worker behind the API — Data-Intensive Apps or System Design fit better. - You want visual polish and perceived-speed cues in the interface itself — Refactoring UI is the design-side tool. - Fonts are what is blocking your first paint — Web Typography covers loading strategy in more detail. - Your service falls over under load rather than loading slowly — Release It! covers stability, not delivery. ## About Ilya Grigorik Google web performance engineer, W3C Web Performance co-chair. Ilya Grigorik is a web performance engineer at Google and co-chair of the W3C Web Performance Working Group. He is one of the foremost authorities on browser networking and web performance optimization. The book: https://openlibrary.org/books/OL26184451M/High_Performance_Browser_Networking ## Example prompts - Optimize the critical rendering path and resource loading for our landing page using high-perf-browser skill _(Web performance)_ - Evaluate whether we should use HTTP/2 server push or preload hints using high-perf-browser skill _(Network optimization)_ - Design a real-time data strategy: WebSocket vs SSE vs polling using high-perf-browser skill _(Architecture)_ - Audit our mobile web performance and suggest network-level optimizations using high-perf-browser skill _(Mobile performance)_ ## Frequently asked questions ### How do I install the High Perf Browser skill? Run `npx skills add wondelai/skills/high-perf-browser --global`. It takes about 30 seconds and needs no account. The High Perf Browser skill then works in Claude, Claude Code, Claude Cowork, Codex, Cursor, OpenClaw and Hermes Agent — anything that reads the open agentskills.io format — and your agent loads it on its own when a task calls for it. It is free and MIT-licensed, and the source is at https://github.com/wondelai/skills. ### Which book is the High Perf Browser skill based on? It packages *High Performance Browser Networking* by Ilya Grigorik — google web performance engineer, W3C Web Performance co-chair. The skill distils the book's method into instructions your agent follows while it works, covering tcp & tls optimization, http/2 & http/3 and resource loading. It sits in the Architecture & Systems part of the library. ### Does this cover backend performance too? No — it stops at the origin. The subject is everything between a user’s device and your first byte, plus what the browser does with the bytes afterwards: DNS lookups, TCP and TLS handshakes, HTTP/2 and HTTP/3 behaviour, connection reuse, cache headers, and which resources block first paint. If the slow part is a query plan or a saturated worker pool, Data-Intensive Apps and System Design are the right skills to load instead. ### Does HTTP/2 mean I should stop bundling and sharding domains? Mostly, and the skill will explain why. HTTP/2 multiplexes many requests over one connection, so domain sharding, spriting and concatenating purely to cut request count become counterproductive — they fragment caching and work against prioritisation. Some bundling still pays for compression ratio and per-request overhead, so it is a smaller-bundles argument rather than a no-bundles one. Server push is the part that aged worst: browsers removed it, and preload hints took over. ### What does HTTP/3 actually change? It moves HTTP off TCP onto QUIC over UDP. The practical wins: no transport-level head-of-line blocking, so a lost packet stalls only its own stream rather than every multiplexed one; a combined transport and TLS handshake costing one round trip, or zero on resumption; and connection IDs that survive a network change, so a phone moving from Wi-Fi to cellular keeps its connection. On a clean low-latency network the gain is small — it pays on lossy mobile links. ### The book is from 2013. Is it out of date? Partly, and it matters which part. The physics do not move — round trips, bandwidth-delay product, TCP slow start, and why latency rather than bandwidth dominates on mobile — and that is most of its value. The specifics have moved: HTTP/3 was standardised nearly a decade after publication, server push shipped and was then removed, and HTTP/2’s original priority scheme was replaced. Check anything version-specific against current browser documentation before shipping it. ## Related - All Architecture & Systems skills: https://skills.wondel.ai/skills/architecture/ - Clean Architecture: https://skills.wondel.ai/skills/clean-architecture/ - Domain-Driven Design: https://skills.wondel.ai/skills/domain-driven-design/ - Data-Intensive Apps: https://skills.wondel.ai/skills/ddia-systems/ - System Design: https://skills.wondel.ai/skills/system-design/ - Release It!: https://skills.wondel.ai/skills/release-it/