<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Web Performance on cloudmato.com</title><link>https://cloudmato.com/tags/web-performance/</link><description>Recent content in Web Performance on cloudmato.com</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>cloudmato.com</managingEditor><webMaster>cloudmato.com</webMaster><lastBuildDate>Sun, 14 Jun 2026 18:01:15 +0530</lastBuildDate><atom:link href="https://cloudmato.com/tags/web-performance/index.xml" rel="self" type="application/rss+xml"/><item><title>Understanding HTTP/3: Is It Really Better Than HTTP/2?</title><link>https://cloudmato.com/posts/understanding-http3-vs-http2-http1/</link><pubDate>Sun, 14 Jun 2026 18:01:15 +0530</pubDate><author>cloudmato.com</author><guid>https://cloudmato.com/posts/understanding-http3-vs-http2-http1/</guid><description>&lt;p&gt;Everyone talks about HTTP/3 like it&amp;rsquo;s a free speed upgrade you flip on and forget. It mostly is — but &amp;ldquo;mostly&amp;rdquo; is doing a lot of work in that sentence. HTTP/3 is now used for roughly 35% of all web requests globally [1], so this isn&amp;rsquo;t a research toy anymore. The thing is, almost no one explains &lt;em&gt;why&lt;/em&gt; it&amp;rsquo;s faster, where it actually loses to HTTP/2, and — the question nobody asks — whether your particular site even benefits. Let me walk through it the way I&amp;rsquo;d explain it to a friend over chai.&lt;/p&gt;</description></item><item><title>How React Really Works: Fiber and Batch Rendering Explained</title><link>https://cloudmato.com/posts/how-react-works-fiber-and-batch-rendering-explained/</link><pubDate>Sat, 13 Jun 2026 17:37:28 +0530</pubDate><author>cloudmato.com</author><guid>https://cloudmato.com/posts/how-react-works-fiber-and-batch-rendering-explained/</guid><description>&lt;p&gt;Ever clicked a button in a React app and just&amp;hellip; trusted that the UI would update correctly? Yeah, me too, for years. I never really stopped to think about what happens between &lt;code&gt;setState&lt;/code&gt; and the pixels changing on screen — until I started debugging a component that was re-rendering five times for a single click. That rabbit hole led me straight into Fiber, lanes, and the surprisingly long history of how React decides &lt;em&gt;when&lt;/em&gt; to actually re-render your app.&lt;/p&gt;</description></item><item><title>Chrome DevTools Performance Panel: Analyzing Code Execution</title><link>https://cloudmato.com/posts/chrome-devtools-performance-panel-deep-dive/</link><pubDate>Wed, 10 Jun 2026 18:12:35 +0530</pubDate><author>cloudmato.com</author><guid>https://cloudmato.com/posts/chrome-devtools-performance-panel-deep-dive/</guid><description>&lt;p&gt;Open the Performance panel in Chrome DevTools for the first time and it looks like someone spilled a box of crayons across your screen. Dozens of colored bars, half a dozen tracks, three tabs at the bottom that all seem to show the same thing but slightly differently. No wonder most devs record one trace, get scared, and go back to &lt;code&gt;console.log&lt;/code&gt; debugging. I did exactly that for years - until I actually sat down and learned what each piece means, and now it&amp;rsquo;s the first tool I reach for when something &amp;ldquo;feels slow.&amp;rdquo;&lt;/p&gt;</description></item></channel></rss>