{"id":964,"date":"2024-02-18T04:45:03","date_gmt":"2024-02-18T04:45:03","guid":{"rendered":"https:\/\/musefind.com\/?p=964"},"modified":"2024-02-18T07:11:37","modified_gmt":"2024-02-18T07:11:37","slug":"how-to-benchmark-react-components-the-quick-and-dirty-guide","status":"publish","type":"post","link":"https:\/\/musefind.com\/how-to-benchmark-react-components-the-quick-and-dirty-guide\/","title":{"rendered":"How to Benchmark React Components: The Quick and Dirty Guide"},"content":{"rendered":"\n<p>A React Component works hard. As the user manipulates the state of the application, it may re-render 5, 10, 100 times. Sometimes, that\u2019s a good thing. But if you don\u2019t understand what is causing the re-renders, and whether they are necessary, your app could suffer serious slowdown.<\/p>\n\n\n\n<div class=\"wp-block-rank-math-toc-block\" id=\"rank-math-toc\"><div><strong>In This Article:<\/strong><\/div><nav><ul><li class=\"\"><a href=\"#a-tale-of-two-tables\">A Tale of Two Tables<\/a><\/li><li class=\"\"><a href=\"#how-to-benchmark-a-react-component\">How To Benchmark A React Component<\/a><\/li><li class=\"\"><a href=\"#measuring-update-time\">Measuring Update Time<\/a><\/li><li class=\"\"><a href=\"#fixing-wasted-renders\">Fixing Wasted Renders<\/a><\/li><li class=\"\"><a href=\"#using-perf-in-the-real-world\">Using Perf in the Real World<\/a><\/li><li class=\"\"><a href=\"#bonus-benchmarking-initial-renders\">Bonus: Benchmarking Initial Renders<\/a><\/li><li class=\"\"><a href=\"#final-notes\">Final Notes<\/a><\/li><\/ul><\/nav><\/div>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"a-tale-of-two-tables\">A Tale of Two Tables<\/h2>\n\n\n\n<p id=\"a81f\">A few months after I started at MuseFind, we embarked on a rewrite of our internal software. The key piece in this application was a table that allowed our customer success team to quickly edit, add, and manage collaborations across all <a href=\"https:\/\/musefind.com\/influencer-marketing-latest-trends-best-practices-2018-report\/\">influencer marketing<\/a> campaigns on our platform.<\/p>\n\n\n\n<p id=\"6d86\">The purpose of this rewrite was to improve our team\u2019s efficiency \u2014 speed was the name of the game. But as the table grew in complexity (more and more subcomponents for each row, with inputs and date inputs and buttons), it became more and more slow. Slow to update, slow to reload \u2014 just a pain to use.<\/p>\n\n\n\n<p id=\"3e86\">The solution was to carefully measure the render time of the subcomponents and of the table as a whole, and then begin experimenting. Over time, we managed to cut the table render time to a third of what it was.<\/p>\n\n\n\n<p id=\"d945\">In this article I\u2019ll take you on a quick tour of React\u2019s performance tools, and how to eliminate wasted renders.<\/p>\n\n\n\n<p id=\"3482\">Let\u2019s get started.<\/p>\n\n\n\n<p id=\"b5ba\"><em>Please note: react-addons-perf is not compatible with React 16. Use your DevTools timeline instead. More on that&nbsp;<\/em><a href=\"https:\/\/github.com\/facebook\/react\/issues\/9207\" rel=\"noreferrer noopener\" target=\"_blank\"><em>here<\/em><\/a><em>.<\/em><\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"how-to-benchmark-a-react-component\">How To Benchmark A React Component<\/h2>\n\n\n\n<p id=\"5a60\">We\u2019ll use a simple example: an app that renders a list of 10,000 numbers.<\/p>\n\n\n\n<p id=\"1842\">Half the numbers in the list \u2014 1 to 5,000- are simply generated by incrementing. The other half, in a separate array, are generated by incrementing and then multiplying by a number stored in the app\u2019s state.<\/p>\n\n\n\n<p id=\"2732\">So if the&nbsp;<em>this.state.multiplier<\/em>&nbsp;is 2, the second array would be 2, 4, 6 \u2026 etc up to 10,000.<\/p>\n\n\n\n<p id=\"4d5d\">To change the multiplier from the default of 1, we click a button.<\/p>\n\n\n\n<p id=\"941c\">When clicking the button, only the second array of ListItems should re-render \u2014 only they are affected by the change. Yet we\u2019re experiencing slowness, so we want to investigate whether everything is as it should be.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"measuring-update-time\">Measuring Update Time<\/h2>\n\n\n\n<p id=\"16db\">We\u2019ll start by installing React\u2019s performance tools.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>npm install --save-dev react-addons-perf<\/code><\/pre>\n\n\n\n<p>And then we can import it in our App.js:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>import Perf from 'react-addons-perf'<\/code><\/pre>\n\n\n\n<p id=\"b1fd\">There are four Perf functions that we care about:<\/p>\n\n\n\n<ul>\n<li>Perf.start(): start measuring performance.<\/li>\n\n\n\n<li>Perf.stop()<\/li>\n\n\n\n<li>Perf.printExclusive(): prints total rendering time for components.<\/li>\n\n\n\n<li>Perf.printWasted(): prints wasted renders- we\u2019ll get to this shortly.<\/li>\n<\/ul>\n\n\n\n<p id=\"ef85\">We want to start measuring render time before our component starts updating- before we call&nbsp;<em>setState()<\/em>. Then we can stop the measurement and print the results using the lifecycle method&nbsp;<em>componentDidUpdate()<\/em>.<\/p>\n\n\n\n<p>Here\u2019s what our console will look like after clicking the button:<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"720\" height=\"165\" src=\"https:\/\/musefind.com\/wp-content\/uploads\/2024\/02\/our-console-will-look-like.png\" alt=\"Our console will look like\" class=\"wp-image-966\" srcset=\"https:\/\/musefind.com\/wp-content\/uploads\/2024\/02\/our-console-will-look-like.png 720w, https:\/\/musefind.com\/wp-content\/uploads\/2024\/02\/our-console-will-look-like-300x69.png 300w\" sizes=\"(max-width: 720px) 100vw, 720px\" \/><\/figure>\n\n\n\n<p id=\"91f7\">Our App renders took 94.75ms to render, and rendered only once.<\/p>\n\n\n\n<p id=\"e349\">Our ListItem component took 53.84ms, and rendered 10,000 times (this is including all instances of the components, not individual render time).<\/p>\n\n\n\n<p id=\"df30\">In the second table, we can see \u2018wasted\u2019 time \u2014 when the component re-rendered but nothing had actually changed.<\/p>\n\n\n\n<p id=\"8b25\">We have 5,000 wasted ListItem renders. Not good.<\/p>\n\n\n\n<p id=\"25e1\">These renders are \u2018wasted\u2019 in the sense that only the ListItems affected by the multiplier will have their render actually changed when we click the button. There\u2019s no point in having them re-render.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"fixing-wasted-renders\">Fixing Wasted Renders<\/h2>\n\n\n\n<p id=\"598b\">Fortunately, <a href=\"https:\/\/musefind.com\/react-lifecycle-methods\/\">React furnishes us with a handy lifecycle method<\/a> called&nbsp;<em>shouldComponentUpdate()<\/em>&nbsp;for these types of situations.<\/p>\n\n\n\n<p id=\"6d6b\">It gives us fine-grained control of when our component will re-render.<\/p>\n\n\n\n<p id=\"9d30\">We can check for certain conditions, returning a boolean that React uses to determine whether it will call&nbsp;<em>render()<\/em>&nbsp;on the component, or leave it as is.<\/p>\n\n\n\n<p id=\"8d69\">Here\u2019s what it would look like for ListItem:<\/p>\n\n\n\n<p id=\"21ae\">If the text prop hasn\u2019t changed, there\u2019s no reason to change the component\u2019s appearance via a re-render.<\/p>\n\n\n\n<p id=\"b7b0\"><em>Note that we don\u2019t use the nextState argument in shouldComponentUpdate()- I left it there for reference.<\/em><\/p>\n\n\n\n<p id=\"7ab2\">Now let\u2019s re-run our Perf.<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"720\" height=\"150\" src=\"https:\/\/musefind.com\/wp-content\/uploads\/2024\/02\/Our-Perf.png\" alt=\"Our Perf\" class=\"wp-image-967\" srcset=\"https:\/\/musefind.com\/wp-content\/uploads\/2024\/02\/Our-Perf.png 720w, https:\/\/musefind.com\/wp-content\/uploads\/2024\/02\/Our-Perf-300x63.png 300w\" sizes=\"(max-width: 720px) 100vw, 720px\" \/><\/figure>\n\n\n\n<p id=\"1d64\">We\u2019ve cut our total render time down by 30ms, and eliminated all wasteful renders.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"using-perf-in-the-real-world\">Using Perf in the Real World<\/h2>\n\n\n\n<p id=\"36b9\">Most of the components you\u2019ll be benchmarking won\u2019t be nearly this simple. But the Perf tools are a valuable way to identify which components are problems.<\/p>\n\n\n\n<p id=\"41aa\">Here\u2019s an example of&nbsp;<em>Perf.printWasted()<\/em>&nbsp;from MuseFind\u2019s administrative table component:<\/p>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"720\" height=\"420\" src=\"https:\/\/musefind.com\/wp-content\/uploads\/2024\/02\/example-of-Perf.printWasted.png\" alt=\"Example of Perf.printWasted()\" class=\"wp-image-968\" srcset=\"https:\/\/musefind.com\/wp-content\/uploads\/2024\/02\/example-of-Perf.printWasted.png 720w, https:\/\/musefind.com\/wp-content\/uploads\/2024\/02\/example-of-Perf.printWasted-300x175.png 300w\" sizes=\"(max-width: 720px) 100vw, 720px\" \/><\/figure>\n\n\n\n<p id=\"df48\">These wasted times aren\u2019t long at all, thankfully \u2014 but you can see that of the wasteful renders, the Header component is the main problem, with its subcomponents Toolbar and PopoverMenu accounting for almost all of the wasted render time.<\/p>\n\n\n\n<p id=\"e66c\">Those two components are prime candidates for adding&nbsp;<em>shouldComponentUpdate()<\/em>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"bonus-benchmarking-initial-renders\">Bonus: Benchmarking Initial Renders<\/h2>\n\n\n\n<p id=\"4632\">Sometimes you want to not just benchmark when the component updates, but also how long it takes to render completely the first time around.<\/p>\n\n\n\n<p id=\"5c50\">In short, we want to measure the time between&nbsp;<em>componentWillMount()&nbsp;<\/em>and&nbsp;<em>componentDidMount().<\/em><\/p>\n\n\n\n<p id=\"9251\"><em>Perf.start()<\/em>&nbsp;can\u2019t be placed in the&nbsp;<em>componentWillMount(),&nbsp;<\/em>however, so we\u2019ll have to be a little more manual.<\/p>\n\n\n\n<p id=\"54d2\">This will give you a logged out time in milliseconds- not as fancy as Perf, but a useful metric for how long it takes to boot up your app.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"final-notes\">Final Notes<\/h2>\n\n\n\n<p id=\"ecfa\">As the docs page&nbsp;<a href=\"https:\/\/facebook.github.io\/react\/docs\/perf.html\" rel=\"noreferrer noopener\" target=\"_blank\">proudly proclaims<\/a>, React is fast as it is.<\/p>\n\n\n\n<p id=\"6697\">However, that doesn\u2019t mean it\u2019s free from performance slowdowns caused by unnecessary re-renders \u2014 especially in complex apps with hundreds of children.<\/p>\n\n\n\n<p id=\"d21f\">Using Perf on high-level components can give you an idea of which children are the problem, so you can keep your app quick and snappy.<\/p>\n\n\n\n<p id=\"9827\">I hope this article has been useful \u2014 if it has, let me know by hitting the green heart below.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>A React Component works hard. As the user manipulates the state of the application, it may re-render 5, 10, 100 times. Sometimes, that\u2019s a good thing. But if you don\u2019t understand what is causing the re-renders, and whether they are necessary, your app could suffer serious slowdown. A Tale of Two Tables A few months &#8230; <a title=\"How to Benchmark React Components: The Quick and Dirty Guide\" class=\"read-more\" href=\"https:\/\/musefind.com\/how-to-benchmark-react-components-the-quick-and-dirty-guide\/\" aria-label=\"More on How to Benchmark React Components: The Quick and Dirty Guide\">Read more<\/a><\/p>\n","protected":false},"author":5,"featured_media":965,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[],"_links":{"self":[{"href":"https:\/\/musefind.com\/wp-json\/wp\/v2\/posts\/964"}],"collection":[{"href":"https:\/\/musefind.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/musefind.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/musefind.com\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/musefind.com\/wp-json\/wp\/v2\/comments?post=964"}],"version-history":[{"count":4,"href":"https:\/\/musefind.com\/wp-json\/wp\/v2\/posts\/964\/revisions"}],"predecessor-version":[{"id":1031,"href":"https:\/\/musefind.com\/wp-json\/wp\/v2\/posts\/964\/revisions\/1031"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/musefind.com\/wp-json\/wp\/v2\/media\/965"}],"wp:attachment":[{"href":"https:\/\/musefind.com\/wp-json\/wp\/v2\/media?parent=964"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/musefind.com\/wp-json\/wp\/v2\/categories?post=964"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/musefind.com\/wp-json\/wp\/v2\/tags?post=964"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}