실무에서 검증된 디자인, 개발, AI workflow 강의를 제공합니다.

# The Browser Rendering Pipeline
Turning HTML text into pixels on screen is called the rendering pipeline. This section walks through each stage and where performance costs appear.

## How does the browser draw HTML on screen?
The browser goes through roughly six stages. It parses HTML into the {tip:DOM}(Document Object Model, a tree representing document structure), parses CSS into the {tip:CSSOM}(CSS Object Model, a tree of style rules), then combines them into the render tree. Layout (position/size), paint (filling pixels), and {tip:compositing}(combining layers into the final frame) follow.

![Six rendering stages](ph:Parse → DOM·CSSOM → Render tree → Layout → Paint → Composite){size=large align=center caption="The six stages from HTML to pixels"}

> Note: these six stages do not run once and stop — some or all of them re-run every time the screen changes.

### How are the DOM and CSSOM built?
The HTML parser converts bytes → characters → tokens → nodes → DOM tree. The CSSOM is built similarly from CSS text. The two trees are built independently, but both are needed to form the render tree.

#### What happens when the parser hits a script?
By default a script tag blocks the parser (parser blocking). Because a script can mutate the DOM, the browser pauses HTML parsing until the script is downloaded and run. That is why script position and the `async`/`defer` attributes matter.

### How does the render tree differ from the DOM?
The render tree only includes nodes that are actually painted. So `display:none` elements and non-visual elements like head never enter the render tree.

# Reflow and Repaint
How much a screen change costs depends on which stages re-run.

## When does reflow happen?
{tip:Reflow}(recomputing element positions and sizes, also called layout. | Like re-measuring the whole room every time you move furniture — so it is expensive. | Repaint is the lighter “re-coloring” work for things like color and shadow.) happens when a change affects an element's size or position. Because the following paint and compositing also re-run, it is among the most expensive operations.

### Which properties trigger reflow?
Layout-affecting properties like `width`, `height`, `margin`, `top`, `left`, and font size trigger reflow. Reading values like `offsetTop` or `getBoundingClientRect()` can also force a synchronous reflow.

#### What is the performance difference between transform and top?
Changing `top` triggers reflow, but `transform: translate` skips layout and is handled only in compositing, so it is far cheaper. That is why `transform` and `opacity` are recommended for animation.

# Web Performance Metrics
Metrics that put a number on the performance users actually feel.

## What do Core Web Vitals measure?
{tip:LCP}(Largest Contentful Paint, when the largest content is painted), {tip:CLS}(Cumulative Layout Shift, unexpected layout movement), and {tip:INP}(Interaction to Next Paint, responsiveness) are the three core metrics.

### How do you improve LCP?
Make the largest content (usually a hero image or large text block) paint fast: optimize images, set priorities, and cut server response time.

#### Why specify width and height on images?
Specifying size lets the browser reserve space before load, preventing the layout shift that happens when the image arrives and pushes content below it.

The six stages from HTML to pixels — plus reflow, the critical rendering path, and Core Web Vitals — to build a clear mental model of web performance.

The Browser Rendering Pipeline, Explained

# Branching Basics
A branching strategy is the shared agreement that reduces conflicts and keeps deploys stable when many people edit the same codebase at once.

## Why not commit straight to main?
Because main should always stay deployable. Features are built on a separate {tip:branch}(an independent line of work split off at a point in time), reviewed, then merged.

### How small should a feature branch be?
Ideally small enough to hold one purpose and merge within a few days. The longer a branch lives, the further it drifts from main, raising conflict and review costs.

## How do merge and rebase differ?
Merge creates a new commit joining two histories; rebase moves your commits on top of main, rewriting history into a straight line. Merge is usually safer for shared branches.

### When should you avoid rebase?
Rebasing a branch already shared (pushed) with others rewrites history and causes conflicts for collaborators. So rebase is usually limited to local branches only you use.

Keeping main safe, the difference between merge and rebase, and the everyday habits that reduce conflicts — learned through questions.

Git Branching Basics for Teams

# The Structure of a Good Prompt
When you delegate work to an LLM, output quality often depends more on prompt design than on the model. Building a reviewable structure first is the key.

## What should you make explicit first?
Lock down three things first: role, goal, and output format. {tip:Role assignment}(a sentence giving the model a perspective or expertise, e.g. “You are a technical editor.”) sets tone and judgment, and stating the output format makes post-processing easy.

### Do examples really help?
Yes. One or two good examples ({tip:few-shot}(showing a few input→output pairs so the model learns the pattern)) convey format and tone more precisely than long explanations.

## What if answers keep getting verbose?
Constrain length and format with numbers. Stating “within 3 sentences” or “5 bullets” lets the model self-regulate its length.

### What is a more reliable way to enforce format?
Provide a JSON schema or template and insist “output only this format.” It is especially effective when you will parse the result downstream.

From role, goal, and output format to few-shot examples and length constraints — the prompt structure behind consistent LLM results.

Tutorials

The Browser Rendering Pipeline, Explained

Git Branching Basics for Teams

Fundamentals of Reviewable Prompt Design