Total Blocking Time（简称TBT）是Chrome开发者工具Lighthouse面板里一项核心性能指标，它衡量的是页面加载过程中长任务超出50毫秒之外的部分总和。当你在浏览器端引入SQLite（通常是SQL.js或官方的SQLite WASM版本）做离线数据存储时，很容易遇到TBT爆表的情况：数据库文件加载、虚拟文件系统初始化、大批量INSERT，这些操作全都在主线程上执行，一跑就是几百毫秒甚至几秒，页面交互直接卡死。这篇文章就围绕一个真实项目中遇到的TBT问题，完整梳理排查思路和优化方案。
为什么浏览器里的SQLite会拖垮Total Blocking Time
先看问题的本质。TBT只统计主线程上的长任务，任何超过50毫米的同步任务都会贡献阻塞时间。而SQLite WASM在浏览器中运行时，有三个阶段特别容易产生长任务。
第一阶段是数据库文件加载。SQL.js默认使用内存模式的虚拟文件系统，你需要先把整个.db文件读进内存，再调用new SQL.Database(buffer)解析。一个几MB的数据库，解析过程在低端手机上可能耗时500毫秒以上，这段时间主线程完全无法响应点击和滚动。
第二阶段是大事务写入。很多人习惯把初始化数据一次性灌进去：
// 典型的错误写法：一个事务里塞了几万条数据
const db = new SQL.Database();
db.run("CREATE TABLE logs (id INTEGER PRIMARY KEY, msg TEXT)");
db.run("BEGIN TRANSACTION");
for (let i = 0; i < 50000; i++) {
db.run("INSERT INTO logs (msg) VALUES (?)", ["日志内容" + i]);
}
db.run("COMMIT");这段代码虽然用了事务，但整个循环是同步执行的，JavaScript主线程必须等它跑完才能处理其他任务，Lighthouse会把这一整段时间几乎全部计入TBT。
第三阶段是复杂查询。多表JOIN加上模糊搜索，在没有索引的情况下，查询耗时同样会转化为阻塞时间。理解了这三个来源，优化方向就清晰了：要么把工作搬离主线程，要么把长任务拆碎。
核心方案：用Web Worker彻底隔离数据库操作
最有效也最应该优先实施的方案，是把SQLite整体搬进Web Worker。Worker是独立线程，它内部执行多久都不会阻塞主线程，TBT直接归零（针对数据库部分）。架构上推荐做成一个数据库服务Worker，主线程通过消息通信访问。
// db-worker.js：数据库专用Worker
import initSqlJs from "sql.js";
let db = null;
self.onmessage = async (e) => {
const { type, payload, id } = e.data;
try {
if (type === "init") {
const SQL = await initSqlJs({
locateFile: (file) => `/wasm/${file}`
});
db = new SQL.Database(payload.buffer);
self.postMessage({ id, ok: true });
}
if (type === "exec") {
const stmt = db.prepare(payload.sql);
stmt.bind(payload.params);
const rows = [];
while (stmt.step()) rows.push(stmt.getAsObject());
stmt.free();
self.postMessage({ id, ok: true, data: rows });
}
} catch (err) {
self.postMessage({ id, ok: false, error: err.message });
}
};
// 主线程封装：Promise化的调用接口
const worker = new Worker("/db-worker.js");
let seq = 0;
const pending = new Map();
worker.onmessage = (e) => {
const { id, ok, data, error } = e.data;
const resolver = pending.get(id);
if (resolver) {
pending.delete(id);
ok ? resolver.resolve(data) : resolver.reject(new Error(error));
}
};
function call(type, payload) {
return new Promise((resolve, reject) => {
const id = ++seq;
pending.set(id, { resolve, reject });
worker.postMessage({ type, payload, id });
});
}
// 使用方式
const rows = await call("exec", {
sql: "SELECT * FROM logs WHERE msg LIKE ? LIMIT 50",
params: ["%关键词%"]
});这个改造有几个细节值得注意。第一，WASM文件的加载要放在Worker内部完成，不要在主线程预加载。第二，传输大结果集时建议配合Transferable对象，比如先把查询结果序列化成ArrayBuffer再transfer，避免结构化克隆带来的主线程开销。第三，如果用官方的SQLite WASM（sqlite.org提供的版本），它自带OPFS支持，可以直接用navigator.storage.getDirectory()做持久化，比手动导出.db文件优雅得多。
辅助优化：拆分任务与延迟初始化
即使搬进了Worker，启动阶段的TBT仍可能被其他环节拖累，比如Worker脚本本身的创建和WASM编译。这里可以用两个策略配合。
第一个策略是延迟初始化。不要在页面加载时就创建数据库，而是等到首次真正需要读写数据时再初始化，并给一个视觉上的过渡状态。实践中可以把初始化放到requestIdleCallback或者首屏渲染完成之后：
// 首屏渲染完成后再初始化数据库
window.addEventListener("load", () => {
const schedule = window.requestIdleCallback || ((cb) => setTimeout(cb, 800));
schedule(async () => {
const buffer = await fetch("/data/app.db").then((r) => r.arrayBuffer());
await call("init", { buffer });
console.log("数据库就绪");
});
});第二个策略是分批写入。对于必须批量导入的数据，按500到1000条一批拆开，每批之间用setTimeout或消息循环让出执行权。如果在Worker里，虽然不直接影响TBT，但分批能避免Worker长时间占用导致查询请求排队，提升交互响应的实时性。
此外别忘了数据库层面的基本功：给高频查询字段建索引、用EXPLAIN QUERY PLAN检查是否走了索引、避免SELECT全表返回。这些传统优化在WASM环境里同样有效，查询快了，阻塞自然就短了。
优化效果与选型建议
在笔者负责的项目中，优化前的Lighthouse移动端报告TBT约为1800毫秒，其中数据库初始化和首次数据导入占了大约1400毫秒。完成Worker隔离加延迟初始化后，TBT降到220毫秒左右，剩余部分来自框架渲染本身，数据库相关的阻塞基本清零。页面在低端安卓设备上的可交互时间从4秒缩短到1.5秒以内。
选型方面给三点建议。如果只是简单的键值存储，其实用IndexedDB或localStorage就够了，没必要为了技术情怀上SQLite；如果需要复杂的离线查询、多表关联和事务能力，SQLite WASM配合Web Worker是非常合理的组合；如果对持久化要求高，优先选官方SQLite WASM的OPFS方案，而不是SQL.js的手动导出模式，前者在数据可靠性和写入性能上都明显更好。性能优化没有银弹，但把重活挪出主线程这一条，永远是Web性能的第一原则。
SQLiteTotal Blocking TimeWASM修改时间：2026-09-09 05:54:35