<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Reading List</title>
    <link>https://reading-list.oddship.net</link>
    <description>A curated linklog of essays, posts, papers, and notes.</description>
    <atom:link href="https://reading-list.oddship.net/tags/performance/rss.xml" rel="self" type="application/rss+xml" />
    <lastBuildDate>Sat, 12 Sep 2026 22:57:00 +0530</lastBuildDate>
    
      <item>
        <title>The browser&#x27;s main thread is expensive</title>
        <link>https://reading-list.oddship.net/notes/2026-09-12-browser-main-thread-expensive/</link>
        <guid>https://reading-list.oddship.net/notes/2026-09-12-browser-main-thread-expensive/</guid>
        <pubDate>Sat, 12 Sep 2026 22:57:00 +0530</pubDate>
        <description>Logged at IST: 2026-09-12 22:57 IST
What it is: kciter’s interactive article on why browser main-thread time is the scarce resource behind jank, slow input, and broken animation.
Gist: The core model is simple: JavaScript, event handlers, framework internals, style calculation, layout, paint, and most of the rendering pipeline all compete on one main thread. At 60Hz there are only about 16.6ms per frame, and less than that in practice; a long task blocks input and paint, so “my code is fast enough” is the wrong frame if it monopolizes the thread.
The article organizes the fixes into two famili…</description>
      </item>
    
  </channel>
</rss>
