<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Performance on Commentary of Takao</title><link>https://takao.blog/en/tags/performance/</link><description>Recent content in Performance on Commentary of Takao</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>Commentary of Takao</copyright><lastBuildDate>Sat, 13 Jun 2026 23:11:50 +0900</lastBuildDate><atom:link href="https://takao.blog/en/tags/performance/index.xml" rel="self" type="application/rss+xml"/><item><title>Speeding Up assets Loading using DNS-Prefetch and Preconnect</title><link>https://takao.blog/en/web/performance-dns-prefetch-preconnect/</link><pubDate>Wed, 15 Apr 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/performance-dns-prefetch-preconnect/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Speeding Up assets Loading using DNS-Prefetch and Preconnect" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;Every external resource — fonts, scripts, images, API endpoints — requires a network connection. The overhead of &lt;strong&gt;DNS resolution&lt;/strong&gt;, &lt;strong&gt;TCP handshake&lt;/strong&gt;, and &lt;strong&gt;TLS negotiation&lt;/strong&gt; can add hundreds of milliseconds to page load time. &lt;strong&gt;Resource hints&lt;/strong&gt; like &lt;code&gt;dns-prefetch&lt;/code&gt; and &lt;code&gt;preconnect&lt;/code&gt; let you tell the browser to perform these steps &lt;strong&gt;in advance&lt;/strong&gt;, before the resource is actually needed.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="the-cost-of-connection"&gt;The Cost of Connection
&lt;/h2&gt;&lt;p&gt;Establishing an HTTPS connection involves multiple round trips:&lt;/p&gt;
&lt;table&gt;
	&lt;thead&gt;
			&lt;tr&gt;
					&lt;th&gt;Step&lt;/th&gt;
					&lt;th&gt;Latency (approx.)&lt;/th&gt;
			&lt;/tr&gt;
	&lt;/thead&gt;
	&lt;tbody&gt;
			&lt;tr&gt;
					&lt;td&gt;DNS lookup&lt;/td&gt;
					&lt;td&gt;20-120 ms&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;TCP handshake&lt;/td&gt;
					&lt;td&gt;1 RTT&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;TLS negotiation&lt;/td&gt;
					&lt;td&gt;2 RTT&lt;/td&gt;
			&lt;/tr&gt;
			&lt;tr&gt;
					&lt;td&gt;&lt;strong&gt;Total&lt;/strong&gt;&lt;/td&gt;
					&lt;td&gt;&lt;strong&gt;3+ RTT&lt;/strong&gt;&lt;/td&gt;
			&lt;/tr&gt;
	&lt;/tbody&gt;
&lt;/table&gt;
&lt;p&gt;On a 3G connection (300ms RTT), that&amp;rsquo;s nearly &lt;strong&gt;1 second&lt;/strong&gt; of overhead before any data is transferred. Resource hints eliminate most of this.&lt;/p&gt;</description></item><item><title>Optimizing Web Font Loading: Preventing FOUT and FOIT</title><link>https://takao.blog/en/web/performance-fonts-loading-optimization/</link><pubDate>Sun, 15 Mar 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/performance-fonts-loading-optimization/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Optimizing Web Font Loading: Preventing FOUT and FOIT" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;Web fonts enhance design but come at a cost. While a custom font loads, browsers must decide: show invisible text (&lt;strong&gt;FOIT&lt;/strong&gt; — Flash of Invisible Text) or show a fallback font (&lt;strong&gt;FOUT&lt;/strong&gt; — Flash of Unstyled Text). Either choice impacts &lt;strong&gt;CLS (Cumulative Layout Shift)&lt;/strong&gt; and user experience. This article covers strategies to load fonts reliably while minimizing layout shifts.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="the-font-display-descriptor"&gt;The font-display Descriptor
&lt;/h2&gt;&lt;p&gt;The &lt;code&gt;font-display&lt;/code&gt; property in &lt;code&gt;@font-face&lt;/code&gt; controls how a font is displayed during loading:&lt;/p&gt;</description></item><item><title>React Compiler: Say Goodbye to Manual Memoization</title><link>https://takao.blog/en/web/react-compiler-automated-memoization/</link><pubDate>Sat, 10 Jan 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/react-compiler-automated-memoization/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post React Compiler: Say Goodbye to Manual Memoization" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;For years, React developers have manually optimized re-renders with &lt;code&gt;useMemo&lt;/code&gt;, &lt;code&gt;useCallback&lt;/code&gt;, &lt;code&gt;React.memo&lt;/code&gt;, and various state-management heuristics. The &lt;strong&gt;React Compiler&lt;/strong&gt; (formerly known as React Forget) changes this paradigm entirely. It is a build-time tool that automatically memoizes React components, hooks, and values by analyzing reactive dependencies at compile time, eliminating the need for manual optimization hooks.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="the-problem-with-manual-memoization"&gt;The Problem with Manual Memoization
&lt;/h2&gt;&lt;p&gt;Consider a typical filtered list component:&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" style="color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"&gt;&lt;code class="language-jsx" data-lang="jsx"&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#66d9ef"&gt;function&lt;/span&gt; &lt;span style="color:#a6e22e"&gt;UserList&lt;/span&gt;({ &lt;span style="color:#a6e22e"&gt;users&lt;/span&gt;, &lt;span style="color:#a6e22e"&gt;filter&lt;/span&gt; }) {
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#66d9ef"&gt;const&lt;/span&gt; &lt;span style="color:#a6e22e"&gt;filtered&lt;/span&gt; &lt;span style="color:#f92672"&gt;=&lt;/span&gt; &lt;span style="color:#a6e22e"&gt;useMemo&lt;/span&gt;(
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; () =&amp;gt; &lt;span style="color:#a6e22e"&gt;users&lt;/span&gt;.&lt;span style="color:#a6e22e"&gt;filter&lt;/span&gt;(&lt;span style="color:#a6e22e"&gt;u&lt;/span&gt; =&amp;gt; &lt;span style="color:#a6e22e"&gt;u&lt;/span&gt;.&lt;span style="color:#a6e22e"&gt;name&lt;/span&gt;.&lt;span style="color:#a6e22e"&gt;includes&lt;/span&gt;(&lt;span style="color:#a6e22e"&gt;filter&lt;/span&gt;)),
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; [&lt;span style="color:#a6e22e"&gt;users&lt;/span&gt;, &lt;span style="color:#a6e22e"&gt;filter&lt;/span&gt;]
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; );
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#66d9ef"&gt;const&lt;/span&gt; &lt;span style="color:#a6e22e"&gt;handleClick&lt;/span&gt; &lt;span style="color:#f92672"&gt;=&lt;/span&gt; &lt;span style="color:#a6e22e"&gt;useCallback&lt;/span&gt;((&lt;span style="color:#a6e22e"&gt;id&lt;/span&gt;) =&amp;gt; {
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#a6e22e"&gt;console&lt;/span&gt;.&lt;span style="color:#a6e22e"&gt;log&lt;/span&gt;(&lt;span style="color:#e6db74"&gt;&amp;#39;Clicked:&amp;#39;&lt;/span&gt;, &lt;span style="color:#a6e22e"&gt;id&lt;/span&gt;);
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; }, []);
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &lt;span style="color:#66d9ef"&gt;return&lt;/span&gt; (
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &amp;lt;&lt;span style="color:#f92672"&gt;ul&lt;/span&gt;&amp;gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; {&lt;span style="color:#a6e22e"&gt;filtered&lt;/span&gt;.&lt;span style="color:#a6e22e"&gt;map&lt;/span&gt;(&lt;span style="color:#a6e22e"&gt;user&lt;/span&gt; =&amp;gt; (
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &amp;lt;&lt;span style="color:#f92672"&gt;UserRow&lt;/span&gt; &lt;span style="color:#a6e22e"&gt;key&lt;/span&gt;&lt;span style="color:#f92672"&gt;=&lt;/span&gt;{&lt;span style="color:#a6e22e"&gt;user&lt;/span&gt;.&lt;span style="color:#a6e22e"&gt;id&lt;/span&gt;} &lt;span style="color:#a6e22e"&gt;user&lt;/span&gt;&lt;span style="color:#f92672"&gt;=&lt;/span&gt;{&lt;span style="color:#a6e22e"&gt;user&lt;/span&gt;} &lt;span style="color:#a6e22e"&gt;onClick&lt;/span&gt;&lt;span style="color:#f92672"&gt;=&lt;/span&gt;{&lt;span style="color:#a6e22e"&gt;handleClick&lt;/span&gt;} /&amp;gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; ))}
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &amp;lt;/&lt;span style="color:#f92672"&gt;ul&lt;/span&gt;&amp;gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; );
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;}
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#66d9ef"&gt;const&lt;/span&gt; &lt;span style="color:#a6e22e"&gt;UserRow&lt;/span&gt; &lt;span style="color:#f92672"&gt;=&lt;/span&gt; &lt;span style="color:#a6e22e"&gt;React&lt;/span&gt;.&lt;span style="color:#a6e22e"&gt;memo&lt;/span&gt;(({ &lt;span style="color:#a6e22e"&gt;user&lt;/span&gt;, &lt;span style="color:#a6e22e"&gt;onClick&lt;/span&gt; }) =&amp;gt; (
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt; &amp;lt;&lt;span style="color:#f92672"&gt;li&lt;/span&gt; &lt;span style="color:#a6e22e"&gt;onClick&lt;/span&gt;&lt;span style="color:#f92672"&gt;=&lt;/span&gt;{() =&amp;gt; &lt;span style="color:#a6e22e"&gt;onClick&lt;/span&gt;(&lt;span style="color:#a6e22e"&gt;user&lt;/span&gt;.&lt;span style="color:#a6e22e"&gt;id&lt;/span&gt;)}&amp;gt;{&lt;span style="color:#a6e22e"&gt;user&lt;/span&gt;.&lt;span style="color:#a6e22e"&gt;name&lt;/span&gt;}&amp;lt;/&lt;span style="color:#f92672"&gt;li&lt;/span&gt;&amp;gt;
&lt;/span&gt;&lt;/span&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;));
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;This works, but it is verbose, error-prone (missing or incorrect dependency arrays), and easy to forget. A missing &lt;code&gt;useMemo&lt;/code&gt; on a large list causes unnecessary re-renders; an incorrect dependency array causes stale closures.&lt;/p&gt;</description></item><item><title>Optimizing Browser Rendering Pipelines (Critical Path)</title><link>https://takao.blog/en/web/performance-critical-rendering-path-optimizations/</link><pubDate>Sat, 20 Dec 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/performance-critical-rendering-path-optimizations/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Optimizing Browser Rendering Pipelines (Critical Path)" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;The &lt;strong&gt;Critical Rendering Path (CRP)&lt;/strong&gt; is the sequence of steps the browser performs to convert HTML, CSS, and JavaScript into visible pixels on the screen. Optimizing this pipeline directly impacts &lt;strong&gt;First Contentful Paint (FCP)&lt;/strong&gt; and &lt;strong&gt;Largest Contentful Paint (LCP)&lt;/strong&gt;. This article breaks down each CRP stage — DOM construction, CSSOM construction, render tree, layout, paint, and composite — and provides actionable optimization strategies.&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id="stage-1-dom-construction"&gt;Stage 1: DOM Construction
&lt;/h2&gt;&lt;p&gt;When the browser receives HTML bytes, it:&lt;/p&gt;</description></item><item><title>Preventing Cumulative Layout Shift with CSS aspect-ratio</title><link>https://takao.blog/en/web/css-aspect-ratio-cumulative-layout-shift/</link><pubDate>Wed, 10 Dec 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/css-aspect-ratio-cumulative-layout-shift/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Preventing Cumulative Layout Shift with CSS aspect-ratio" /&gt;&lt;h2 id="understanding-cumulative-layout-shift"&gt;Understanding Cumulative Layout Shift
&lt;/h2&gt;&lt;p&gt;Cumulative Layout Shift (CLS) is one of Google&amp;rsquo;s &lt;strong&gt;Core Web Vitals&lt;/strong&gt; metrics that measures visual stability. It quantifies how often users experience unexpected layout shifts. A high CLS score harms user experience and SEO rankings. The primary cause? Media elements (images, videos, iframes) loading without reserved space.&lt;/p&gt;
&lt;h2 id="how-css-aspect-ratio-works"&gt;How CSS aspect-ratio Works
&lt;/h2&gt;&lt;p&gt;The &lt;code&gt;aspect-ratio&lt;/code&gt; CSS property lets you declare the ratio of width to height for any element. The browser reserves space accordingly, preventing the layout from jumping when content loads.&lt;/p&gt;</description></item><item><title>Maximizing Docker Build Cache for Faster Deployment Pipelines</title><link>https://takao.blog/en/web/docker-build-caches-speedup/</link><pubDate>Sat, 20 Sep 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/docker-build-caches-speedup/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Maximizing Docker Build Cache for Faster Deployment Pipelines" /&gt;&lt;p&gt;Whether you are trying to speed up local iterative container runs or aiming to shave minutes off your CI/CD pipelines, optimizing your &lt;strong&gt;Docker image build speeds&lt;/strong&gt; is a crucial aspect of engineering productivity. Long build wait times disrupt developer focus and drive up cloud computing costs.&lt;/p&gt;
&lt;p&gt;One of the most powerful and easiest ways to optimize build speeds is by configuring Docker files to maximize the use of the &lt;strong&gt;Docker Build Cache&lt;/strong&gt;.&lt;/p&gt;</description></item><item><title>Executing Non-Blocking Scripts with requestIdleCallback</title><link>https://takao.blog/en/web/web-performance-requestidlecallback-optimizations/</link><pubDate>Fri, 25 Jul 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/web-performance-requestidlecallback-optimizations/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Executing Non-Blocking Scripts with requestIdleCallback" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;When building complex web applications, maintaining smooth animations and responsive user inputs (ideally matching 60+ FPS frame rates) is essential for a good user experience.&lt;/p&gt;
&lt;p&gt;However, modern applications often require executing low-priority background operations—such as sending analytics data, syncing caches, parsing telemetry logs, or pre-fetching assets.&lt;/p&gt;
&lt;p&gt;Executing these non-urgent tasks as standard async promises or immediate timers can block the main thread mid-frame, causing interface jank or increasing your Interaction to Next Paint (INP) score.&lt;/p&gt;</description></item><item><title>Boosting Initial Page Speeds with Lazy-Loaded Frames and Images</title><link>https://takao.blog/en/web/web-performance-lazyloading-iframe/</link><pubDate>Sun, 20 Jul 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/web-performance-lazyloading-iframe/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Boosting Initial Page Speeds with Lazy-Loaded Frames and Images" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;An effective but frequently overlooked strategy for optimizing web page speeds is &lt;strong&gt;deferring off-screen asset loading&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;By default, when a user loads a web page, the browser immediately requests all images and &lt;code&gt;&amp;lt;iframe&amp;gt;&lt;/code&gt; elements (like YouTube embeds, interactive maps, social widgets, or advertising scripts) on the page, even if they are located far below the fold. This concurrent downloading blocks the main thread and slows down your page&amp;rsquo;s First Contentful Paint (FCP) time.&lt;/p&gt;</description></item><item><title>Optimizing Images: WebP vs. AVIF and Responsive Sizes</title><link>https://takao.blog/en/web/web-performance-image-optimizations/</link><pubDate>Tue, 15 Jul 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/web-performance-image-optimizations/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Optimizing Images: WebP vs. AVIF and Responsive Sizes" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;Optimizing image assets is one of the most effective ways to improve web performance metrics like Lighthouse scores and LCP (Largest Contentful Paint).&lt;/p&gt;
&lt;p&gt;In many web applications, images make up more than half of the total payload size. Slow image loading times directly degrade user experience.&lt;/p&gt;
&lt;p&gt;Replacing legacy formats like JPEG and PNG with next-generation formats like &lt;strong&gt;WebP&lt;/strong&gt; and &lt;strong&gt;AVIF&lt;/strong&gt; has become standard practice in modern web development. This article compares these two formats and explains how to configure responsive, optimized image delivery.&lt;/p&gt;</description></item><item><title>Stop Overusing useMemo and useCallback in React</title><link>https://takao.blog/en/web/react-hooks-usememo-usecallback/</link><pubDate>Fri, 20 Jun 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/react-hooks-usememo-usecallback/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Stop Overusing useMemo and useCallback in React" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;When optimizing React application performance, developers often reach for &lt;strong&gt;&lt;code&gt;useMemo&lt;/code&gt;&lt;/strong&gt; and &lt;strong&gt;&lt;code&gt;useCallback&lt;/code&gt;&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;It is tempting to wrap every object and function in these hooks, assuming that caching outputs will automatically speed up the application. However, this is a common misconception.&lt;/p&gt;
&lt;p&gt;Unnecessary memoization does not just make code harder to read; it adds &lt;strong&gt;performance overhead from shallow dependency comparisons and garbage collection memory allocations&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;This article outlines the specific scenarios where these hooks are beneficial and when they should be avoided.&lt;/p&gt;</description></item><item><title>Intro to DB Indexing: Resolving Query Latencies</title><link>https://takao.blog/en/web/backend-database-indexing-basics/</link><pubDate>Sun, 25 May 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/backend-database-indexing-basics/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Intro to DB Indexing: Resolving Query Latencies" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;As web applications scale and data volumes grow, backend systems often face database bottleneck issues like query latencies.&lt;/p&gt;
&lt;p&gt;Running join (&lt;code&gt;JOIN&lt;/code&gt;) operations or complex search queries on tables with hundreds of thousands of records without proper index optimizations can cause database CPU spikes, leading to slow response times for end users.&lt;/p&gt;
&lt;p&gt;Designing database indices is a powerful way to address these performance bottlenecks. This article explains how database indices work, details B-Tree structures, and shares guidelines for designing effective indices.&lt;/p&gt;</description></item><item><title>Approaches to Improving Interaction to Next Paint (INP)</title><link>https://takao.blog/en/web/performance-web-vitals-inp/</link><pubDate>Sat, 15 Mar 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/performance-web-vitals-inp/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Approaches to Improving Interaction to Next Paint (INP)" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;In Google&amp;rsquo;s &lt;strong&gt;Core Web Vitals&lt;/strong&gt; metrics, which measure the user experience of web pages, FID (First Input Delay) has officially been replaced by &lt;strong&gt;INP (Interaction to Next Paint)&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;While FID only measured the response speed of the very first user interaction, INP evaluates the responsiveness of all clicks, taps, and keyboard inputs across the entire lifecycle of the page visit. It logs the delay between an interaction and the subsequent visual update (the &amp;ldquo;Next Paint&amp;rdquo;).&lt;/p&gt;</description></item><item><title>CDN Caching Strategies: Maximize Performance and Freshness</title><link>https://takao.blog/en/web/cdn-caching-strategies/</link><pubDate>Mon, 30 Dec 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/cdn-caching-strategies/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post CDN Caching Strategies: Maximize Performance and Freshness" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;Content Delivery Networks (CDNs) are the backbone of modern web performance. By caching content at edge nodes distributed globally, CDNs dramatically reduce latency and offload traffic from origin servers. However, effective caching is not simply a matter of enabling a CDN and forgetting about it. Striking the right balance between performance — high cache hit rates and low latency — and freshness — minimal staleness and fast invalidation — requires deliberate strategy.&lt;/p&gt;</description></item><item><title>Mobile Web Performance Optimization: 2024 Techniques</title><link>https://takao.blog/en/web/mobile-performance/</link><pubDate>Thu, 26 Dec 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/mobile-performance/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Mobile Web Performance Optimization: 2024 Techniques" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;Mobile web performance is no longer a secondary concern. With mobile traffic accounting for over 60% of global web traffic and growing rapidly in emerging markets, the performance characteristics of your site on mobile devices directly impact user retention, conversion, and search rankings. Users expect fast, fluid experiences — 53% abandon sites that take longer than 3 seconds to load. This article covers the key techniques for optimizing mobile web performance in 2024, from network-aware loading to touch event optimization and Core Web Vitals.&lt;/p&gt;</description></item><item><title>Node.js Performance Monitoring: Metrics That Matter</title><link>https://takao.blog/en/web/nodejs-performance/</link><pubDate>Wed, 18 Dec 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/nodejs-performance/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Node.js Performance Monitoring: Metrics That Matter" /&gt;&lt;p&gt;Node.js performance monitoring requires a different approach than traditional server environments. The single-threaded event loop, garbage-collected memory model, and asynchronous I/O create unique failure modes that generic CPU and memory metrics alone cannot capture. This article covers the essential metrics and tools you need to keep Node.js applications running smoothly in production.&lt;/p&gt;
&lt;h2 id="why-nodejs-performance-monitoring-is-different"&gt;Why Node.js Performance Monitoring Is Different
&lt;/h2&gt;&lt;p&gt;Unlike multi-threaded servers where a slow operation blocks only one thread, a single CPU-heavy operation in Node.js blocks the entire event loop, stalling all concurrent requests. Garbage collection pauses can introduce unpredictable latency spikes. Common failure modes include event loop starvation, memory leaks from uncleaned closures, callback thrashing, and unhandled promise rejections silently swallowing errors. Understanding these characteristics is the first step toward effective monitoring.&lt;/p&gt;</description></item><item><title>React Concurrent Features: Building Responsive UIs</title><link>https://takao.blog/en/web/react-concurrent/</link><pubDate>Fri, 06 Dec 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/react-concurrent/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post React Concurrent Features: Building Responsive UIs" /&gt;&lt;p&gt;React 18 introduced concurrent features that fundamentally change how rendering works. These features let React prepare multiple versions of the UI at once, interrupt work in progress, and prioritize urgent updates over non-urgent ones. The result is more responsive applications without giving up the declarative programming model that makes React productive.&lt;/p&gt;
&lt;p&gt;Concurrency in React is not an all-or-nothing mode. Unlike the abandoned &amp;ldquo;Concurrent Mode&amp;rdquo; concept from earlier experimental builds, React 18+ makes concurrent features opt-in. You adopt them feature by feature, where they provide the most value. The underlying Fiber architecture makes this possible: React&amp;rsquo;s render phase can be paused and resumed, so the reconciler can switch between different units of work as priorities change.&lt;/p&gt;</description></item><item><title>WebAssembly for Browser Applications: Beyond the Hype</title><link>https://takao.blog/en/web/wasm-browser-apps/</link><pubDate>Sat, 30 Nov 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/wasm-browser-apps/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post WebAssembly for Browser Applications: Beyond the Hype" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;WebAssembly has matured from a niche curiosity into a production-ready tool for browser-based applications. While early demos focused on gaming engines and scientific simulations, today Wasm is used in image editors, video transcoders, compression libraries, and cryptographic utilities — all running in the browser at near-native speed.&lt;/p&gt;
&lt;p&gt;The key shift in 2024 is ecosystem maturity. WasmGC ships in Chrome 119+, SIMD is available across all major browsers, and reference types allow passing DOM nodes directly into Wasm modules. This article cuts through the hype to examine realistic use cases, compile-target decisions, memory management strategies, and integration patterns for production applications.&lt;/p&gt;</description></item><item><title>Third-Party Script Optimization: Taming Page Bloat</title><link>https://takao.blog/en/web/third-party-scripts/</link><pubDate>Tue, 19 Nov 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/third-party-scripts/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Third-Party Script Optimization: Taming Page Bloat" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;Third-party scripts are the hidden tax of modern web development. The average page loads 15–25 third-party requests, accounting for 60–80% of total page weight. Data from the HTTP Archive confirms that third-party JavaScript is growing faster than first-party code. Each external script adds network latency, parse and compile time, main-thread contention, and potential security risks. The good news: you can optimize third-party scripts without removing their functionality. The goal is to minimize performance impact while preserving business value.&lt;/p&gt;</description></item><item><title>JavaScript Bundle Size Optimization: From Analysis to Action</title><link>https://takao.blog/en/web/bundle-size-optimization/</link><pubDate>Tue, 22 Oct 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/bundle-size-optimization/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post JavaScript Bundle Size Optimization: From Analysis to Action" /&gt;&lt;p&gt;JavaScript bundle size directly impacts user experience. Larger bundles mean longer download times, slower parsing and compilation, and worse Core Web Vitals. A 100KB increase in JavaScript reduces conversion rates by 2 to 3 percent. Bundle optimization is an ongoing investment, not a one-time fix, and follows a cycle of analysis, identification, optimization, and monitoring.&lt;/p&gt;
&lt;h2 id="bundle-analysis-tools"&gt;Bundle Analysis Tools
&lt;/h2&gt;&lt;p&gt;Understanding what is in your bundle is the first step. webpack-bundle-analyzer provides an interactive treemap visualization that highlights large dependencies and duplicate modules. Vite users can leverage rollup-plugin-visualizer with sunburst and network graphs, while esbuild offers the &amp;ndash;metafile flag for detailed output analysis. source-map-explorer maps compiled code back to source files.&lt;/p&gt;</description></item><item><title>Image Optimization Strategies 2024: AVIF, WebP, and Beyond</title><link>https://takao.blog/en/web/image-optimization-2024/</link><pubDate>Tue, 02 Jul 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/image-optimization-2024/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Image Optimization Strategies 2024: AVIF, WebP, and Beyond" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;Images account for over half of the typical webpage&amp;rsquo;s total weight. As web applications grow more visual, optimizing image delivery has become critical for performance, user experience, and Core Web Vitals scores. This article explores modern image optimization strategies, from next-generation formats to responsive delivery techniques.&lt;/p&gt;
&lt;h2 id="image-formats-in-2024"&gt;Image Formats in 2024
&lt;/h2&gt;&lt;p&gt;The image format landscape has shifted dramatically. Three modern formats now compete for dominance alongside legacy JPEG and PNG.&lt;/p&gt;</description></item><item><title>Node.js Worker Threads: Parallel Processing in Practice</title><link>https://takao.blog/en/web/nodejs-worker-threads/</link><pubDate>Tue, 23 Apr 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/nodejs-worker-threads/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Node.js Worker Threads: Parallel Processing in Practice" /&gt;&lt;p&gt;Node.js has traditionally been single-threaded, relying on asynchronous I/O for concurrency. While this model excels at I/O-bound workloads, CPU-intensive operations block the event loop and degrade application responsiveness. Worker Threads, stabilized in Node.js 12, provide true parallel execution within a single process by running JavaScript in separate V8 isolates. This article covers practical patterns for using worker threads in production.&lt;/p&gt;
&lt;h2 id="worker-lifecycle-and-communication"&gt;Worker Lifecycle and Communication
&lt;/h2&gt;&lt;p&gt;Creating a worker requires a separate JavaScript file that executes in its own V8 isolate with its own heap and event loop.&lt;/p&gt;</description></item><item><title>Next.js Image Optimization: From Setup to Advanced Patterns</title><link>https://takao.blog/en/web/nextjs-image-optimization/</link><pubDate>Tue, 26 Mar 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/nextjs-image-optimization/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Next.js Image Optimization: From Setup to Advanced Patterns" /&gt;&lt;h2 id="introduction"&gt;Introduction
&lt;/h2&gt;&lt;p&gt;Images account for over 50% of total webpage bytes on average, making optimization essential for performance. Next.js provides a comprehensive image optimization pipeline through the &lt;code&gt;next/image&lt;/code&gt; component and its built-in Image Optimization API. This article covers setup, configuration, and advanced patterns with a focus on Core Web Vitals impact.&lt;/p&gt;
&lt;h2 id="the-nextimage-component"&gt;The next/image Component
&lt;/h2&gt;&lt;p&gt;The &lt;code&gt;next/image&lt;/code&gt; component extends the HTML &lt;code&gt;&amp;lt;img&amp;gt;&lt;/code&gt; element with automatic optimization features: lazy loading, responsive srcset generation, width and height enforcement to prevent Cumulative Layout Shift, blur-up placeholders, and automatic format negotiation.&lt;/p&gt;</description></item><item><title>Core Web Vitals Optimization: Complete 2024 Guide</title><link>https://takao.blog/en/web/core-web-vitals/</link><pubDate>Mon, 15 Jan 2024 00:00:00 +0900</pubDate><guid>https://takao.blog/en/web/core-web-vitals/</guid><description>&lt;img src="https://takao.blog/img/thumnail.webp" alt="Featured image of post Core Web Vitals Optimization: Complete 2024 Guide" /&gt;&lt;p&gt;Core Web Vitals (CWV) are the set of user-centric performance metrics that Google uses to measure real-world experience on the web. In March 2024, Google replaced First Input Delay (FID) with Interaction to Next Paint (INP), making it critical to understand all three metrics: Largest Contentful Paint (LCP), INP, and Cumulative Layout Shift (CLS). This guide covers every aspect of optimizing your site for good CWV scores.&lt;/p&gt;
&lt;h2 id="understanding-core-web-vitals-in-2024"&gt;Understanding Core Web Vitals in 2024
&lt;/h2&gt;&lt;p&gt;The three CWV metrics measure distinct aspects of user experience. LCP tracks loading performance — how quickly the main content appears. INP measures interactivity — how responsive the page feels when users click, tap, or type. CLS quantifies visual stability — how much the layout shifts unexpectedly during load.&lt;/p&gt;</description></item></channel></rss>