记一次 FastAPI Jinja 模板加载优化：干掉 12 个 display:none 的历史遗留 HTML 标签页

#074

1 min read · 208 words

目录

1. 问题背景
2. 故障现象
3. 运行环境
4. 尝试过但失败的方案
5. 最终解决方案
6. 相关代码
7. 验证结果
8. 当前状态
9. 避坑指南
10. Related ToolSignal Guides

如果你在 FastAPI Jinja 模板环境中，也遇到了因为历史包袱代码导致 Web 应用加载变慢的问题，本文或许能帮到你。这里分享一个安全剥离并归档那些“假装隐藏”的重度 HTML 模块、瞬间提升页面加载速度的实战方案。

问题背景

事情是这样的。老板下达了明确指示：“界面太乱了，把那些像玩具一样的图标都拿掉，再加一个说明书标签页。”我翻开自己负责的模块代码一看，webapp/templates/index.html 居然有 5,183 行。表面上虽然只显示了 4 个标签页，但实际上，自动驾驶、brain、auto-promo 等 13 个与老板意志背道而驰的历史遗留（legacy）模块，全都被用 display:none 悄悄藏在模板里。在资本主义社会，代码是干不过钱包的，违背老板意志的代码更不可能活下去。必须立刻动手清理。

故障现象

templates/index.html 文件本身过于臃肿，导致老板在加载预览页面时有肉眼可见的卡顿。开发者工具的 Network 标签页显示，瓶颈主要卡在 HTML 文档本身的下载和解析（Parsing）上。

运行环境

基于 FastAPI + Jinja 模板的 Web 应用，目标文件为 webapp/templates/index.html。

尝试过但失败的方案

起初为了稳妥起见，我打算沿用老路子，仅保持 display:none，只在 UI 上把链接断开。但这种做法治标不治本：不仅无法减小文件体积，后台运行的存量 JavaScript 依赖还会因为找不到对应的 DOM 交互而发生 silent fail（静默失败），在浏览器控制台里疯狂报错。虽然具体原因还有待深究，但目前看来，是因为即使 DOM 元素存在，异常的初始化脚本相互冲突导致了崩溃。显然，单纯的“隐藏”行不通。

最终解决方案

我决定快刀斩乱麻，把这 12 个历史遗留 Section 从 HTML 里彻底挖掉。手动删肯定会手抖误伤无辜标签，于是我写了个 Python 正则解析脚本。除了需要保留的 5 个核心标签页（tab-dashboard、tab-writer、tab-indexer、tab-help、tab-settings）外，将其余 12 个遗留 Section 的 HTML 完整提取出来，打包归档到 backups/ 目录下，然后从原 index.html 中一并抹去。

相关代码

import re

# 定义需要保留的 5 个核心标签页
KEEP = {'tab-dashboard', 'tab-writer', 'tab-indexer', 'tab-help', 'tab-settings'}

# 用于提取遗留 Section 的正则匹配规则
section_pat = re.compile(r"^<section id='(tab-[a-z-]+)' class='tab-pane[^']*'>", re.M)

# 遍历匹配到的 Section，将不在 KEEP 列表中的部分移至归档
for m in section_pat.finditer(content):
 if m.group(1) not in KEEP:
 archive.append(content[m.start():next_section.start()])

验证结果

瘦身效果立竿见影。index.html 的代码量从 5,183 行骤降至 2,798 行，实现了高达 49% 的代码瘦身。现在导航栏里只剩下清爽的 5 个可见标签页，老板预览页面的加载速度明显起飞。被剥离的遗留代码已被安全归档至 backups/sess142-webapp-refactor-20260523/legacy_sections_archive.html（大小 123KB），随时可以回滚复原。

↓

encoder L1 — self-attention

↓

encoder L2 — feed-forward

↓

encoder L3 — residual

↓

output (fix suggestion)