Skip to content

Commit 46ee704

Browse files
hardsoncorehardsoncore
committed
feat: upd answer for question N2
1 parent 4acbedf commit 46ee704

6 files changed

Lines changed: 339 additions & 180 deletions

File tree

‎src/assets/content/eng/answers/2-How-to-optimize-page-rendering.md‎

Lines changed: 111 additions & 59 deletions
Original file line numberDiff line numberDiff line change
@@ -1,59 +1,111 @@
1-
<h3>1. Understanding the Critical Rendering Path (CRP)</h3>
2-
3-
<p><span class="accent"> Critical Rendering Path (CRP)</span> is the sequence of steps the browser goes through to convert HTML, CSS, and JavaScript into pixels on the screen. Rendering optimization is essentially minimizing the time it takes to complete this path.</p>
4-
5-
<p><strong>Steps:</strong> DOM Construction -> CSSOM Construction -> Render Tree Formation -> Layout (geometry calculation) -> Paint (drawing pixels).</p>
6-
7-
<p><strong>Main Rule:</strong> The faster the browser builds the Render Tree, the faster the user will see the content. Therefore, it is crucial to optimize resource loading and processing to minimize the time to the first display (<strong>First Contentful Paint</strong>) and the time to full interactivity (<strong>Time to Interactive</strong>).</p>
8-
9-
<h3>2. DOM (HTML) Optimization</h3>
10-
<p>The element tree should be as lightweight as possible.</p>
11-
12-
<p><strong>Reducing Nesting Depth:</strong> Avoid unnecessary wrappers (like a <code>&lt;div&gt;</code> inside a <code>&lt;div&gt;</code> just for a single margin). The deeper the DOM, the harder it is for the browser to recalculate Layout.</p>
13-
14-
<p><strong>DOM Size:</strong> Try to keep the number of nodes on the page within reasonable limits (it is recommended not to exceed 1500 nodes).</p>
15-
16-
<p><strong>Semantics:</strong> Using the correct tags speeds up parsing and improves accessibility.</p>
17-
18-
<h3>3. CSSOM (CSS) Optimization</h3>
19-
<p>CSS is render-blocking. The browser will not paint the page until it has downloaded and parsed all synchronous styles.</p>
20-
21-
<p><strong>Critical CSS:</strong> Extract the styles needed to render the first screen (Above the Fold) and inline them directly into the <code>&lt;head&gt;</code>.</p>
22-
23-
<p><strong>Asynchronous Loading for the Rest of CSS:</strong> Load the remaining styles asynchronously (e.g., via <code>&lt;link rel="preload"&gt;</code> or media queries).</p>
24-
25-
<p><strong>Selector Complexity:</strong> Avoid universal and overly nested selectors (like <code>.wrapper ul li a span</code>). The browser reads selectors from right to left, and complex chains force it to make many unnecessary checks.</p>
26-
27-
<p><strong>Animations:</strong> Only animate <code>transform</code> and <code>opacity</code> properties. They do not trigger geometry recalculation (Layout) or repainting (Paint), but are handled at the composite level by the GPU.</p>
28-
29-
<h3>4. JavaScript and Framework Optimization</h3>
30-
<p>JS blocks HTML parsing. When the parser encounters a <code>&lt;script&gt;</code>, it stops, downloads, and executes it.</p>
31-
32-
<p><code>defer</code> and <code>async</code>: Always use these attributes for external scripts so they do not block page parsing.</p>
33-
34-
<p><strong>Code Splitting and Lazy Loading:</strong> Do not load the entire application bundle at once. Split the code by routes or components.</p>
35-
36-
<p><strong>Working with Reactivity:</strong> In Vue 2, be mindful of what you put in <code>data()</code>. If an object is large and doesn't require reactivity, use <code>Object.freeze()</code>. For static template parts, the <code>v-once</code> directive works perfectly.</p>
37-
38-
<p><strong>In Angular:</strong> By default, every asynchronous event triggers a full check (Change Detection). Be sure to switch components to the <code>ChangeDetectionStrategy.OnPush</code> strategy so that checks only occur when <code>@Input()</code> references change.</p>
39-
40-
<p><strong>Web Workers:</strong> Offload heavy calculations (e.g., parsing large JSONs or complex math) to background threads so you do not block the Main Thread.</p>
41-
42-
<h3>5. Media and Fonts (Resources) Optimization</h3>
43-
<p>Heavy resources delay the loading of useful content.</p>
44-
45-
<p><strong>Images:</strong> Use modern formats (WebP, AVIF), and always specify <code>width</code> and <code>height</code> attributes to prevent content jumps (Cumulative Layout Shift - CLS).</p>
46-
47-
<p><strong>Lazy Loading:</strong> Use <code>loading="lazy"</code> for images and <code>iframe</code>s that are out of the viewport (below the fold).</p>
48-
49-
<p><strong>Fonts:</strong> Use <code>font-display: swap</code> in <code>@font-face</code>. This allows the browser to immediately display text using a system font while the custom one is still loading, avoiding the "invisible text" effect (FOIT).</p>
50-
51-
<h3>6. Network Optimizations and Content Delivery</h3>
52-
<p><strong>Resource Hints:</strong> Use <code>&lt;link rel="preconnect"&gt;</code> for early connections to important third-party domains (like an API or CDN). Use <code>&lt;link rel="preload"&gt;</code> for critical resources (fonts, Hero images).</p>
53-
54-
<p><strong>SSR / SSG:</strong> For complex SPAs (Single Page Applications), generating markup on the server (Server-Side Rendering) or at build time (Static Site Generation) drastically speeds up the First Contentful Paint (FCP) and makes life easier for search engine bots.</p>
55-
56-
<h3>7. Profiling and Metrics</h3>
57-
<p><strong>Throttling:</strong> During local development on powerful hardware, the page will always "fly." Be sure to enable CPU and network throttling in Chrome DevTools (Performance tab) to see the real picture that users face on average smartphones.</p>
58-
59-
<p><strong>Core Web Vitals:</strong> Focus on Google's key metrics: LCP (Largest Contentful Paint - main content rendering speed), FID/INP (reaction delay to actions), and CLS (layout stability).</p>
1+
<h3>Critical Rendering Path</h3>
2+
<p>Rendering optimization means speeding up the <span class="accent">Critical Rendering Path</span> (DOM → CSSOM → Render Tree → Layout → Paint → Composite): the less work and blocking along the path, the sooner the user sees content.</p>
3+
4+
<p class="info"><strong>Key idea:</strong> fewer blockers on the critical path: a light DOM, critical CSS inlined, scripts with <code>defer</code>, heavy resources loaded lazily, and the effect measured with Core Web Vitals.</p>
5+
6+
<h3>Optimizing DOM (HTML)</h3>
7+
<ul>
8+
<li>Fewer nodes and less nesting: the bigger the tree, the more expensive every Layout (Lighthouse complains from ~800 nodes).</li>
9+
<li>Long lists — virtual scrolling; off-screen content — <code>content-visibility: auto</code>.</li>
10+
</ul>
11+
12+
<h3>Optimizing CSSOM (CSS)</h3>
13+
<ul>
14+
<li>CSS blocks rendering: inline the critical above-the-fold styles into <code>&lt;head&gt;</code>, load the rest asynchronously.</li>
15+
<li>Animate only <code>transform</code> and <code>opacity</code> — they skip Layout and Paint, running on the GPU (Composite).</li>
16+
</ul>
17+
18+
<h3>Optimizing JavaScript</h3>
19+
<ul>
20+
<li>JS blocks HTML parsing — external scripts with <code>defer</code>/<code>async</code>.</li>
21+
<li>Code Splitting + Lazy Loading: load code per route instead of the whole bundle at once.</li>
22+
<li>Heavy computations go to a Web Worker, keeping the main thread free.</li>
23+
</ul>
24+
25+
<h3>Media and fonts</h3>
26+
<ul>
27+
<li>WebP/AVIF formats and explicit <code>width</code>/<code>height</code> — protection against layout shifts (CLS).</li>
28+
<li><code>loading="lazy"</code> for images and iframes below the fold.</li>
29+
<li>Fonts: <code>font-display: swap</code> — text is immediately visible in a system font (no FOIT).</li>
30+
</ul>
31+
32+
<h3>Network and delivery</h3>
33+
<ul>
34+
<li>Resource Hints: <code>preconnect</code> to critical domains, <code>preload</code> for fonts and the hero image.</li>
35+
<li>Compression (Brotli), HTTP caching, CDN, HTTP/2+.</li>
36+
<li>SSR/SSG — ready-made markup from the server drastically speeds up FCP/LCP.</li>
37+
</ul>
38+
39+
<h3>Profiling and metrics</h3>
40+
<p>The benchmark is <span class="accent">Core Web Vitals</span>: <strong>LCP</strong> (main content paint), <strong>INP</strong> (responsiveness, replaced FID), <strong>CLS</strong> (layout stability). Tools: Lighthouse and the Performance panel in DevTools.</p>
41+
42+
<p class="info info--orange">A common mistake is optimizing "by eye" on a powerful dev machine: profile with CPU/network throttling and fix the most expensive thing, not the first one you spot.</p>
43+
44+
<p class="deep-dive">Deep Dive</p>
45+
46+
<h3>What optimized loading looks like</h3>
47+
<code class="code">
48+
&lt;head&gt;
49+
&lt;link rel="preconnect" href="https://cdn.example.com"&gt;
50+
&lt;style&gt;/* critical above-the-fold CSS */&lt;/style&gt;
51+
&lt;link rel="stylesheet" href="rest.css" media="print" onload="this.media='all'"&gt;
52+
&lt;script src="app.js" defer&gt;&lt;/script&gt;
53+
&lt;/head&gt;
54+
55+
&lt;!-- LCP element: high priority, no lazy --&gt;
56+
&lt;img src="hero.avif" width="800" height="400" fetchpriority="high" alt="..."&gt;
57+
&lt;!-- below the fold --&gt;
58+
&lt;img src="feed.webp" width="400" height="300" loading="lazy" alt="..."&gt;
59+
</code>
60+
<p>The <code>media="print"</code> trick downloads non-critical styles at low priority without blocking rendering, and <code>onload</code> switches them on. <code>fetchpriority="high"</code> raises the LCP image's priority in the network queue.</p>
61+
62+
<h3>Reflow, Repaint, and Layout Thrashing</h3>
63+
<p>Changing geometry (<code>width</code>, <code>top</code>, adding nodes) triggers Reflow; changing appearance (<code>color</code>, <code>box-shadow</code>) triggers Repaint. Reading layout properties (<code>offsetHeight</code>, <code>getBoundingClientRect()</code>) on a "dirty" tree forces the browser to recalculate Layout synchronously. Alternating reads and writes in a loop is <span class="accent">layout thrashing</span>: N forced reflows instead of one.</p>
64+
<ul>
65+
<li>Group operations: all reads first, then all writes; visual changes via <code>requestAnimationFrame</code>.</li>
66+
<li>Swap a whole class instead of a series of inline styles; batch insertions via <code>DocumentFragment</code>.</li>
67+
</ul>
68+
69+
<h3>Compositor layers and the GPU</h3>
70+
<p><code>will-change: transform</code> (or <code>translateZ(0)</code>) promotes an element to its own compositor layer: its movement is handled by the compositor on the GPU without touching Layout/Paint of the rest of the page.</p>
71+
<p class="info info--blue">Every layer consumes GPU memory. <code>will-change</code> is a targeted tool for genuinely animated elements, not a global "accelerator": sprinkled everywhere, it causes layer explosion and slows the page down.</p>
72+
73+
<h3>content-visibility: auto</h3>
74+
<p>Tells the browser to skip Layout and Paint of a block's contents until it nears the viewport; the content is rendered on the fly as you scroll. Unlike virtual scroll, the nodes stay in the DOM (Ctrl+F finds them, screen readers reach them) — only the rendering cost is cut, not the DOM itself. It fits a long page of heavy, heterogeneous sections (an article, a card feed), whereas virtualization suits thousands of uniform rows.</p>
75+
<p><code>contain-intrinsic-size</code> gives the block a placeholder height while it is unrendered — without it the scrollbar and layout jump (CLS) as sections render in.</p>
76+
<code class="code">
77+
.section {
78+
content-visibility: auto;
79+
contain-intrinsic-size: auto 500px; /* estimated height before render */
80+
}
81+
</code>
82+
<p class="info info--blue">The height estimate in <code>contain-intrinsic-size</code> is a trade-off: a large gap from the real height causes scroll jumps. The <code>auto</code> keyword asks the browser to remember the actual size after the first render and reuse it.</p>
83+
84+
<h3>Framework-level optimizations</h3>
85+
<ul>
86+
<li><strong>Angular:</strong> <code>ChangeDetectionStrategy.OnPush</code> and Signals — change checks only where data actually changed; <code>trackBy</code> in lists; <code>@defer</code> for deferred template blocks.</li>
87+
<li><strong>Vue:</strong> <code>v-once</code>/<code>v-memo</code> for static template chunks, <code>shallowRef</code> for large structures without deep reactivity.</li>
88+
<li>The common principle is narrowing the re-render zone: list virtualization, memoizing computations, splitting heavy components.</li>
89+
</ul>
90+
91+
<h3>Fonts in detail</h3>
92+
<ul>
93+
<li>WOFF2 only, subsetting via <code>unicode-range</code> (don't load Cyrillic on an English-only page and vice versa).</li>
94+
<li><code>&lt;link rel="preload" as="font"&gt;</code> for the above-the-fold font + self-hosting instead of third-party CDNs.</li>
95+
<li>Tuning the fallback font via <code>size-adjust</code>/<code>ascent-override</code> removes CLS during the font swap.</li>
96+
</ul>
97+
98+
<h3>Delivery: details</h3>
99+
<ul>
100+
<li>HTTP/2 multiplexes requests over a single connection; HTTP/3 (QUIC) speeds up the handshake and resilience on mobile networks.</li>
101+
<li>Brotli compresses text ~15–20% better than gzip.</li>
102+
<li>Caching: hashes in bundle names + long <code>Cache-Control: immutable</code>; a Service Worker for instant repeat visits.</li>
103+
<li>103 Early Hints: the server sends preload/preconnect hints before the HTML is even generated.</li>
104+
</ul>
105+
106+
<h3>Metrics: thresholds and practice</h3>
107+
<ul>
108+
<li>"Green" thresholds: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1 — at the 75th percentile of real users.</li>
109+
<li>INP replaced FID (2024): FID measured only the first input's delay, INP — the worst interaction of the whole visit.</li>
110+
<li>Lab data (Lighthouse, DevTools) is for debugging; field data (RUM, CrUX) is the source of truth about real users.</li>
111+
</ul>

‎src/assets/content/eng/questions.ts‎

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -38,7 +38,8 @@ export const questions = [
3838
tags: [
3939
'markup',
4040
'CSS',
41-
'browser'
41+
'browser',
42+
'Performance'
4243
],
4344
category: 'Markup',
4445
level: QuestionLevels.middle,

0 commit comments

Comments
 (0)