[{"_1":2,"_114":-5,"_115":-5},"loaderData",{"_3":4,"_42":43},"root",{"_5":6,"_15":16,"_21":22,"_34":35},"ENV",{"_7":8,"_9":10,"_11":12,"_13":14},"MODE","production","SENTRY_DSN","https://4e34045e065e0a3ef57135ae5020f388@o4506001960468480.ingest.sentry.io/4506001960599552","AMPLITUDE_INIT","12e15cca4c978dad4bb7dc430e747471","CONVERT_KIT_FORM_ID","7241351","requestInfo",{"_17":18},"userPreferences",{"_19":20},"theme","light","newsLetterData",{"_23":24,"_32":33},"newsletterImage",{"_25":26,"_27":28,"_29":30,"_31":30},"src","https://res.cloudinary.com/dinypqsgl/image/upload/f_webp/c_scale,h_150,w_150/b_transparent/r_max/v1/blog/me?_a=DATAg1eAZAA0","srcSet","https://res.cloudinary.com/dinypqsgl/image/upload/f_webp/c_scale,h_150,w_150/b_transparent/r_max/v1/blog/me?_a=DATAg1eAZAA0 1x, https://res.cloudinary.com/dinypqsgl/image/upload/f_webp/c_scale,h_300,w_300/b_transparent/r_max/v1/blog/me?_a=DATAg1eAZAA0 2x","width",150,"height","showNewsLetter",true,"honeypotInputProps",{"_36":37,"_38":39,"_40":41},"nameFieldName","name__confirm","validFromFieldName","from__confirm","encryptedValidFrom","bZtELhlA3Lvs7rMl9+uIlhjZFG4UiUKgslvEVMaqVbHbbLozneRYguQ=","routes/blog._index",{"_44":45,"_83":84,"_87":88},"featuredPost",{"_46":47,"_67":68,"_69":70,"_79":80,"_81":82},"matter",{"_48":49,"_61":62,"_63":64,"_65":66},"data",{"_50":51,"_52":53,"_54":55,"_56":57,"_58":59,"_60":57},"tag","workshop","title","Web Performance Fundamentals","date","2025-08-12T00:00:00.000Z","description","My key takeaways from Todd Gardner's Frontend Master's workshop.","hero","https://res.cloudinary.com/dinypqsgl/image/upload/v1755017483/blog/20-web-performance/web-perf_k21qjz.png","subtitle","excerpt","","isEmpty",false,"content","\nI recently completed a workshop on Frontend Masters,\nand this blog post will serve as a repository for my key takeaways,\nbaseline understanding, and overall reference guide to the fundamentals of web performance.\n\nShout out to Todd Gardner for that awesome workshop. A lot of the stats, if not all of the ones I mention,\ncan be found in his slide deck! [Here are his slides.](https://github.com/toddhgardner/fundametals-of-web-performance#course-slides)\n\n## A Shared Understanding\n\nBefore we can even begin talking about performance, we need to align as developers on what\nperformance pertains to in the context of the web. For our purposes, we can think of performance as\n**the speed and efficiency with which a web page loads, renders, and responds to interactions\nfrom visitors**.\n\nNow, the next thing we need to establish is **why** performance matters.\nPerformance impacts our user experience (which is important because if our users aren't happy,\nthen our revenue will suffer), and it can also affect our search engine rankings, as page speed is a known ranking factor for Google,\nand lastly, it can impact our online advertising -- if our pages are slow to load,\nwe may lose potential customers before they even see our ads and each ad therefore becomes more expensive\nfor our ad sponsors.\n\nIn fact, [WPO Stats](https://wpostats.com/) is a collection of several different case studies that\ndemonstrate the impact of performance on user experience and business metrics. If you don't have time\nto go through any of the case studies, I'll leave you with this statistic... 40% of users\nabandon a site at 3 seconds of loading 🫢. So you can see how crucial it is to optimize our web performance,\nsince a slow site equates to lost potential revenue and -- the thing I care a lot about -- subpar user experiences.\n\nBut, what does \"fast\" really mean? Who defines \"fast\"? I'll give you a hint, it's not you 😆! Fast is\na subjective measure that can vary greatly depending on the context. But for our purposes, the\npeople who define \"fast\" are our customers, our competitors, and search engines.\n\n### People - we're imperfect\n\nWhen it comes to our users, there's a fundamental truth you have to realize about folks -- they have\nshoddy memories. If the actual time it takes for something to occur is 10 seconds, they might perceive it\nas 20 seconds, and when they're recounting it to their friends, they'll remember it as 30 seconds. And so,\nwe can see that perceived performance and not making our users wait is critical for our success. However,\npeople are people and therefore can be understood, at least somewhat, via the lens of psychology.\n\nNot all waiting is the same kind of waiting. For example -- and keep this list in mind when you're doing anything\n-- the following things factor into how \"slow\" or \"fast\" a wait feels to a person.\n\n1. ⏳ People want to start, so if you make them wait to start, it feels slow.\n2. 😴 If people are _bored_, waiting feels slower.\n3. 😬 If people are _anxious_, waiting feels slower.\n4. 🤔 _Unexplained_ waiting feels slower.\n5. 🕰️ _Uncertain_ waiting feels slow — tell them how long a thing could take.\n6. 🏆 People will wait longer for high-value things — think about your mortgage application; you’d wait 30 seconds to a minute for that bad boy since it’s so damn important.\n\n### Our competitors\n\nWhen it comes to speed, there's an adage that's apt for when trying to determine if you're \"fast enough\".\nWhen a gazelle is running from a lion, it doesn't have to be the fastest gazelle, it just has to be faster than the slowest gazelle.\nA similar parallel can be drawn to our competitors, albeit much less morbid.\nIn the context of web performance, you don't have to be the fastest site on the internet, you just have to be faster than your slowest competitor. This means keeping an eye on your competitors' performance and ensuring that you're at least keeping pace, if not surpassing them.\n\nMoreover, we need to keep `Weber's Law` in mind. Weber's Law states that the perceived difference between two stimuli is proportional to the magnitude of the stimuli.\nBasically, we need a 20% difference in performance to make a noticeable impact on user perception. So what's that mean practically?\nIf we're Target and our website is loading in at 3 seconds and our competitor is loading in at 2.7 seconds,\nthe difference isn't that great, from a percentage point of view, so we're probably fine being at 3 seconds.\n\n\n\nAs shown in the above image, the magnitude of the change is the same between the two scenarios, we are increasing the\ntotal count by **10**, however, the percentage difference is quite different. In the first example, we're going from **10** to **20** and in the\nsecond example we're going from **110** to **120**. The first example is a 100% increase, while the\nsecond is only a 9.09% increase. Just by looking at these two images, we can tell, that the same absolute change\nhas different perceived impacts based on the context 🤯.\n\n## Measuring things\n\nWhen it comes to improving something, I'm a big believer that you need to be able to measure it! If I want to track\nwhether or not I'm getting stronger in the gym, I need to keep track of how much I'm lifting over time -- otherwise,\nhow do I know if I'm improving?! When it comes to web performance, the same principle applies. We need to measure our performance metrics to understand where we stand and how we can improve.\nThe bread and butter charts used for measuring web performance are waterfall charts and flame charts (which are indeed intimidating).\n\n\n\nIn the pre-single page application (SPA) era, developers relied on load and DOMContentLoaded events to gauge\nperformance. With client-side rendering, these became less representative—initial HTML was often minimal, and\nmuch of the UI was built in-browser. Today, we focus on Core Web Vitals, a set of metrics that measure\nreal-world loading, interactivity, and visual stability. They matter for both user experience and Google Search rankings.\n\nAt a high level, the core web vitals are:\n\n1. 🖼️ _Largest Contentful Paint (LCP)_: how fast the largest visible element loads in. This tends to be images, videos, css background images, text elements. Basically,\n **how fast your site visibly loads**.\n2. 👀 _Cumulative Layout Shift (CLS)_: how _smoothly_ and _predictably_ do elements load in the page.\n This is important because unexpected shifts can lead to a poor user experience. Also, this is why\n you see loading skeletons all over the place, they help prevent layout shifts.\n3. ⌨️ _Interaction to Next Paint (INP)_: how responsive your page is to user interactions (keyboard, clicks, but not scrolling). Basically,\n how quickly users can interact with the page.\n4. 👾 _Other metrics_:\n - _First Contentful Paint (FCP)_: what's the first time we've shown the user something; how fast our site shows something.\n - _Time to First Byte (TTFB)_: measures the time it takes for the browser to receive the first byte of data from the server after a user requests a page.\n\nNote: I'm not going to discuss the [Performance API](https://developer.mozilla.org/en-US/docs/Web/API/Performance) in this post, but it's worth noting that the Performance API is a powerful tool for measuring web performance inside\nthe browser.\n\n## Testing\n\nWhen it comes to testing your web performance, it's important to establish _where_ you want to test from.\nThe options you have to choose from are the lab (simulated environments) and the field (real user environments).\nMost folks tend to lean on the lab for initial testing due to its controlled conditions, but the field provides invaluable insights into real-world performance.\n\nTesting is also where we start caring about statistics 📊! I know, I know, statistics aren't really linked to\ntesting or measuring, but they are needed to help analyze the data we're tracking -- and if you're like me,\nI have a hard time understanding stats 😅.\n\nWhen measuring user experience, we look at **percentiles**, not **averages**.\nPercentiles show the cutoff where a certain percentage of values fall below;\naverages just add everything up and divide by the count.\nPercentiles reveal the spread, averages show the middle. So when I say p75 in web performance,\nI mean the 75th percentile — 75% of visits are faster than that threshold, 25% are slower.\n\n\n\n### Tools\n\nFor gathering lab data, we can use tools like:\n\n- [PageSpeed Insights](https://pagespeed.web.dev/)\n- [WebPageTest](https://www.webpagetest.org/)\n- [Lighthouse - but locally](https://developer.chrome.com/docs/lighthouse/overview/)\n\nFor local testing, as I mentioned, we can use Lighthouse! It's baked into our browser's DevTools,\nassuming you're using a Chromium based browser, making it super convenient to run audits on your web pages.\n_Note_: having your dev tools open impacts the test results. Make sure that you [undock](https://stackoverflow.com/questions/20220090/undock-chrome-developer-tools)\nyour dev tools so that your test run isn't impacted.\n\n## Setting Goals\n\nAlright, so this is going to seem painfully obvious, but I have to state it nonetheless.\nWe can't go around trying to fix everything.\nWe do not have an infinite amount of time to improve our web vitals, and to be frank, it might not even be necessary.\n\n

We need to purposefully set goals

\n\nAs mentioned above, fast is a **subjective** user perception. For different groups, fast means **different** things. And\nwith all that being said, I'm trying to hammer home the idea that we need to **purposefully** set goals. For example,\nif we are able to see a correlation between our business metrics and web vitals, maybe it's worth looking into said web vitals.\nFor instance, say the conversion rate on our e-commerce store dips\nwhenever there's a huge increase in CLS, maybe that's worth looking into? I'm not necessarily saying that a bad CLS score\nis causing the dip in conversion but it is worth investigating for sure.\n\nIn addition to investigating the business impact of our web vitals, don't forget about `Weber's Law`! In order for our customers\nto take notice of a difference in our site's performance, whether they're comparing with our old site or our competitors,\na minimum of a 20% difference is what is required.\n\n## Improving\n\nLet's jump into the meat 🍖 and potatoes 🥔 of this post! Let's talk about how to make some gains 💪!\nFor anyone reading this later (including myself), try to keep the following in mind:\n\n1. 🧘 Focus on the _easiest_ fixes for your _worst_ metrics from real user data, where possible.\n2. 🤔 Don't try to do everything. Sometimes we're fast enough.\n3. ⚡ The most basic rule of performance.... **do fewer things**.\n\n### Time to First Byte (TTFB)\n\nWhen it comes to improving our web vitals, TTFB is the one metric that isn't necessarily impacted\nwith how our code is written but rather how it's delivered to our users -- this is the operations\nside of the performance question 🛣!\n\nOne of the most basic things we can do is ensure that we are sending content via a compression algorithm\nlike Brotli or gzip. Additionally, using a Content Delivery Network (CDN) -- a hopefully geographically distributed network\nof servers that cache and serve content closer to our users. In addition to offloading work from our own internal servers,\nit hopefully reduces latency and speeds up delivery of content to our users!\n\nUtilizing efficient protocols when delivering our content will also improve our TTFB! Refer to the below table.\n\n

\n\n| Feature / Constraint | HTTP/1.1 🚗 | HTTP/2 🚅 | HTTP/3 ✈️ |\n| ----------------------- | ------------------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------------- |\n| Transport | TCP | TCP | QUIC (UDP) |\n| Request Handling | Sequential; multiple TCP connections needed | Multiplexed streams over a single TCP connection | Multiplexed streams over QUIC with no TCP “head-of-line” blocking |\n| Parallel Requests Limit | ~6–10 TCP connections per domain | Usually 1 connection per domain; streams limited by server (10–100 typical) | 1 QUIC connection per domain; streams limited by server (often >100) |\n| Head-of-Line Blocking | Yes (per connection) | Yes (per TCP connection, affects all streams) | No (independent streams over QUIC) |\n| Header Compression | None (except gzip for body) | HPACK | QPACK |\n| Encryption | Optional (HTTP or HTTPS) | Usually HTTPS by default | Always HTTPS |\n| Setup Time | TCP handshake + optional TLS handshake | Faster TLS (fewer round trips) | Fastest (0-RTT possible) |\n| Fallback | Works everywhere | Falls back to 1.1 | Falls back to 2 or 1.1 |\n| Best Use Today | Legacy systems | Widely adopted, works for most modern sites | Growing adoption, best for high-latency or mobile-heavy traffic |\n\n

\n\nThe TLDR of that table, if you didn't go through it 😅:\n\n| Protocol | Analogy | Description |\n| ----------- | --------------------- | --------------------------------------------- |\n| HTTP/1.1 🚗 | Single-lane road | One car at a time. |\n| HTTP/2 🚙 | Multi-lane road | Many cars, but if one crashes, traffic slows. |\n| HTTP/3 🚀 | Smart multi-lane road | If one crashes, others keep moving. |\n\nSo, if you're having issues with TTFB, look at _how_ you're delivering content to your users and talk to your ops engineers -- if you have\nops engineers that is 👀!\n\n### First Contentful Paint\n\nFirst Contentful Paint (FCP) is how fast our site loads **something** -- anything really. CSS and Fonts are\n**render blocking** by default so when you're including those types of assets, they prevent the page from rendering\nuntil they complete. This is why [minification 📰]() and [bundling 🎥](https://youtu.be/5IG4UmULyoA) are important for these kinds of assets!\nThe faster we enable the browser to parse and interpret the rules, the faster our page will render.\n\nWhat's important for this particular web vital is starting the download of our `critical path` resources as soon as possible.\nWhat we want to do here is utilize strategies like preloading resources wherever possible. The following can be preloaded via the\n[link tag](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/rel/preload):\n\n- style\n- script\n- image\n- font (CORS)\n- fetch (CORS)\n\nWe can remove resources from that `critical path` via **lazy loading**. Lazy loading is a strategy that amounts to\nloading in resources only as they are needed, think a user scrolling or perhaps after a button press, loading in some\nJS code from our server.\n\nBy default, JavaScript is parser-blocking: when the browser encounters a script,\nit halts HTML parsing and delays rendering until that script has been fetched, parsed,\nand executed on the main thread. In order to halt this parser blocking behavior, we can utilize the\n`defer` and `async` attributes on our `\n ```\n\n- ⏳ **Defer** - Downloads in parallel with HTML parsing, executes after parsing is complete, right before DOMContentLoaded.\n Execution order is preserved.\n ```html\n \n \n ```\n\n### Largest Contentful Paint\n\nLargest Contentful Paint (LCP) tends to be an image or video resource. So the question is, how quickly\ncan that resource load and render? That's why TTFB and FCP matter -- the faster the browser\ncan get and start painting the main content, the better our LCP score will be.\n\nThe components of LCP are `resource delay`, `resource duration`, and `render delay`. The tactics we\ncan use to improve our LCP score are _even_ more lazy loading, eager loading, and optimizing our images! Did\nyou know that `images` and `iframes` accept a [loading attribute](https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Lazy_loading#images_and_iframes)? Well, they do ⚡, so we can set this\nequal to lazy and get some performance gains.\n\nFor LCP, we can also utilize `eager loading`, the idea of loading critical path resources as soon as possible. This can be\naccomplished by, assuming the resource is an image or something to that effect, using a `` tag to preload our image asset...\n`` or by setting a [`fetchpriority`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/fetchPriority) on our important\n`img` elements... `

`!\n\nAnother great tactic is compressing our images and only sending the bytes truly necessary for rendering our resources\nat an acceptable quality level. You might be saying, but bro 🤨, didn't we already talk about compressing via Brotli or gzip,\nso why would I need to compress my images further?\n\nThe key difference is that Brotli and gzip are text-based compression algorithms. They're awesome for HTML, CSS, and JavaScript\nbecause those files are just text, which compresses really well. Images, on the other hand, are already stored in compressed\nformats like JPEG, PNG, or WebP. Running them through gzip won't magically shrink them more — in fact, it usually does nothing 😅.\n\nThat's why we need image-specific compression: things like resizing to responsive breakpoints, serving WebP/AVIF, stripping out\nmetadata, and dialing in quality settings. These steps cut actual image bytes, which is often the biggest win for\nLargest Contentful Paint (LCP).\n\n

\n\n| Format | Compression | Typical Size 📦 | Quality 🖼️ | Browser Support 🌐 | Best Use Case |\n| ------- | -------------- | --------------------- | ----------------------------------------------- | ----------------------------- | ----------------------------------------- |\n| JPEG 📸 | Lossy | Medium–Small | Good, but can show artifacts | Universal ✅ | Photos, complex images |\n| PNG 🖌️ | Lossless | Large | Excellent (no artifacts, supports transparency) | Universal ✅ | Logos, icons, images needing transparency |\n| WebP 🚀 | Lossy/Lossless | Smaller than JPEG/PNG | High (supports transparency + animation) | Widely supported (not IE) | General purpose replacement for JPEG/PNG |\n| AVIF 🌈 | Lossy/Lossless | Smallest | Excellent (HDR support) | Growing (all modern browsers) | Cutting edge for photos, hi-res graphics |\n\n

\n\nWe can also utilize responsive images to help improve our LCP.\nIt makes no sense to serve a 2800px-wide image to a mobile device with a 600px screen.\nInstead, we can use the `srcset` attribute to define multiple image sources at different sizes.\nThe browser will automatically choose the most appropriate file based on the user's screen resolution and viewport size.\nFor even more control, we can wrap our images in the `

Blog

My year at an agile agency

Tear it up with Taran!

Tear it up with Taran!