Static Resource Management and Template Framework for Front-End Optimization
The article discusses static resource management and a template framework to optimize front‑end performance by collecting resource requirements via require, widget, and script tags, deduplicating them, placing CSS in the head and JavaScript at the bottom, and enabling on‑demand loading while reducing HTTP requests.
Let’s review the remaining optimization principles from the previous table:
Optimization Direction – Optimization Method: • Request count – Merge scripts and stylesheets, split initial load. • Request bandwidth – Remove duplicate scripts. • Cache utilization – Make Ajax cacheable. • Page structure – Place stylesheets at the top, scripts at the bottom, and refresh document output early.
The remaining principles cannot be fully achieved with tools alone. Some may argue that a tool can merge scripts and stylesheets, but in large web applications this approach has serious drawbacks.
For example, a web product page has three resources A, B, and C. Engineers merged them to reduce HTTP requests, but later the product manager required module C to be loaded on demand. The merged resource makes C redundant, and removing it is risky, leading to performance degradation.
Offline static‑resource merging cannot solve on‑demand loading. It often causes resource redundancy and separates resource loading from usage, creating maintenance mismatches (code that uses a resource is removed while the reference remains). Therefore, industrial solutions must satisfy the following requirements:
Actually reduce HTTP requests (merge).
Reference resources where they are used (nearby dependency) and load only when needed (on‑demand).
Even if resource references are not centralized, the final references must appear in the page head (CSS) or footer (JS).
Avoid duplicate loading of resources (deduplication).
Pure front‑end techniques or tools struggle to meet these goals. Most large‑scale web pages are generated by server‑side dynamic languages using template engines (e.g., Smarty, Velocity) or directly with PHP, Python, etc. The following introduces a new template architecture that fulfills the above optimization principles.
Consider the following page code:
<html>
<head>
<title>hello world</title>
<link rel="stylesheet" type="text/css" href="A.css">
<link rel="stylesheet" type="text/css" href="B.css">
<link rel="stylesheet" type="text/css" href="C.css">
</head>
<body>
<div>html of A</div>
<div>html of B</div>
<div>html of C</div>
</body>
</html>To keep resource references close to their usage, the ideal source becomes:
<html>
<head>
<title>hello world</title>
</head>
<body>
<link rel="stylesheet" type="text/css" href="A.css"><div>html of A</div>
<link rel="stylesheet" type="text/css" href="B.css"><div>html of B</div>
<link rel="stylesheet" type="text/css" href="C.css"><div>html of C</div>
</body>
</html>However, delivering such a page directly would cause severe flash‑of‑content issues. We still want CSS in the head, so we introduce a placeholder and a template interface to collect resource requirements:
<html>
<head>
<title>hello world</title>
<!--[CSS LINKS PLACEHOLDER]-->
</head>
<body>
{require name="A.css"}<div>html of A</div>
{require name="B.css"}<div>html of B</div>
{require name="C.css"}<div>html of C</div>
</body>
</html>The placeholder is replaced at render time with the collected CSS links, while the require calls gather resource IDs into an array, deduplicate them, and output the final tags.
Three simple template interfaces are sufficient to implement the needed optimizations:
require(String id) : Collects a resource loading requirement.
widget(String template_id) : Loads a small component template (also known as load, component, or pagelet).
script(String code) : Collects inline JavaScript so it can be placed at the page bottom.
A refactored template page might look like this:
<html>
<head>
<title>hello world</title>
<!--[CSS LINKS PLACEHOLDER]-->
{require name="jquery.js"}
{require name="bootstrap.css"}
</head>
<body>
{require name="A/A.css"}{widget name="A/A.tpl"}
{script}console.log('A loaded'){/script}
{require name="B/B.css"}{widget name="B/B.tpl"}
{require name="C/C.css"}{widget name="C/C.tpl"}
<!--[SCRIPTS PLACEHOLDER]-->
</body>
</html>During template rendering, the system deduplicates resources, gathers scripts, replaces placeholders, and finally sends the following HTML to the client:
<html>
<head>
<title>hello world</title>
<link rel="stylesheet" type="text/css" href="bootstrap.css">
<link rel="stylesheet" type="text/css" href="A/A.css">
<link rel="stylesheet" type="text/css" href="B/B.css">
<link rel="stylesheet" type="text/css" href="C/C.css">
</head>
<body>
<div>html of A</div>
<div>html of B</div>
<div>html of C</div>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript">console.log('A loaded');</script>
</body>
</html>Thus the architecture achieves on‑demand loading, places scripts at the bottom, and keeps stylesheets in the head, satisfying the key performance‑optimization principles.
Baidu Tech Salon
Baidu Tech Salon, organized by Baidu's Technology Management Department, is a monthly offline event that shares cutting‑edge tech trends from Baidu and the industry, providing a free platform for mid‑to‑senior engineers to exchange ideas.
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.