Đừng bảo agent tối ưu web

Đừng bảo agent tối ưu web

Performance audit không nên kết thúc ở một báo cáo đỏ lòm. Nó nên kết thúc bằng một prompt có cấu trúc để agent sửa đúng chỗ.

“Make this site faster.”

Nếu câu này từng xuất hiện trong prompt của bạn gửi cho Cursor, Claude Code, GitHub Copilot hay một coding agent tương tự, mình xin rót thêm cà phê: bạn không cô đơn. Team nào làm frontend một thời gian cũng có ngày mở Lighthouse, thấy vài ô đỏ, rồi quăng cả đống screenshot cho AI với niềm tin mong manh rằng nó sẽ tự biết sửa.

Niềm tin phổ biến là: agent càng xịn thì prompt càng có thể lười.

Mình nghĩ ngược lại. Với performance, agent giỏi không thay thế được phần handoff giữa công cụ đo và codebase. Nếu audit là hải đăng báo chỗ nguy hiểm, prompt chính là hải trình đưa agent tới đúng vùng cần sửa. Thiếu hải trình, nó vẫn đi, nhưng dễ vòng quanh bến cả buổi.

Luận điểm của bài này: đừng biến performance report thành lời than phiền; hãy biến nó thành một fix prompt có contract rõ ràng.

Sơ đồ minh họa cho bài Đừng bảo agent tối ưu web

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu không phải là “nhanh hơn”, mà là “sửa được”

Performance tools rất giỏi chỉ ra vấn đề: Largest Contentful Paint cao, JavaScript bundle phình, ảnh chưa cần đã tải, main thread bị nghẽn. Nhưng chúng thường dừng lại ở câu: đây là thứ đang chậm.

Developer lại cần câu tiếp theo: agent nên nhìn file nào, nghi ngờ nguyên nhân gì, sửa trong phạm vi nào, và kiểm chứng ra sao?

Ở đây có một điểm nhiều team hiểu sai. Báo cáo performance không tự động là context tốt cho AI.

context window — vùng ngữ cảnh model còn xử lý được trong một lượt — không nên bị nhồi bằng mọi log, mọi screenshot, mọi đoạn HTML. Bài về RAG context nhỏ nhắc một ý đáng giữ: context lớn hơn chỉ làm hệ thống dễ thở hơn, không thay thế được context management. Với coding agent cũng vậy. Bạn đưa càng nhiều thứ không lọc, agent càng có cơ hội bám vào chi tiết phụ.

Nói thẳng ra thì: prompt tốt cho performance fix không phải prompt dài; nó là prompt biết cắt bỏ phần không cần.

Checklist: một finding đủ tốt cần có gì?

Trước khi viết extension hay automation, hãy định nghĩa finding — một bản ghi có cấu trúc về vấn đề audit. Đây là mỏ neo của toàn bộ quy trình.

Một finding nên có tối thiểu:

Ví dụ cụ thể:

{
  "metric": "LCP",
  "observed": "4.2s",
  "resource": "/images/hero.jpg",
  "likelyCause": "hero image is not preloaded and may be too large",
  "inspectFirst": ["src/app/page.tsx", "src/components/Hero.tsx"],
  "constraints": ["keep visual layout", "avoid new image CDN dependency"],
  "verify": "rerun performance audit on the same page and compare LCP"
}

Điểm quan trọng: likelyCause chỉ là giả thuyết. Nếu bạn ghi như chân lý, agent có thể sửa theo hướng sai mà vẫn rất tự tin. Đây là dạng hallucination — bịa hoặc khẳng định sai nhưng nhìn có vẻ hợp lý — trong workflow coding.

Playbook một buổi: biến audit thành prompt sửa code

Bạn không cần xây cả performance engine. Làm một luồng nhỏ trước đã.

Bước 1: chọn một loại finding duy nhất

Đừng ôm hết Core Web Vitals ngay ngày đầu. Chọn một case dễ xác minh, ví dụ LCP do ảnh hero hoặc JavaScript bundle lớn.

Mục tiêu là chứng minh pipeline:

performance finding -> structured prompt -> code patch -> verification

Nếu team bạn đang dùng Chrome DevTools, Lighthouse, WebPageTest, hay tool nội bộ, cứ bắt đầu từ output bạn đang có. Nguồn chính dùng ví dụ DevTools extension có nút Copy AI fix prompt, nhưng pattern quan trọng hơn tool.

Bước 2: viết prompt template như một contract

prompt contract ở đây nghĩa là khung giao việc cố định để agent không phải đoán.

You are fixing a frontend performance issue.

Metric: {{metric}}
Observed value: {{observed}}
Affected resource: {{resource}}
Likely cause: {{likelyCause}}
Inspect these files first: {{inspectFirst}}

Constraints:
{{constraints}}

Task:
1. Explain the likely fix in 3-5 bullets.
2. Make the smallest safe code change.
3. Do not rewrite unrelated components.
4. Add a short verification note.

Verification:
{{verify}}

Bạn có thể dịch sang tiếng Việt nếu team thích, nhưng với codebase và tool tiếng Anh, giữ prompt tiếng Anh thường ít lệch nghĩa hơn.

Bước 3: gắn nút copy vào nơi developer đang đứng

Đây là chỗ DevTools extension đáng giá. Không phải vì extension làm AI thông minh hơn, mà vì nó đặt prompt ngay cạnh dữ liệu đo.

Nếu chưa muốn viết extension, làm phiên bản nghèo mà hiệu quả:

Ví dụ:

type Finding = {
  metric: string;
  observed: string;
  resource: string;
  likelyCause: string;
  inspectFirst: string[];
  constraints: string[];
  verify: string;
};

function buildFixPrompt(f: Finding) {
  return `You are fixing a frontend performance issue.

Metric: ${f.metric}
Observed value: ${f.observed}
Affected resource: ${f.resource}
Likely cause: ${f.likelyCause}
Inspect these files first: ${f.inspectFirst.join(", ")}

Constraints:
${f.constraints.map(c => `- ${c}`).join("\n")}

Task:
1. Explain the likely fix in 3-5 bullets.
2. Make the smallest safe code change.
3. Do not rewrite unrelated components.
4. Add a short verification note.

Verification:
${f.verify}`;
}

Bước 4: bắt agent trả về patch nhỏ

Đừng yêu cầu “optimize toàn trang”. Hãy yêu cầu một patch có phạm vi hẹp.

Hình dung thế này: nếu finding nói ảnh hero làm LCP tệ, agent nên kiểm tra component hero, cách load ảnh, kích thước ảnh, preload, priority, chứ không nên refactor toàn bộ layout. Một con tàu đang lệch hướng vài độ thì chỉnh bánh lái, không tháo cả thân tàu giữa biển.

Prompt nên có câu:

Prefer the smallest change that directly addresses the finding.
If the finding is insufficient, ask for the missing data instead of guessing.

Câu thứ hai rất đáng tiền. Nó cho agent quyền dừng lại khi context thiếu, thay vì bịa hướng sửa.

Bước 5: verification phải là một phần của prompt

Nếu prompt chỉ yêu cầu sửa, agent sẽ tối ưu cho việc tạo diff. Nếu prompt yêu cầu kiểm chứng, agent sẽ để lại dấu vết vận hành tốt hơn.

Verification không cần phức tạp ngay:

Đây là verification loop — vòng kiểm chứng sau thay đổi. Nó biến AI patch từ “trông có vẻ đúng” thành “có cơ hội được tin”.

Ba bẫy làm agent sửa performance sai hướng

Bẫy 1: đưa metric mà không đưa resource.
“LCP chậm” là thông tin thiếu. “LCP chậm, element nghi ngờ là ảnh hero /images/hero.jpg” mới đủ để agent bắt đầu.

Bẫy 2: đưa quá nhiều context không phân cấp.
Đừng paste nguyên báo cáo dài nếu chỉ cần một finding. Nếu cần nhiều lớp, hãy tóm tắt theo thứ tự: summary → finding → raw evidence. Cách này giống bài RAG context nhỏ: cho model phần tinh trước, phần thô sau.

Bẫy 3: quên ràng buộc sản phẩm.
Agent có thể đề xuất bỏ animation, lazy-load thứ không nên lazy-load, hoặc gỡ script quan trọng. Với team thật, performance không được thắng bằng cách làm hỏng tracking, SEO, accessibility hay visual design.

Nếu là mình, mình sẽ triển khai thế này

Với một team Việt Nam khoảng 3-8 developer, mình sẽ không bắt đầu bằng extension đầy đủ. Mình sẽ đi theo 3 tầng:

| Tầng | Cách làm | Khi nào đủ dùng |
|---|---|---|
| Manual | JSON finding + script tạo prompt | Team mới thử workflow |
| Semi-automated | Button copy trong internal tool hoặc DevTools panel | Có nhiều audit lặp lại |
| Integrated | CI tạo finding và gợi ý prompt cho PR | Performance đã thành quy trình release |

Điểm quyết định không phải tool nào đẹp hơn. Điểm quyết định là finding của bạn có đủ cấu trúc để agent không đoán mò không.

Bài nguồn về DevTools extension đưa ra một hướng hay: đặt nút Copy AI fix prompt ngay trong panel. Nhưng nếu bạn đang ở giai đoạn early, đừng đóng tàu chiến khi chỉ cần một chiếc thuyền đủ qua sông. Hãy chứng minh prompt contract trước, rồi mới tự động hóa.

Sau bài này, mình muốn bạn đổi một suy nghĩ: AI performance workflow không bắt đầu từ agent; nó bắt đầu từ cách bạn đóng gói bằng chứng cho agent.

Tối ưu web bằng AI không phải hét “nhanh lên” vào màn hình. Nó là ghi tọa độ rõ ràng, đưa đúng bản đồ, rồi kiểm tra xem tàu có thật sự cập bến chưa.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo