      [: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."]])})

      " were a great way to identify performance bottlenecks in your application. If your application "
      "was unnecessarily mutating the DOM, Chrome would helpfully show you a transparent overlay over the "
      "parts of the page that were modified."]
     [:p "Here’s an example from Circle’s old haml-coffee/knockout.js frontend. We noticed that the site "
      "was feeling a bit sluggish. The paint rectangles made it obvious that the problem was the sidebar"
      " being re-rendered even though the content stayed the same."]]


    [: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"]
