<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet type="text/css" href="https://www.aaron-gustafson.com/c/feed.min.css" ?><feed xmlns="http://www.w3.org/2005/Atom"
      xmlns:amg="https://www.aaron-gustafson.com.com/amg-dtd/"><title>Aaron Gustafson: Content tagged DevTools</title><subtitle>The latest 20 posts and links tagged DevTools.</subtitle><id>https://www.aaron-gustafson.com</id><link href="https://www.aaron-gustafson.com/feeds/devtools.xml" rel="self"/><link href="https://www.aaron-gustafson.com"/><author><name>Aaron Gustafson</name><uri>https://www.aaron-gustafson.com</uri></author><updated>2021-12-09T17:44:40Z</updated><entry><id>https://www.aaron-gustafson.com/notebook/links/debug-memory-leaks-with-the-microsoft-edge-detached-elements-tool/</id><title type="html"><![CDATA[🔗 Debug memory leaks with the Microsoft Edge Detached Elements tool]]></title><link href="https://www.aaron-gustafson.com/notebook/links/debug-memory-leaks-with-the-microsoft-edge-detached-elements-tool/" rel="alternate" type="text/html" /><link href="https://blogs.windows.com/msedgedev/2021/12/09/debug-memory-leaks-detached-elements-tool-devtools/" rel="related" type="text/html" /><published>2021-12-09T17:44:40Z</published><content type="html" xml:base="https://www.aaron-gustafson.com"><![CDATA[<p>Memory leaks suck and they proliferate when you slice &amp; dice the DOM using JavaScript. Edge DevTools makes it easy to debug “detached elements” now.</p>]]></content><amg:twitter><![CDATA[Memory leaks suck and they proliferate when you slice & dice the DOM using JavaScript. @MSEdgeDev now makes it easy to debug “detached elements” in DevTools.]]></amg:twitter><category term="JavaScript" /><category term="DevTools" /><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://blogs.windows.com/wp-content/uploads/prod/sites/33/2021/09/1fcfaeac10ed41b08decb59e35dad86b.png" /></entry><entry><id>https://www.aaron-gustafson.com/notebook/links/using-the-chrome-devtools-new-code-coverage-feature-ca96c3dddcaf/</id><title type="html"><![CDATA[🔗 Using the Chrome DevTools new code coverage feature]]></title><link href="https://www.aaron-gustafson.com/notebook/links/using-the-chrome-devtools-new-code-coverage-feature-ca96c3dddcaf/" rel="alternate" type="text/html" /><link href="https://blog.logrocket.com/using-the-chrome-devtools-new-code-coverage-feature-ca96c3dddcaf" rel="related" type="text/html" /><published>2017-04-12T15:40:30Z</published><content type="html" xml:base="https://www.aaron-gustafson.com"><![CDATA[<p>While the name is a bit confusing, this new tool helps you compare the volume of code you’ve authored to the the amount of code that is actually executed by the browser. It’s a cool idea, but you should take it’s results with a grain of salt: This tool is only diagnosing your project based on <em>the current page and/or flow</em> (if it’s a single page app). Be careful not to take the results as gospel and start eliminating code without knowing whether it’s actually unused in all scenarios.</p><p>Now… tie this into an automated testing tool and gather results from a complete run-through of an app or site and you’ve got something you can actually use to improve your site’s performance.</p><p>It’s worth noting that there are static analysis tools for many task runners that can actually run queries against your HTML templates and remove unused styles automatically. I’ve used <a href="https://www.npmjs.com/package/gulp-uncss"><code>gulp-uncss</code></a> on a few projects and found it to work reasonably well (though you have to tune it for any JavaScript-related styles since it only consults your HTML to find matches).</p>]]></content><category term="performance" /><category term="CSS" /><category term="JavaScript" /><category term="DevTools" /><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="https://storage.googleapis.com/blog-images-backup/1*gD8lX40PSemDOZgvT695Mg.png" /></entry></feed>