<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Browser on Commentary of Takao</title><link>https://takao.blog/ko/tags/browser/</link><description>Recent content in Browser on Commentary of Takao</description><generator>Hugo -- gohugo.io</generator><language>ko</language><copyright>Commentary of Takao</copyright><lastBuildDate>Sun, 12 Jul 2026 04:12:51 +0900</lastBuildDate><atom:link href="https://takao.blog/ko/tags/browser/index.xml" rel="self" type="application/rss+xml"/><item><title>Transitioning from WebGL to WebGPU for Faster Graphics</title><link>https://takao.blog/ko/web/webgpu-native-browser-graphics-generation/</link><pubDate>Sun, 05 Apr 2026 00:00:00 +0900</pubDate><guid>https://takao.blog/ko/web/webgpu-native-browser-graphics-generation/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/webgpu-native-browser-graphics-generation-ko.png" alt="Featured image of post Transitioning from WebGL to WebGPU for Faster Graphics" /&gt;&lt;h2 id="transitioning-from-webgl-to-webgpu-for-faster-그래픽"&gt;Transitioning from WebGL to WebGPU for Faster 그래픽
&lt;/h2&gt;&lt;p&gt;For over a decade, &lt;strong&gt;WebGL&lt;/strong&gt; has been the sole standard for hardware-accelerated 3D 그래픽 in the browser. Built on OpenGL ES, it exposed a state-machine API that worked well for its era but imposed significant CPU overhead and lacked direct access to modern GPU 기능. Enter &lt;strong&gt;WebGPU&lt;/strong&gt; — a next-generation 그래픽 and compute API designed from the ground up for modern GPU architectures.&lt;/p&gt;</description></item><item><title>Optimizing Browser Rendering Pipelines (Critical Path)</title><link>https://takao.blog/ko/web/performance-critical-rendering-path-optimizations/</link><pubDate>Sat, 20 Dec 2025 00:00:00 +0900</pubDate><guid>https://takao.blog/ko/web/performance-critical-rendering-path-optimizations/</guid><description>&lt;img src="https://takao.blog/img/thumbnail/performance-critical-rendering-path-optimizations-ko.png" 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 화면. 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 최적화 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></channel></rss>