      [:article
       [:p "The console-style instrumentation panel drops down when we hit Ctrl+j and we can see it update in real-time "
        "as components are rendered."]
-      [:p "Now it’s easy to identify the bottlenecks and measure the effects of our optimizations on render times."]])})
+      [:p "Now it's easy to identify the bottlenecks and measure the effects of our optimizations on render times."]])})


    [:article
     [:p "React diffs against its virtual copy of the DOM before it writes to the actual DOM, so paint rectangles "
      "can’t show you where you’re rendering too much. The benefit of React’s global optimization is that we never "
      "make those slow DOM updates, but the cost is that we can’t use all of the browser’s built-in tools for debugging."]
     [:p "My first approach to the problem was to hack the paint rectangles back into the page. I had each "
      "component generate a random border color each time it rendered, forcing React to change the DOM. By using a "
      [:a {:href "https://github.com/circleci/frontend/blob/7cf4a54480bc5aa772f465afced98d8f3d84dc8a/src-cljs/frontend/utils.clj#L51"}

    [:article
     [:p "This is a nice step forward. Like paint rectangles, it gives us a visual indication of possible "
      "performance bottlenecks. But we can do so much better. Paint rectangles can show us the regions that "
      "are being re-rendered, but that's not how we think of components when we write and use them. Like any "
      "function, we want to refer to them by their name. The paint rectangles also don't tell us how long it "
      "takes to render each region, so we don't know which component to prioritize."]]

    [:article
     [:h3 "Instrumenting components"]
