From Code to Browser: Front‑End Development, Build, and Deployment
Front‑end development transforms a URL request into a rendered page by downloading HTML, CSS, and JavaScript, building the DOM and CSSOM, executing scripts, constructing a render tree, then performing layout and paint, while modern workflows use component frameworks, build tools for bundling and minification, versioned or hashed assets with long‑term CDN caching, and non‑overlapping gray‑release deployments to ensure smooth updates.
When a user enters a URL, the browser first requests the HTML entry file, parses it, builds the DOM, downloads and parses CSS to create a CSSOM, executes JavaScript which may modify the DOM or CSSOM, then constructs a render tree, performs layout (reflow) and paint – the steps known as the Critical Rendering Path (CRP).
The CRP can be summarised as:
Network download HTML → build DOM
Network download CSS → build CSSOM
Network download JS → parse & execute, possibly mutating DOM/CSSOM
When DOM & CSSOM are ready, construct Render Tree
Layout (re‑calculate element positions)
Paint pixels to the screen
Modern front‑end development no longer places all HTML, CSS, and JS in a single file. Instead, developers use component‑based frameworks such as React, Vue, or Angular, and CSS preprocessors like Sass or Less. Build tools (Webpack, Vite, Rollup) bundle modules, perform tree‑shaking, minification, and generate production‑ready assets.
Typical HTML entry example:
<!DOCTYPE html>
<html>
<head>
<title>Page Title</title>
<link rel="stylesheet" href="style.css">
<script src="app.js"></script>
</head>
<body>...</body>
</html>Example of module imports in a source file:
import '@/common/style.scss';
import arrowBack from '@/common/arrow-back.svg';
import { loadScript } from '@/common/utils.js';Production JavaScript is heavily minified and may look like:
!function(){"use strict";function t(t){if(null==t)return-1;var e=Number(t);return isNaN(e)?-1:Math.trunc(e)}/* … */}();Production CSS snippet:
.foo{background-color:red;}To force browsers to fetch updated resources, version numbers or hash‑based filenames are added to URLs:
<script src="https://cdn.example.com/build/foo.js?t=0.0.2" defer></script>
<link href="https://cdn.example.com/build/index.css?t=0.0.2" rel="stylesheet">Or using a content hash in the filename:
<link href="https://cdn.example.com/build/index_1i0gdg6ic.css" rel="stylesheet">Cache‑control headers are set to enable long‑term caching of static assets:
Cache-Control: max-age=2592000, s-maxage=86400When deploying, a non‑overlapping (gray‑release) strategy is recommended: first publish new static assets to a CDN without overwriting old ones, then gradually roll out the new HTML pages. This avoids situations where a page references resources that are not yet available, which can cause style breakage or JavaScript errors.
Key static‑resource optimisation steps include:
Configure very long cache expiry to maximise cache hits.
Use content hashes or versioned paths for precise cache invalidation.
Serve static files from a CDN close to users.
Adopt non‑overlapping releases for smooth upgrades.
DaTaobao Tech
Official account of DaTaobao Technology
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.