initial commit

3 files changed, 555 insertions, 0 deletions

diff --git a/files/ko/web/performance/index.html b/files/ko/web/performance/index.html
new file mode 100644
index 0000000000..2bca12d91b
--- /dev/null
+++ b/files/ko/web/performance/index.html
@@ -0,0 +1,291 @@
+---
+title: Web Performance
+slug: Web/Performance
+tags:
+  - API
+  - App
+  - App Performance
+  - HTML
+  - JavaScript
+  - Landing
+  - Mobile
+  - Mobile Performance
+  - NeedsTranslation
+  - Performance
+  - Performance Budget
+  - Start-Up Performance
+  - TopicStub
+  - Web
+  - Web Performance
+translation_of: Web/Performance
+---
+<p><span class="seoSummary">Web performance is the objective measurements and the perceived user experience of load time and runtime. Web performance is how long a site takes to load, become interactive and responsive, and how smooth the content is during user interactions </span>- is the scrolling smooth? are buttons clickable? Are pop-ups quick to load and display, and do they animate smoothly as they do so? Web performance includes both objective measurements like time to load, frames per second, and time to become interactive, and subjective experiences of how long it felt like it took the content to load.</p>
+
+<p>The longer it takes for a site to respond, the more users will abandon the site. It is important to minimize the loading and response times and add additional features to conceal latency by making the experience as available and interactive as possible, as soon as possible, while asynchronously loading in the longer tail parts of the experience.</p>
+
+<p>There are tools, APIs, and best practices that help us measure and improve web performance. We cover them in this section:</p>
+
+<h2 id="Key_performance_guides">Key performance guides</h2>
+
+<p>{{LandingPageListSubpages}}</p>
+
+<div class="cleared topicpage-table">
+<div class="section">
+<h2 id="Beginners_tutorials">Beginner's tutorials</h2>
+
+<p>The MDN <a href="/en-US/docs/Learn/Performance">Web Performance Learning Area</a> contains modern, up-to-date tutorials covering Performance essentials. Start here if you are a newcomer to performance:</p>
+
+<dl>
+ <dt></dt>
+ <dt><a href="/en-US/docs/Learn/Performance/web_performance_overview">Web performance: brief overview</a></dt>
+ <dd>Overview of the web performance learning path. Start your journey here.</dd>
+ <dt><a href="/en-US/docs/Learn/Performance/What_is_web_performance">What is web performance?</a></dt>
+ <dd>This article starts the module off with a good look at what performance actually is — this includes the tools, metrics, APIs, networks, and groups of people we need to consider when thinking about performance, and how we can make performance part of our web development workflow.</dd>
+ <dt><a href="/en-US/docs/Learn/Performance/Perceived_performance">How do users perceive performance?</a></dt>
+ <dd>
+ <p>More important than how fast your website is in milliseconds, is how fast your users perceive your site to be. These perceptions are impacted by actual p<span style="letter-spacing: -0.00278rem;">age load time, idling, responsiveness to user interaction, and the smoothness of scrolling and other animations. In this article, we discuss the various loading metrics, animation, and responsiveness metrics, along with best practices to improve user perception, if not the actual timings.</span></p>
+ </dd>
+ <dt><a href="/en-US/docs/Learn/Performance/Web_Performance_Basics">Web performance basics</a></dt>
+ <dd>In addition to the front end components of HTML, CSS, JavaScript, and media files, there are features that can make applications slower and features that can make applications subjectively and objectively faster. There are many APIs, developer tools, best practices, and bad practices relating to web performance. Here we'll introduce many of these features ad the basic level and provide links to deeper dives to improve performance for each topic.</dd>
+ <dt><a href="/en-US/docs/Learn/Performance/HTML">HTML performance features</a></dt>
+ <dd>Some attributes and the source order of your mark-up can impact the performance or your website. By minimizing the number of DOM nodes, making sure the best order and attributes are used for including content such as styles, scripts, media, and third-party scripts, you can drastically improve the user experience. This article looks in detail at how HTML can be used to ensure maximum performance.</dd>
+ <dt><a href="/en-US/docs/Learn/Performance/Multimedia">Multimedia: images and video</a></dt>
+ <dd>The lowest hanging fruit of web performance is often media optimization. Serving different media files based on each user agent's capability, size, and pixel density is possible. Additional tips like removing audio tracks from background videos can improve performance even further. In this article we discuss the impact video, audio, and image content has on performance, and the methods to ensure that impact is as minimal as possible.</dd>
+ <dt><a href="/en-US/docs/Learn/Performance/CSS">CSS performance features</a></dt>
+ <dd>CSS may be a less important optimization focus for improved performance, but there are some CSS features that impact performance more than others. In this article we look at some CSS properties that impact performance and suggested ways of handling styles to ensure performance is not negatively impacted.</dd>
+ <dt><a href="/en-US/docs/Learn/Performance/JavaScript">JavaScript performance best practices</a></dt>
+ <dd>JavaScript, when used properly, can allow for interactive and immersive web experiences — or it can significantly harm download time, render time, in-app performance, battery life, and user experience. This article outlines some JavaScript best practices that should be considered to ensure even complex content is as performant as possible.</dd>
+ <dt><a href="/en-US/docs/Learn/Performance/Mobile">Mobile performance</a></dt>
+ <dd>With web access on mobile devices being so popular, and all mobile platforms having fully-fledged web browsers, but possibly limited bandwidth, CPU and battery life, it is important to consider the performance of your web content on these platforms. This article looks at mobile-specific performance considerations.</dd>
+</dl>
+
+<dl>
+</dl>
+</div>
+
+<div class="section">
+<h2 class="Other_documentation" id="Other_documentation" name="Other_documentation">Using Performance APIs</h2>
+
+<dl>
+ <dt><a href="/en-US/docs/Web/API/Performance_API/Using_the_Performance_API">Performance API</a></dt>
+ <dd>This guide describes how to use the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Performance" title="The Performance interface provides access to performance-related information for the current page. It's part of the High Resolution Time API, but is enhanced by the Performance Timeline API, the Navigation Timing API, the User Timing API, and the Resource Timing API."><code>Performance</code></a> interfaces that are defined in the <a class="external external-icon" href="https://w3c.github.io/hr-time/" rel="noopener">High-Resolution Time</a> standard.</dd>
+ <dt><a href="/en-US/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API">Resource Timing API</a></dt>
+ <dd><a href="/en-US/docs/Web/API/Resource_Timing_API">Resource loading and timing</a> the loading of those resources, including managing the resource buffer and coping with CORS</dd>
+ <dt><a href="/en-US/docs/Web/API/Performance_Timeline/Using_Performance_Timeline">The performance timeline</a></dt>
+ <dd>The <a href="/en-US/docs/Web/API/Performance_Timeline">Performance Timeline</a> standard defines extensions to the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Performance" title="The Performance interface provides access to performance-related information for the current page. It's part of the High Resolution Time API, but is enhanced by the Performance Timeline API, the Navigation Timing API, the User Timing API, and the Resource Timing API."><code>Performance</code></a> interface to support client-side latency measurements within applications. Together, these interfaces can be used to help identify an application's performance bottlenecks.</dd>
+ <dt><a href="/en-US/docs/Web/API/User_Timing_API/Using_the_User_Timing_API">User Timing API</a></dt>
+ <dd>Create application specific timestamps using the <a href="/en-US/docs/Web/API/User_Timing_API">user timing API</a>'s "mark" and "measure" entry types - that are part of the browser's performance timeline.</dd>
+ <dt><a href="/en-US/docs/Web/API/Frame_Timing_API/Using_the_Frame_Timing_API">Frame Timing API</a></dt>
+ <dd>The <code><a href="/en-US/docs/Web/API/PerformanceFrameTiming">PerformanceFrameTiming</a></code> interface provides <em>frame</em> timing data about the browser's event loop.</dd>
+ <dt><a href="/en-US/docs/Web/API/Beacon_API/Using_the_Beacon_API">Beacon API</a></dt>
+ <dd><small>The <a href="/en-US/docs/Web/API/Beacon_API">Beacon</a> interface schedules an asynchronous and non-blocking request to a web server.</small></dd>
+ <dt><a href="/en-US/docs/Web/API/Intersection_Observer_API/Timing_element_visibility">Intersection Observer API</a></dt>
+ <dd>Learn to time element visibility with the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API">Intersection Observer API</a> and be asynchronously notified when elements of interest becomes visible.</dd>
+</dl>
+
+<h2 class="Other_documentation" id="Other_documentation" name="Other_documentation">Other documentation</h2>
+
+<dl>
+ <dt><a href="/en-US/docs/Tools/Performance">Developer Tools Performance Features</a></dt>
+ <dd>This section provides information on how to use and understand the performance features in your developer tools, including <a href="/en-US/docs/Tools/Performance/Waterfall">Waterfall</a>, <a href="/en-US/docs/Tools/Performance/Call_Tree">Call Tree</a>, and <a href="/en-US/docs/Tools/Performance/Flame_Chart">Flame Charts</a>.</dd>
+ <dt><a href="/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler">Profiling with the built-in profiler</a></dt>
+ <dd>Learn how to profile app performance with Firefox's built-in profiler.</dd>
+</dl>
+</div>
+</div>
+
+<h2 id="Glossary_Terms">Glossary Terms</h2>
+
+<div class="index">
+<ul class="index">
+ <li>{{glossary('Beacon')}}</li>
+ <li>{{glossary('Brotli compression')}}</li>
+ <li>{{glossary('Client hints')}}</li>
+ <li>{{glossary('Code splitting')}}</li>
+ <li>{{glossary('CSSOM')}}</li>
+ <li>{{glossary('Domain sharding')}}</li>
+ <li>{{glossary('Effective connection type')}}</li>
+ <li>{{glossary('First contentful paint')}}</li>
+ <li>{{glossary('First CPU idle')}}</li>
+ <li>{{glossary('First input delay')}}</li>
+ <li>{{glossary('First interactive')}}</li>
+ <li>{{glossary('First meaningful paint')}}</li>
+ <li>{{glossary('First paint')}}</li>
+ <li>{{glossary('HTTP')}}</li>
+ <li>{{glossary('HTTP_2', 'HTTP/2')}}</li>
+ <li>{{glossary('Jank')}}</li>
+ <li>{{glossary('Latency')}}</li>
+ <li>{{glossary('Lazy load')}}</li>
+ <li>{{glossary('Long task')}}</li>
+ <li>{{glossary('Lossless compression')}}</li>
+ <li>{{glossary('Lossy compression')}}</li>
+ <li>{{glossary('Main thread')}}</li>
+ <li>{{glossary('Minification')}}</li>
+ <li>{{glossary('Network throttling')}}</li>
+ <li>{{glossary('Packet')}}</li>
+ <li>{{glossary('Page load time')}}</li>
+ <li>{{glossary('Page prediction')}}</li>
+ <li>{{glossary('Parse')}}</li>
+ <li>{{glossary('Perceived performance')}}</li>
+ <li>{{glossary('Prefetch')}}</li>
+ <li>{{glossary('Prerender')}}</li>
+ <li>{{glossary('QUIC')}}</li>
+ <li>{{glossary('RAIL')}}</li>
+ <li>{{glossary('Real User Monitoring')}}</li>
+ <li>{{glossary('Resource Timing')}}</li>
+ <li>{{glossary('Round Trip Time (RTT)')}}</li>
+ <li>{{glossary('Server Timing')}}</li>
+ <li>{{glossary('Speculative parsing')}}</li>
+ <li>{{glossary('Speed index')}}</li>
+ <li>{{glossary('SSL')}}</li>
+ <li>{{glossary('Synthetic monitoring')}}</li>
+ <li>{{glossary('TCP handshake')}}</li>
+ <li>{{glossary('TCP slow start')}}</li>
+ <li>{{glossary('Time to first byte')}}</li>
+ <li>{{glossary('Time to interactive')}}</li>
+ <li>{{glossary('TLS')}}</li>
+ <li>{{glossary('TCP', 'Transmission Control Protocol (TCP)')}}</li>
+ <li>{{glossary('Tree shaking')}}</li>
+ <li>{{glossary('Web performance')}}</li>
+</ul>
+</div>
+
+<h2 id="Documents_yet_to_be_written">Documents yet to be written</h2>
+
+<dl>
+ <dt><a href="/en-US/docs/Learn/Performance/JavaScript">JavaScript performance best practices</a></dt>
+ <dd>JavaScript, when used properly, can allow for interactive and immersive web experiences ... or it can significantly harm download time, render time, in app performance, battery life, and user experience. <span class="veryhardreadability"><span><span>This article outlines some JavaScript best practices that can ensure even complex content's performance is the highest possible.</span></span></span></dd>
+ <dt><a href="/en-US/docs/Learn/Performance/Mobile">Mobile performance</a></dt>
+ <dd>With web access on mobile devices being so popular, and all mobile platforms having fully-fledged web browsers, but possibly limited bandwidth, CPU, and battery life, it is important to consider the performance of your web content on these platforms. This article also looks at mobile-specific performance considerations.</dd>
+ <dt>Web font performance</dt>
+ <dd>An often overlooked aspect of performance landscape are web fonts. Web fonts are more prominent in web design than ever, yet many developers simply embed them from a third party service and think nothing of it. In this article, we'll covers methods for getting your font files as small as possible with efficient file formats and sub setting. From there, we'll go on to talk about how browsers text, and how you can use CSS and JavaScript features to ensure your fonts render quickly, and with minimal disruption to the user experience.</dd>
+ <dt>Performance bottlenecks</dt>
+ <dd></dd>
+ <dt>Understanding bandwidth</dt>
+ <dd>
+ <div>
+ <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"><span><span>Bandwidth is the amount of data measured in Megabits(Mb) or Kilobits(Kb) that one can send per second. </span></span><span class="veryhardreadability"><span><span>This article explains the role of bandwidth in media-rich internet applications, how you can measure it, and how you can optimize applications to make the best use of available bandwidth</span></span></span><span><span>.</span></span></div>
+ </div>
+ </dd>
+ <dd></dd>
+ <dt>The role of TLS in performance</dt>
+ <dd>
+ <p>TLS—or HTTPS as we tend to call it—is crucial in creating secure and safe user experiences. While hardware has reduced the negative impacts TLS has had on server performance, it still represents a substantial slice of the time we spend waiting for browsers to connect to servers. This article explains the TLS handshake process, and offers some tips for reducing this time, such as OCSP stapling, HSTS preload headers, and the potential role of resource hints in masking TLS latency for third parties.</p>
+ </dd>
+ <dt>Reading performance charts</dt>
+ <dd>Developer tools provide information on performance, memory, and network requests. Knowing how to read <a href="https://developer.mozilla.org/en-US/docs/Tools/Performance/Waterfall">waterfall</a> charts, <a href="https://developer.mozilla.org/en-US/docs/Tools/Performance/Call_Tree">call trees</a>, traces, <a href="https://developer.mozilla.org/en-US/docs/Tools/Performance/Flame_Chart">flame charts</a> , and <a href="https://developer.mozilla.org/en-US/docs/Tools/Performance/Allocations">allocations</a> in your browser developer tools will help you understand waterfall and flame charts in other performance tools.</dd>
+ <dt>Alternative media formats</dt>
+ <dd>When it comes to images and videos, there are more formats than you're likely aware of. Some of these formats can take your highly optimized media-rich pages even further by offering additional reductions in file size. In this guide we'll discuss some alternative media formats, how to use them responsibly so that non-supporting browsers don't get left out in the cold, and some advanced guidance on transcoding your existing assets to them.</dd>
+ <dt>Analyzing JavaScript bundles</dt>
+ <dd>No doubt, JavaScript is a big part of modern web development. While you should always strive to reduce the amount of JavaScript you use in your applications, it can be difficult to know where to start. <span class="veryhardreadability"><span><span>In this guide, we'll show you how to analyze your application's script bundles, so you know </span></span><em><span>what</span></em><span><span> you're using, as well how to detect if your app contains duplicated scripts between bundles</span></span></span><span><span>.</span></span></dd>
+ <dt><a href="/en-US/docs/Web/Performance/Lazy_loading">Lazy loading</a></dt>
+ <dd>It isn't always necessary to load all of a web applications assets on initial page load. Lazy Loading is deferring the loading of assets on a page, such as scripts, images, etc., on a page to a later point in time i.e when those assets are actually needed.</dd>
+ <dt>Lazy-loading JavaScript with dynamic imports</dt>
+ <dd>When developers hear the term "lazy loading", they immediately think of below-the-fold imagery that loads when it scrolls into the viewport. But did you know you can lazy load JavaScript as well? In this guide we'll talk about the dynamic import() statement, which is a feature in modern browsers that loads a JavaScript module on demand. Of course, since this feature isn't available everywhere, we'll also show you how you can configure your tooling to use this feature in a widely compatible fashion.</dd>
+ <dt><a href="/en-US/docs/Web/Performance/Controlling_resource_delivery_with_resource_hints">Controlling resource delivery with resource hints</a></dt>
+ <dd>Browsers often know better than we do when it comes to resource prioritization and delivery however they're far from clairyovant. Native browser features enable us to hint to the browser when it should connect to another server, or preload a resource before the browser knows it ever needs it. When used judiciously, this can make fast experience seem even faster. In this article, we cover native browser features like rel=preconnect, rel=dns-prefetch, rel=prefetch, and rel=preload, and how to use them to your advantage.</dd>
+ <dt><a href="/en-US/docs/Web/Performance/Performance_budgets">Performance Budgets</a></dt>
+ <dd>Marketing, design, and sales needs, and developer experience, often ad bloat, third-party scripts, and other features that can slow down web performance. To help set priorities, it is helpful to set a performance budget: a set of restrictions to not exceed during the development phase. In this article, we'll discuss creating and sticking to a performance budget. </dd>
+ <dt><a href="/en-US/docs/Web/Performance/Checklist">Web performance checklist</a></dt>
+ <dd>A performance checklist of features to consider when developing applications with links to tutorials on how to implement each feature, include service workers, diagnosing performance problems, font loading best practices, client hints, creating performant animations, etc.</dd>
+ <dt><a href="/en-US/docs/Web/Performance/Mobile_performance_checklist">Mobile performance checklist</a></dt>
+ <dd>A concise checklist of performance considerations impacting mobile network users on hand-held, battery operated devices.</dd>
+</dl>
+
+<h2 id="See_also">See also</h2>
+
+<p>HTML</p>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTML/Element/picture">The <code>&lt;picture&gt;</code> Element</a></li>
+ <li><a href="/en-US/docs/Web/HTML/Element/video">The <code>&lt;video&gt;</code> Element</a></li>
+ <li><a href="/en-US/docs/Web/HTML/Element/source">The <code>&lt;source&gt;</code> Element</a></li>
+ <li><a href="/en-US/docs/Web/HTML/Element/img#Attributes">The <code>&lt;img&gt; srcset</code> attribute</a>
+  <ul>
+   <li><a href="/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images">Responsive images</a></li>
+  </ul>
+ </li>
+ <li><a href="/en-US/docs/Web/HTML/Preloading_content">Preloading content with <code>rel="preload"</code></a> - <a href="https://w3c.github.io/preload/">(https://w3c.github.io/preload/ </a>)</li>
+</ul>
+
+<p>CSS</p>
+
+<ul>
+ <li><a href="/en-US/docs/Web/CSS/will-change">will-change</a></li>
+ <li>GPU v CPU</li>
+ <li>Measuring layout</li>
+ <li>Font-loading best practices</li>
+</ul>
+
+<p>JavaScript</p>
+
+<ul>
+ <li><a href="/en-US/docs/Web/Events/DOMContentLoaded">DOMContentLoaded</a></li>
+ <li><a href="/en-US/docs/Glossary/Garbage_collection">Garbage collection</a></li>
+ <li><a href="/en-US/docs/Web/API/window/requestAnimationFrame">requestAnimationFrame</a></li>
+</ul>
+
+<p>APIs</p>
+
+<ul>
+ <li><a href="/en-US/docs/Web/API/Performance_API">Performance API</a></li>
+ <li><a href="/en-US/docs/Web/API/Navigation_timing_API">Navigation Timing API</a></li>
+ <li><a href="/en-US/docs/Web/API/Media_Capabilities_API/Using_the_Media_Capabilities_API">Media Capabilities API</a></li>
+ <li><a href="/en-US/docs/Web/API/Network_Information_API">Network Information API</a></li>
+ <li><a href="/en-US/docs/Web/API/PerformanceNavigationTiming">PerformanceNavigationTiming</a></li>
+ <li><a href="/en-US/docs/Web/API/Battery_Status_API">Battery Status API</a></li>
+ <li><a href="/en-US/docs/Web/API/Navigator/deviceMemory">Navigator.deviceMemory</a></li>
+ <li><a href="/en-US/docs/Web/API/Intersection_Observer_API">Intersection Observer</a></li>
+ <li><a href="/en-US/docs/Web/API/User_Timing_API/Using_the_User_Timing_API">Using the User Timing AP</a>I</li>
+ <li><a href="/en-US/docs/Web/API/Long_Tasks_API">Long Tasks API</a></li>
+ <li><a href="/en-US/docs/Web/API/DOMHighResTimeStamp">High Resolution Timing API</a> (<a href="https://w3c.github.io/hr-time/">https://w3c.github.io/hr-time/)</a></li>
+ <li><a href="/en-US/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API">Resource Timing API</a></li>
+ <li><a href="/en-US/docs/Web/API/Page_Visibility_API">Page Visibility</a></li>
+ <li><a href="/en-US/docs/Web/API/Background_Tasks_API">Cooperative Scheduling of Background Tasks API</a>
+  <ul>
+   <li style="margin-top: 0.25em;"><a href="/en-US/docs/Web/API/Window/requestIdleCallback">requestIdleCallback() </a></li>
+  </ul>
+ </li>
+ <li><a href="/en-US/docs/Web/API/Beacon_API/Using_the_Beacon_API">Beacon API</a></li>
+ <li>Resource Hints - <a href="/en-US/docs/Web/HTTP/Headers/X-DNS-Prefetch-Control">dns-prefetch</a>, preconnect, <a href="/en-US/docs/Web/HTTP/Link_prefetching_FAQ">prefetch</a>, and prerender</li>
+ <li><a href="/en-US/docs/Web/API/FetchEvent/navigationPreload">Fetchevent.navigationPreload</a></li>
+ <li><a href="/en-US/docs/Web/API/PerformanceServerTiming">Performance Server Timing API</a></li>
+</ul>
+
+<p>Headers</p>
+
+<ul>
+ <li><a href="/en-US/docs/Web/HTTP/Headers/Content-Encoding">Content-encoding</a></li>
+ <li>HTTP/2</li>
+ <li><a href="/en-US/docs/Glossary/GZip_compression">gZip</a></li>
+ <li>Client Hints</li>
+</ul>
+
+<p>Tools</p>
+
+<ul>
+ <li><a href="/en-US/docs/Tools/Performance">Performance in Firefox Developer Tools</a></li>
+ <li>Flame charts</li>
+ <li>The Network panel</li>
+ <li>Waterfall charts</li>
+</ul>
+
+<p>Additional Metrics</p>
+
+<ul>
+ <li>Speed Index and Perceptual Speed Index</li>
+</ul>
+
+<p>Best Practices</p>
+
+<ul>
+ <li><a href="/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers">Using Service Workers</a></li>
+ <li><a href="/en-US/docs/Web/API/Web_Workers_API/Using_web_workers">Using Web Workers</a>
+  <ul>
+   <li><a href="/en-US/docs/Web/API/Web_Workers_API">Web Workers API</a></li>
+  </ul>
+ </li>
+ <li><a href="/en-US/docs/Web/Apps/Progressive/Offline_Service_workers">PWA</a></li>
+ <li><a href="/en-US/docs/Web/HTTP/Caching">Caching</a></li>
+ <li>Content Delivery Networks (CDN)</li>
+</ul>
diff --git a/files/ko/web/performance/브라우저는_어떻게_동작하는가/index.html b/files/ko/web/performance/브라우저는_어떻게_동작하는가/index.html
new file mode 100644
index 0000000000..473e30980d
--- /dev/null
+++ b/files/ko/web/performance/브라우저는_어떻게_동작하는가/index.html
@@ -0,0 +1,204 @@
+---
+title: '웹페이지를 표시한다는 것: 브라우저는 어떻게 동작하는가'
+slug: Web/Performance/브라우저는_어떻게_동작하는가
+translation_of: Web/Performance/How_browsers_work
+---
+<p>Users want web experiences with content that is fast to load and smooth to interact with. Therefore, <span class="seoSummary">a developer should strive to achieve these two goals. </span></p>
+
+<p><span class="seoSummary">To understand how to improve performance and perceived performance, it helps to understand how the browser works.</span></p>
+
+<h2 id="개요">개요</h2>
+
+<p>Fast sites provide better user experiences. Users want and expect web experiences with content that is fast to load and smooth to interact with.</p>
+
+<p>Two major issues in web performance are understanding issues having to do with latency and issues having to do with the fact that for the most part, browsers are single threaded.</p>
+
+<p>Latency is our main threat to overcome to ensure a fast load. To be fast to load, the developers’ goals include sending requested information as fast as possible, or at least seem super fast. Network latency is the time it takes to transmit bytes over-the-air to computers. Web performance is what we have to do to make the page load happen as quickly as possible.</p>
+
+<p>For the most part, browsers are considered single threaded. For smooth interactions, the developer's goal is to ensure performant site interactions, from smooth scrolling to being responsive to touch. Render time is key, with ensuring the main thread can complete all the work we throw at it and still always be available to handle user interactions. Web performance can be improved by understanding the single-threaded nature of the browser and minimizing the main thread's responsibilities, where possible and appropriate, to ensure rendering is smooth and responses to interactions are immediate.</p>
+
+<h2 id="여정">여정</h2>
+
+<p><em>Navigation</em> is the first step in loading a web page. It occurs whenever a user requests a page by entering a URL into the address bar, clicking a link, submitting a form, as well as other actions.</p>
+
+<p>One of the goals of web performance is to minimize the amount of time a navigation takes to complete. In ideal conditions, this usually doesn't take too long, but latency and bandwidth are foes which can cause delays.</p>
+
+<h3 id="DNS_Lookup">DNS Lookup</h3>
+
+<p>The first step of navigating to a web page is finding where the assets for that page are located. If you navigate to <code>https://example.com</code>, the HTML page is located on the server with IP address of <code>93.184.216.34</code>. If you’ve never visited this site, a DNS lookup must happen.</p>
+
+<p>Your browser requests a DNS lookup, which is eventually fielded by a name server, which in turn responds with an IP address. After this initial request, the IP will likely be cached for a time, which speeds up subsequent requests by retrieving the IP address from the cache instead of contacting a name server again.</p>
+
+<p>DNS lookups usually only need to be done once per hostname for a page load. However, DNS lookups must be done for each unique hostname the requested page references. If your fonts, images, scripts, ads, and metrics all have different hostnames, a DNS lookup will have to be made for each one.</p>
+
+<p><img alt="Mobile requests go first to the cell tower, then to a central phone company computer before being sent to the internet" src="https://mdn.mozillademos.org/files/16743/latency.jpg" style="height: 281px; width: 792px;"></p>
+
+<p>This can be problematic for performance, particularly on mobile networks. When a user is on a mobile network, each DNS lookup has to go from the phone to the cell tower to reach an authoritative DNS server. The distance between a phone, a cell tower, and the name server can add significant latency.</p>
+
+<h3 id="TCP_Handshake">TCP Handshake</h3>
+
+<p>Once the IP address is known, the browser sets up a connection to the server via a {{glossary('TCP handshake','TCP three-way handshake')}}. This mechanism is designed so that two entities attempting to communicate—in this case the browser and web server—can negotiate the parameters of the network TCP socket connection before transmitting data, often over {{glossary('HTTPS')}}.</p>
+
+<p>TCP's three way handshaking technique is often referred to as "SYN-SYN-ACK"—or more accurately SYN, SYN-ACK, ACK—because there are three messages transmitted by TCP to negotiate and start a TCP session between two computers. Yes, this means three more messages back and forth between each server, and the request has yet to be made.</p>
+
+<h3 id="TLS_Negotiation">TLS Negotiation</h3>
+
+<p>For secure connections established over HTTPS, another "handshake" is required. This handshake, or rather the {{glossary('TLS')}} negotiation, determines which cipher will be used to encrypt the communication, verifies the server, and establishes that a secure connection is in place before beginning the actual transfer of data. This requires three more round trips to the server before the request for content is actually sent.</p>
+
+<p><img alt="The DNS lookup, the TCP handshake, and 5 steps of the TLS handshake including clienthello, serverhello and certificate, clientkey and finished for both server and client." src="https://mdn.mozillademos.org/files/16746/ssl.jpg" style="height: 412px; width: 729px;"></p>
+
+<p>While making the connection secure adds time to the page load, a secure connection is worth the latency expense, as the data transmitted between the browser and the web server cannot be decrypted by a third party.</p>
+
+<p>After the 8 round trips, the browser is finally able to make the request.</p>
+
+<h2 id="응답">응답</h2>
+
+<p>Once we have an established connection to a web server, the browser sends an initial <a href="/en-US/docs/Web/HTTP/Methods">HTTP <code>GET</code> request</a> on behalf of the user, which for websites is most often an HTML file. Once the server receives the request, it will reply with relevant response headers and the contents of the HTML.</p>
+
+<pre class="brush: html">&lt;!doctype HTML&gt;
+&lt;html&gt;
+ &lt;head&gt;
+  &lt;meta charset="UTF-8"/&gt;
+  &lt;title&gt;My simple page&lt;/title&gt;
+  &lt;link rel="stylesheet" src="styles.css"/&gt;
+  &lt;script src="myscript.js"&gt;&lt;/script&gt;
+&lt;/head&gt;
+&lt;body&gt;
+  &lt;h1 class="heading"&gt;My Page&lt;/h1&gt;
+  &lt;p&gt;A paragraph with a &lt;a href="https://example.com/about"&gt;link&lt;/a&gt;&lt;/p&gt;
+  &lt;div&gt;
+    &lt;img src="myimage.jpg" alt="image description"/&gt;
+  &lt;/div&gt;
+  &lt;script src="anotherscript.js"&gt;&lt;/script&gt;
+&lt;/body&gt;
+&lt;/html&gt;</pre>
+
+<p>This response for this initial request contains the first byte of data received. {{glossary('Time to First Byte')}} (TTFB) is the time between when the user made the request—say by clicking on a link—and the receipt of this first packet of HTML. The first chunk of content is usually 14kb of data.</p>
+
+<p>In our example above, the request is definitely less than 14Kb, but the linked resources aren't requested until the browser encounters the links during parsing, described below.</p>
+
+<h3 id="TCP_Slow_Start_14kb_rule">TCP Slow Start / 14kb rule</h3>
+
+<p>The first response packet will be 14Kb. This is part of {{glossary('TCP slow start')}}, an algorithm which balances the speed of a network connection. Slow start gradually increases the amount of data transmitted until the network's maximum bandwidth can be determined.</p>
+
+<p>In {{glossary('TCP slow start')}}, after receipt of the initial packet, the server doubles the size of the next packet to around 28Kb. Subsequent packets increase in size until a predetermined threshold is reached, or congestion is experienced.</p>
+
+<p><img alt="TCP slow start" src="https://mdn.mozillademos.org/files/16754/congestioncontrol.jpg" style="height: 412px; width: 729px;"></p>
+
+<p>If you’ve ever heard of the 14Kb rule for initial page load, TCP slow start is the reason why the initial response is 14Kb, and why web performance optimization calls for focusing optimizations with this initial 14Kb response in mind. TCP slow start gradually builds up transmission speeds appropriate for the network's capabilities to avoid congestion.</p>
+
+<h3 id="Congestion_control">Congestion control</h3>
+
+<p><span style="font-weight: 400;">As the server sends data in TCP packets, the user's client confirms delivery by returning acknowledgements, or ACKs. The connection has a limited capacity depending on hardware and network conditions. If the server sends too many packets too quickly, they will be dropped. Meaning, there will be no acknowledgement. The server registers this as missing ACKs. Congestion control algorithms use this flow of sent packets and ACKs to determine a send rate.</span></p>
+
+<h2 id="파싱">파싱</h2>
+
+<p>Once the browser receives the first chunk of data, it can begin parsing the information received. {{glossary('speculative parsing', 'Parsing')}} is the step the browser takes to turn the data it receives over the network into the {{glossary('DOM')}} and {{glossary('CSSOM')}}, which is used by the renderer to paint a page to the screen.</p>
+
+<p>The DOM is the internal representation of the markup for the browser. The DOM is also exposed, and can be manipulated through various APIs in JavaScript.</p>
+
+<p>Even if the request page's HTML is larger than the initial 14KB packet, the browser will begin parsing and attempting to render an experience based on the data it has. This is why it's important for web performance optimization to include everything the browser needs to start rendering a page, or at least a template of the page - the CSS and HTML needed for the first render -- in the first 14 kilobytes. But before anything is rendered to the screen, the HTML, CSS, and JavaScript have to be parsed.</p>
+
+<h3 id="Building_the_DOM_tree">Building the DOM tree</h3>
+
+<p>We describe five steps in the <a href="/en-US/docs/Web/Performance/Critical_rendering_path">critical rendering path</a>.</p>
+
+<p>The first step is processing the HTML markup and building the DOM tree. HTML parsing involves <a href="/en-US/docs/Web/API/DOMTokenList">tokenization</a> and tree construction. HTML tokens include start and end tags, as well as attribute names and values. If the document is well-formed, parsing it is straightforward and faster. The parser parses tokenized input into the document, building up the document tree.</p>
+
+<p>The DOM tree describes the content of the document. The <code><a href="/en-US/docs/Web/HTML/Element/html">&lt;html&gt;</a></code> element is the first tag and root node of the document tree. The tree reflects the relationships and hierarchies between different tags. Tags nested within other tags are child nodes. The greater the number of DOM nodes, the longer it takes to construct the DOM tree.</p>
+
+<p><img alt="The DOM tree for our sample code, showing all the nodes, including text nodes." src="https://mdn.mozillademos.org/files/16759/DOM.gif" style="height: 689px; width: 754px;"></p>
+
+<p>When the parser finds non-blocking resources, such as an image, the browser will request those resources and continue parsing. Parsing can continue when a CSS file is encountered, but <code>&lt;script&gt;</code> tags—particularly those without an <code><a href="/en-US/docs/Web/JavaScript/Reference/Statements/async_function">async</a></code> or <code>defer</code> attribute—block rendering, and pause the parsing of HTML. Though the browser's preload scanner hastens this process, excessive scripts can still be a significant bottleneck.</p>
+
+<h3 id="Preload_scanner">Preload scanner</h3>
+
+<p>While the browser builds the DOM tree, this process occupies the main thread. As this happens, the <em>preload scanner</em> will parse through the content available and request high priority resources like CSS, JavaScript, and web fonts. Thanks to the preload scanner, we don't have to wait until the parser finds a reference to an external resource to request it. It will retrieve resources in the background so that by the time the main HTML parser reaches requested assets, they may possibly already be in flight, or have been downloaded. The optimizations the preload scanner provides reduce blockages.</p>
+
+<pre class="brush:html">&lt;link rel="stylesheet" src="styles.css"/&gt;
+&lt;script src="myscript.js" <strong>async</strong>&gt;&lt;/script&gt;
+&lt;img src="myimage.jpg" alt="image description"/&gt;
+&lt;script src="anotherscript.js" <strong>async</strong>&gt;&lt;/script&gt;
+</pre>
+
+<p>In this example, while the main thread is parsing the HTML and CSS, the preload scanner will find the scripts and image, and start downloading them as well. To ensure the script doesn't block the process, add the <code>async</code> attribute, or the <code>defer</code> attribute if JavaScript parsing and execution order is not important.</p>
+
+<p>Waiting to obtain CSS doesn't block HTML parsing or downloading, but it does block JavaScript, because JavaScript is often used to query CSS properties’ impact on elements.</p>
+
+<h3 id="Building_the_CSSOM">Building the CSSOM</h3>
+
+<p>The second step in the critical rendering path is processing CSS and building the CSSOM tree. The CSS object model is similar to the DOM. <span style="color: #212121; display: inline !important; float: none; font-family: Roboto,sans-serif; font-size: 16px; font-style: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration-style: initial; text-indent: 0px; text-transform: none; white-space: normal;">The DOM and CSSOM are both trees. They are independent data structures</span>. The browser converts the CSS rules into a map of styles it can understand and work with. The browser goes through each rule set in the CSS, creating a tree of nodes with parent, child, and sibling relationships based on the CSS selectors.</p>
+
+<p>As with HTML, the browser needs to convert the received CSS rules into something it can work with. Hence, it repeats the HTML-to-object process, but for the CSS.</p>
+
+<p>The CSSOM tree includes styles from the user agent style sheet. The browser begins with the most general rule applicable to a node and recursively refines the computed styles by applying more specific rules. In other words, it cascades the property values.</p>
+
+<p>Building the CSSOM is very, very fast and is not displayed in a unique color in current developer tools. Rather, the "Recalculate Style" in developer tools shows the total time it takes to parse CSS, construct the CSSOM tree, and recursively calculate computed styles. In terms of web performance optimization, there are lower hanging fruit, as the total time to create the CSSOM is generally less than the time it takes for one DNS lookup.</p>
+
+<h3 id="Other_Processes">Other Processes</h3>
+
+<h4 id="JavaScript_Compilation">JavaScript Compilation</h4>
+
+<p>While the CSS is being parsed and the CSSOM created, other assets, including JavaScript files, are downloading (thanks to the preload scanner). JavaScript is interpreted, compiled, parsed and executed. The scripts are parsed into abstract syntax trees. Some browser engines take the {{glossary('Abstract Syntax Tree')}} and pass it into an interpreter, outputting bytecode which is executed on the main thread. This is known as JavaScript compilation.</p>
+
+<h4 id="Building_the_Accessibility_Tree">Building the Accessibility Tree</h4>
+
+<p>The browser also builds an <a href="/en-US/docs/Learn/Accessibility">accessibility</a> tree that assistive devices use to parse and interpret content. The accessibility object model (AOM) is like a semantic version of the DOM. The browser updates the accessibility tree when the DOM is updated. The accessibility tree is not modifiable by assistive technologies themselves.</p>
+
+<p>Until the AOM is built, the content is not accessible to <a href="/en-US/docs/Web/Accessibility/ARIA/ARIA_Screen_Reader_Implementors_Guide">screen readers</a>.</p>
+
+<h2 id="렌더">렌더</h2>
+
+<p>Rendering steps include style, layout, paint and, in some cases, compositing. The CSSOM and DOM trees created in the parsing step are combined into a render tree which is then used to compute the layout of every visible element, which is then painted to the screen. In some cases, content can be promoted to their own layers and composited, improving performance by painting portions of the screen on the GPU instead of the CPU, freeing up the main thread.</p>
+
+<h3 id="Style">Style</h3>
+
+<p>The third step in the critical rendering path is combining the DOM and CSSOM into a render tree.The computed style tree, or render tree, construction starts with the root of the DOM tree, traversing each visible node.</p>
+
+<p>Tags that aren't going to be displayed, like the <code><a href="/en-US/docs/Web/HTML/Element/head">&lt;head&gt;</a></code> and its children and any nodes with <code>display: none</code>, such as the <code>script { display: none; }</code> you will find in user agent stylesheets, are not included in the render tree as they will not appear in the rendered output. Nodes with <code>visibility: hidden</code> applied are included in the render tree, as they do take up space. As we have not given any directives to override the user agent default, the <code>script</code> node in our code example above will not be included in the render tree.</p>
+
+<p>Each visible node has its CSSOM rules applied to it. The render tree holds all the visible nodes with content and computed styles -- matching up all the relevant styles to every visible node in the DOM tree, and determining, based on the <a href="/en-US/docs/Web/CSS/Cascade">CSS cascade</a>, what the computed styles are for each node.</p>
+
+<h3 id="Layout">Layout</h3>
+
+<p>The fourth step in the critical rending path is running layout on the render tree to compute the geometry of each node. <em>Layout</em> is the process by which the width, height, and location of all the nodes in the render tree are determined, plus the determination of the size and position of each object on the page. <em>Reflow</em> is any subsequent size and position determination of any part of the page or the entire document.</p>
+
+<p>Once the render tree is built, layout commences. The render tree identified which nodes are displayed (even if invisible) along with their computed styles, but not the dimensions or location of each node. To determine the exact size and location of each object, the browser starts at the root of the render tree and traverses it.</p>
+
+<p>On the web page, most everything is a box. Different devices and different desktop preferences mean an unlimited number of differing viewport sizes. In this phase, taking the viewport size into consideration, the browser determines what the dimensions of all the different boxes are going to be on the screen. Taking the size of the viewport as its base, layout generally starts with the body, laying out the dimensions of all the body’s descendants, with each element's box model properties, providing placeholder space for replaced elements it doesn’t know the dimensions of, such as our image.</p>
+
+<p>The first time the size and position of nodes are determined is called <em>layout</em>. Subsequent recalculations of node size and locations are called <em>reflows</em>.  In our example, suppose the initial layout occurs before the image is returned. Since we didn't declare the size of our image, there will be a reflow once the image size is known.</p>
+
+<h3 id="Paint">Paint</h3>
+
+<p>The last step in the critical rendering path is painting the individual nodes to the screen, the first occurence of which is called the <a href="/en-US/docs/Glossary/first_meaningful_paint">first meaningful paint</a>. In the painting or rasterization phase, the browser converts each box calculated in the layout phase to actual pixels on the screen. Painting involves drawing every visual part of an element to the screen, including text, colors, borders, shadows, and replaced elements like buttons and images. The browser needs to do this super quickly.</p>
+
+<p>To ensure smooth scrolling and animation, everything occupying the main thread, including calculating styles, along with reflow and paint, must take the browser less than 16.67ms to accomplish. At 2048 X 1536, the iPad has over 3,145,000 pixels to be painted to the screen. That is a lot of pixels that have to be painted very quickly. To ensure repainting can be done even faster than the initial paint, the drawing to the screen is generally broken down into several layers. If this occurs, then compositing is necessary.</p>
+
+<p>Painting can break the elements in the layout tree into layers. Promoting content into layers on the GPU (instead of the main thread on the CPU) improves paint and repaint performance. There are specific properties and elements that instantiate a layer, including <code><a href="/en-US/docs/Web/HTML/Element/video">&lt;video&gt;</a></code> and <code><a href="/en-US/docs/Web/HTML/Element/canvas">&lt;canvas&gt;</a></code>, and any element which has the CSS properties of <a href="/en-US/docs/Web/CSS/opacity"><code>opacity</code></a>, a 3D <code><a href="/en-US/docs/Web/CSS/transform">transform</a></code>, <code><a href="/en-US/docs/Web/CSS/will-change">will-change</a></code>, and a few others. These nodes will be painted onto their own layer, along with their descendants, unless a descendant necessitates its own layer for one (or more) of the above reasons.</p>
+
+<p>Layers do improve performance, but are expensive when it comes to memory management, so should not be overused as part of web performance optimization strategies.</p>
+
+<h3 id="Compositing">Compositing</h3>
+
+<p>When sections of the document are drawn in different layers, overlapping each other, compositing is necessary to ensure they are drawn to the screen in the right order and the content is rendered correctly.</p>
+
+<p>As the page continues to load assets, reflows can happen (recall our example image that arrived late).  A reflow sparks a repaint and a re-composite. Had we defined the size of our image, no reflow would have been necessary, and only the layer that needed to be repainted would be repainted, and composited if necessary. But we didn't include the image size! When the image is obtained from the server, the rendering process goes back to the layout steps and restarts from there.</p>
+
+<h2 id="상호운용성">상호운용성</h2>
+
+<p>Once the main thread is done painting the page, you would think we would be "all set." That isn't necessarily the case. If the load includes JavaScript, that was correctly deferred, and only executed after the <code><a href="/en-US/docs/Web/API/GlobalEventHandlers/onload">onload</a></code> event fires, the main thread might be busy, and not available for scrolling, touch, and other interactions.</p>
+
+<p>{{glossary('Time to Interactive')}} (TTI) is the measurement of how long it took from that first request which led to the DNS lookup and SSL connection to when the page is interactive -- interactive being the point in time after the {{glossary('First Contentful Paint')}} when the page responds to user interactions within 50ms. If the main thread is occupied parsing, compiling, and executing JavaScript, it is not available and therefore not able to responsd to user interactions in a timely (less than 50ms) fashion.</p>
+
+<p>In our example, maybe the image loaded quickly, but perhaps the <code>anotherscript.js</code> file was 2MB and our user's network connection was slow.  In this case the user would see the page super quickly, but wouldn't be able to scroll without jank until the script was downloaded, parsed and executed. That is not a good user experience. Avoid occupying the main thread, as demonstrated in this WebPageTest example:</p>
+
+<p><img alt="The main thread is occupied by the downloading, parsing and execution of a  javascript file - over a fast connection" src="https://mdn.mozillademos.org/files/16760/visa_network.png" style="height: 699px; width: 1200px;"></p>
+
+<p>In this example, the DOM content load process took over 1.5 seconds, and the main thread was fully occupied that entire time, unresponsive to click events or screen taps.</p>
+
+<h2 id="같이_보기">같이 보기</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/Performance">Web Performance</a></li>
+</ul>
diff --git a/files/ko/web/performance/중요_렌더링_경로/index.html b/files/ko/web/performance/중요_렌더링_경로/index.html
new file mode 100644
index 0000000000..0dd28ed81c
--- /dev/null
+++ b/files/ko/web/performance/중요_렌더링_경로/index.html
@@ -0,0 +1,60 @@
+---
+title: 중요 렌더링 경로
+slug: Web/Performance/중요_렌더링_경로
+translation_of: Web/Performance/Critical_rendering_path
+---
+<p>{{draft}}</p>
+
+<p>중요 렌더링 경로 (<em>Critical Rendering Path</em>)는 브라우저가 HTML, CSS, Javascipt를 화면에 픽셀로 변화하는 일련의 단계를 말하며 이를 최적화하는 것은 렌더링 성능을 향상시킵니다. 중요 렌더링 경로는 <a href="https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model">Document Object Model </a>(DOM), <a href="https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_Model">CSS Object Model </a>(CSSOM), 렌더 트리 그리고 레이아웃을 포함합니다.</p>
+
+<p>도큐먼트 오브젝트 모델은 HTML을 분석함으로써 만들어집니다. HTML은 Javascript를 요청할 수 있으며, 이 경우 DOM 이 변경될 수 있습니다. HTML은 차례대로 CSS 오브젝트 모델을 만들기 위한 스타일에 대한 요청을 만들거나 포함합니다. 브라우저 엔진은 이 두가지를 결합하여 렌더 트리를 생성하며 레이아웃은 페이지의 모든 것에 대한 크기와 위치를 결정합니다. 일단 레이아웃이 결정되면 화면에 픽셀을 그립니다.</p>
+
+<p>중요 렌더링 경로 최적화는 첫번째 렌더링의 시간을 개선시킵니다. 중요 렌더링 경로를 이해하고, 최적화 하는 것은 뛰어난 사용자 상호작용을 보장하며 버벅거림을 피할 수 있도록 하고, 1초당 60 프레임에 리플로우와 리페인트가 발생할 수 있도록 하는데 중요합니다.</p>
+
+<h2 id="CRP_이해하기">CRP 이해하기</h2>
+
+<p>웹 성능은 서버의 요청과 응답, 로딩, 스크립팅, 렌더링, 레이아웃 그리고 화면에 픽셀 그리기를 포함합니다.</p>
+
+<p>웹 페이지 또는 어플리케이션에 대한 요청은 HTML 요청으로 시작됩니다. 서버는 응답 헤더 또는 데이터로 HTML을 반환합니다. 그리고 나서 브라우저는 HTML을 분석하고 수신된 바이츠를 DOM 트리로 변환하기 시작합니다. 브라우저는 스타일시트, 스크립트 또는 포함된 이미지 참조인 외부 자원에 대한 링크를 찾을때마다 요청을 시작합니다. 불러온 에셋을 다룰 때까지 나머지 HTML을 분석하는 작업하는 일부 요청은 중단되며 차단됩니다. 브라우저는 CSS 오브젝트 모델을 구축하는 작업이 끝날때까지 요청을 만들고 DOM을 생성하는 HTML을 계속해서 분석합니다. DOM과 CSSOM이 완료되면 브라우저는 렌더 트리를 생성하고 보여지는 컨텐츠를 위해 스타일을 계산합니다. 렌더트리가 완료된 후 모든 렌더 트리 요소들에 대한 위치와 크기가 정의된 레이아웃이 만들어집니다. 일단 완료되면 레이지는 렌더링되거나 또는 화면에 '그려집니다(<em>painted</em>)'.</p>
+
+<h3 id="Document_Object_Model">Document Object Model</h3>
+
+<p>DOM 구성은 점진적으로 증가합니다. HTML 응답은 토큰으로, 토큰은 노드로, 노드는 DOM 트리로 변환됩니다.1개의 DOM 노드는 시작태그 토큰으로 시작해서 끝태그 토큰으로 끝납니다. 노드들은 HTML 요소에 대한 모두 연관성 있는 정보를 포함하고 있습니다. 그 정보는 토큰을 통해 설명됩니다. 노드들은 토큰의 위계서열을 기반으로 DOM 트리안에 연결됩니다. 만약 또 다른 시작태그와 끝태그의 묶음이 한 세트의 시작태그와 끝태그 사이에 있다면, 여러분은 DOM 트리의 위계서열을 정의하는 방법으로 노드 안에 노드를 가지게 됩니다.</p>
+
+<p>많은 수의 노드는 중요 렌더링 경로에서 다음의 이벤트를 더 오래 발생시킬 것입니다. 측정하세요! 몇 개의 추가 노드는 차이를 만들지 않지만 전염은 버벅거림을 유발할 수 있습니다.</p>
+
+<h3 id="CSS_Object_Model">CSS Object Model</h3>
+
+<p>DOM은 페이지의 모든 컨텐츠를 포함하고, CSSOM은 DOM을 스타일링 하기 위한 페이지의 모든 스타일 정보를 포함합니다. CSSOM은 DOM과 유사하지만 다릅니다. DOM의 구조는 점진적으로 증가하는 반면에 CSSOM은 그렇지 않습니다. CSS는 렌더링을 막습니다: 브라우저는 모든 CSS를 처리하고 수신할때까지 페이지 렌더링을 막습니다. CSS는 규칙을 덮어쓸수 있기 때문에 렌더링을 막습니다. 그러므로 CSSOM이 완료될때까지 콘텐츠를 렌더링 할 수 없습니다.</p>
+
+<p>CSS는 유효한 토크들은 인식하기 위해 스스로 규칙 세트를 가지고 있습니다. CSS의 C가 'Cascade(종속 또는 폭포)'라는 의미를 기억해두세요. CSS 규칙은 아래로 종속됩니다. 분석기는 토큰을 노드로 변환할때, 하위 노드가 스타일을 상속합니다. 연속적인 규칙들이 이전의 규칙들에 덮어쓰여질 수 있기 때문에, 증감 처리 기술은 HTML 처럼 CSS에 적용되지는 않습니다. CSS 개체 모델은 CSS를 분석할 때 빌드되지만 나중에 분석되 덮어쓸 스타일들은 화면에 렌더링 할 수 없기 때문에 완전히 분석될 때까지 렌더 트리를 생성하는데 사용할 수 없습니다.</p>
+
+<p>선택자 성능 측면에서, 덜 구체적인 선택자는 더 구체적인 선택자보다 더 빠릅니다. 예를 들어, 브라우저가 <code>.foo</code> 찾을때, <code>.foo {}</code> 는 <code>.bar .foo {}</code> 보다 빠릅니다. 왜냐하면 두번째 시나리오에서, <code>.foo</code> 가 부모 객체인 <code>.bar</code> 를 가지고 있는지 확인하기 위해 DOM을 거슬러 올라가기 때문입니다. 더 구체적인 태그는 브라우저에게 더 많은 작업을 요구하지만 이러한 패널티는 최적화 할 가치가 없습니다.</p>
+
+<p>만약 CSS 분석 시간을 측정한다면, 브라우저들이 정말 빠르다는 것에 놀랄 것입니다. 규칙이 구체적일수록 DOM 트리 안에서 더 많은 노드들은 지나야 하기 때문에 더 높은 비용이 듭니다. 그러나 추가적인 비용은 일반적으로 최소입니다. 첫번째는 측정입니다. 필요할때 최적화하세요. 특정 짓는 것은 쉬운 일이 아닙니다. CSS 측면에서, 선택자 성능 최적화와 개선은 오직 microsecond 밖에 되지 않될 것입니다. 축소화와 미디어 쿼리를 사용함으로써 지연된 CSS를 논-블로킹 요청으로 분리하는 것과 같은 <a href="https://developer.mozilla.org/en-US/docs/Learn/Performance/CSS_performance">CSS 최적화</a>를 위한 다른 방법이 있습니다.</p>
+
+<h3 id="Render_Tree">Render Tree</h3>
+
+<p>렌터 트리는 콘텐츠와 스타일 둘다 캡쳐합니다. DOM과 CSSOM 트리는 렌더 트리에 결합됩니다. 렌더 트리를 구성하기 위해 브라우저는 DOM 트리의 root에서 시작해 모든 노드는 확인하면서 어떤 CSS 규칙들을 첨부할지 결정합니다.</p>
+
+<p>렌더 트리는 오직 보여지는 콘텐츠만은 캡쳐합니다. (일반적으로) 헤드 섹션은 보여지는 정보를 포함하고 있지 않으므로 렌더트리 안에 포함되지 않습니다. 만약 요소에 <code>display: none</code> 이 적용되어 있다면, 해당 요소 또는 하위 요소는 포함되지 않습니다.</p>
+
+<h3 id="Layout">Layout</h3>
+
+<p>일단 렌더 트리가 생성되고 나면, 레이아웃은 가능해지며 화면의 크기에 의존합니다. 레이아웃 단계는 요소들이 페이지에서 배치되는 위치와 방법, 각 요소의 너비와 높이 그리고 서로 관련된 위치를 결정합니다.</p>
+
+<p>요소의 너비는 무엇일까요? 정의에 따르면, 블럭 수준의 요소들은 그 부모 너비의 기본 너비값의 100% 입니다. 50%의 너비를 갖는 요소는 부모 요소의 절반일 것입니다. 비록 그렇게 정의되어 있지 않더라고, <code>body</code> 는 뷰포트 너비의 100%를 의미하는 너비 입니다. 디바이스의 너비는 레이아웃에 영향을 미칩니다.</p>
+
+<p>뷰포트 메타 태그는 레이아웃에 영향을 미치는 뷰포트 레이아웃의 너비로 정의합니다. 이 태그 없다면, 브라우저는 뷰포트 기본값을 사용합니다. 브라우저의 full screen 기본값은 일반적으로 960px 입니다. 기본적으로 브라우저의 full screen에서, 스마트폰의 브라우저와 같은 너비는 <code>&lt;meta name="Viewport" content="width=device-witdh"&gt;</code> 로 세팅함으로써 기본 뷰포트 너비 대신에 디바이스의 너비를 사용합니다. 디바이스 너비는 사용자가 디비이스를 가로(landscapre) 또는 세로(portrait) 모드 사이로 돌릴때마다 바뀝니다. 레이아웃은 디바이스가 회전하거나 브라우저의 사이즈가 조정될 때마다 발생합니다.</p>
+
+<p>레이아웃 성능은 DOM의 영향을 받습니다. 노드의 수가 많을수록 레이아웃은 더 길어지며 스크롤링 또는 다른 애니메이션들이 필요하다면 레이아웃에 쟁크(jank)를 일으키는 병목현상이 발생할 수 있습니다. 로딩 또는 방향 전환에 20ms 정도 밀릴 수 있지만 애니메이션 또는 스크롤에 쟁크(jank) 유발할 수 있습니다. 노드에 박스 모델 업데이트, 콘텐츠 대체 그리고 노드 추가와 같은 수정은 언제든지 렌더 트리를 수정할 수 있으며 레이아웃을 형성합니다.</p>
+
+<p>레이아웃 이벤트의 반복과 형성시간을 줄이기 위해서 일괄 업데이트 해야하고, 박스 모델 속성을 애니메이션화 하지 말아야 합니다.</p>
+
+<h3 id="Paint">Paint</h3>
+
+<p>마자믹 단계는 화면에 픽셀을 그리는 것입니다. 일단 렌더 트리가 생성되고 레이아웃나 나타나기 시작하면, 화면에 픽셀을 그릴수 있습니다. 로드시, 전체 화면을 그립니다. 그 후에는 브라우저가 필요한 최소 영역만을 다시 그리도록 최적화되어 있기 때문에 영향을 받는 영역만을 화면에 다시 그립니다. 그리는 시간은 렌터 트리에 적용되는 업데이트의 종류가 무엇있냐에 따라 달라집니다. 페인팅인 매우 빠르게 진행되는 과정이기 때문에 성능 향상에 집중해야 하는 가장 큰 영향있는 부분이 아닐 수 있지만, 애니메이션 프레임 소요시간을 측정할때, 레이아웃과 리페인트 시간을 모두 고려하는 것이 중요합니다. 각 노드에 적용된 스타일은 페인트 시간을 증가시키지만 페인트 시간을 0.001ms 증가시키는 스타일을 제거하는 것은 여러분의 최적화 비용이 매우 커지는 것을 막지 못할 수 있습니다. 첫째는 측정하는 것을 기억하고, 최적화 우선순위를 정해야할지 말지를 결정해야 합니다.</p>
+
+<h2 id="Optimizing_for_CRP">Optimizing for CRP</h2>
+
+<p>자원 로드 순서를 관리하고, 파일 사이즈를 줄이며 어떤 자원을 먼저 로드할지 정함으로써 페이지 로드 속도를 개선하세요. 성능 팁으로는 1) 자원 다운로드를 연기함으로써 중요 자원들의 수를 최소화하기 , 2) 각 요청에 대한 파일 사이즈에 따라 필수적인 요청 횟수 최적하하기, 3) 다운받을 중요 에셋의 우선순위를 정함으로써 중요 자원 불러오는 순서 최적화하고, 중요 경로 길이 최소화하기</p>