14 thg 8, 2025·8 phút
Tiếp cận trình biên dịch cho hiệu năng web: Góc nhìn của Rich Harris
Một cái nhìn thực tế về cách tiếp cận dựa trên trình biên dịch cho hiệu năng web, so sánh với framework nặng runtime và một khung quyết định đơn giản.
Một cái nhìn thực tế về cách tiếp cận dựa trên trình biên dịch cho hiệu năng web, so sánh với framework nặng runtime và một khung quyết định đơn giản.
Người dùng hiếm khi mô tả hiệu năng bằng thuật ngữ kỹ thuật. Họ nói app cảm thấy nặng. Trang mất một nhịp quá lâu để hiện nội dung, nút bấm phản hồi chậm, và những hành động đơn giản như mở menu, gõ trong ô tìm kiếm, hoặc chuyển tab bị giật.
Các triệu chứng quen thuộc: tải lần đầu chậm (giao diện trống hoặc hiển thị chưa hoàn chỉnh), tương tác giật (click đáp sau một khoảng dừng, cuộn rung), và vòng xoay chờ dài sau các hành động lẽ ra phải tức thì, như lưu form hay lọc danh sách.
Phần lớn là chi phí runtime. Nói thẳng ra, đó là công việc trình duyệt phải làm sau khi trang tải xong để app có thể dùng được: tải thêm JavaScript, phân tích, chạy, dựng UI, gán handler, và tiếp tục làm thêm ở mỗi lần cập nhật. Ngay cả trên thiết bị nhanh, có giới hạn về lượng JavaScript có thể đẩy qua trình duyệt trước khi trải nghiệm bắt đầu trì trệ.
Vấn đề hiệu năng cũng thường xuất hiện muộn. Ban đầu app nhỏ: vài màn, dữ liệu nhẹ, UI đơn giản. Rồi sản phẩm phát triển. Marketing thêm tracker, design thêm component phong phú hơn, các nhóm thêm state, tính năng, dependency và cá nhân hoá. Mỗi thay đổi có vẻ vô hại riêng lẻ, nhưng tổng khối lượng công việc cộng lại.
Đó là lý do các đội bắt đầu chú ý đến ý tưởng ưu tiên trình biên dịch (compiler-first). Mục tiêu thường không phải điểm tuyệt đối. Mà là tiếp tục phát hành mà app không bị chậm hơn theo từng tháng.
Hầu hết framework frontend giúp bạn làm hai việc: xây app, và giữ UI đồng bộ với dữ liệu. Khác biệt chính là phần thứ hai xảy ra khi nào.
Với framework nặng runtime, nhiều công việc xảy ra trong trình duyệt sau khi trang tải. Bạn gửi một runtime đa năng có thể xử lý nhiều trường hợp: theo dõi thay đổi, quyết định cái gì cần cập nhật, và áp dụng các cập nhật đó. Tính linh hoạt đó tiện cho phát triển, nhưng thường có nghĩa là nhiều JavaScript cần tải, phân tích và chạy trước khi UI sẵn sàng.
Với tối ưu hoá thời gian biên dịch, nhiều công việc đó chuyển vào bước build. Thay vì gửi trình duyệt một bộ quy tắc chung, công cụ build phân tích component và sinh mã cụ thể cho app.
Một mô hình tư duy hữu ích:
Hầu hết sản phẩm thật sự nằm ở giữa. Cách tiếp cận ưu tiên trình biên dịch vẫn gửi một số mã runtime (routing, fetch dữ liệu, animation, xử lý lỗi). Framework nặng runtime cũng dùng kỹ thuật thời gian build (minification, code splitting, server rendering) để giảm việc phải làm ở client. Câu hỏi thực dụng không phải trại nào đúng, mà là tổ hợp nào phù hợp với sản phẩm của bạn.
Rich Harris là một trong những tiếng nói rõ ràng ủng hộ tư duy frontend ưu tiên trình biên dịch. Lập luận của ông đơn giản: làm nhiều việc trước để người dùng tải ít mã hơn và trình duyệt làm ít việc hơn.
Động lực là thực tế. Nhiều framework nặng runtime gửi một engine đa năng: logic component, reactivity, diffing, scheduling và helper phải hoạt động cho mọi app. Tính linh hoạt đó tốn bytes và CPU. Ngay cả khi UI nhỏ, bạn vẫn có thể trả chi phí cho runtime lớn.
Cách tiếp cận trình biên dịch lật ngược mô hình. Trong thời gian build, trình biên dịch nhìn vào component thực tế và sinh ra mã cập nhật DOM cụ thể mà chúng cần. Nếu một nhãn không bao giờ thay đổi, nó trở thành HTML thuần. Nếu chỉ một giá trị thay đổi, chỉ đường cập nhật cho giá trị đó được xuất ra. Thay vì gửi một cỗ máy UI chung, bạn gửi đầu ra được tối ưu cho sản phẩm.
Kết quả thường đơn giản: ít mã framework gửi tới người dùng hơn, và ít công việc phải làm ở mỗi tương tác. Nó cũng tỏ ra hữu dụng nhất trên thiết bị cấu hình thấp, nơi chi phí runtime phụ nhanh chóng hiển thị.
Những đánh đổi vẫn quan trọng:
Quy tắc thực tế: nếu UI của bạn phần lớn biết trước được khi build, compiler có thể sinh ra đầu ra chặt chẽ. Nếu UI rất động hoặc dựa trên plugin, runtime nặng sẽ dễ hơn.
Tối ưu thời gian build thay đổi chỗ xảy ra công việc. Nhiều quyết định được đưa ra khi build, và ít công việc bị bỏ lại cho trình duyệt.
Một kết quả thấy rõ là ít JavaScript được gửi hơn. Bundle nhỏ giảm thời gian mạng, thời gian phân tích và độ trễ trước khi trang có thể phản hồi một tap hay click. Trên điện thoại tầm trung, điều đó quan trọng hơn nhiều đội nghĩ.
Trình biên dịch cũng có thể sinh ra các cập nhật DOM trực tiếp hơn. Khi bước build thấy được cấu trúc component, nó có thể sản sinh mã cập nhật chỉ chạm tới các node DOM thực sự thay đổi, không qua nhiều lớp trừu tượng ở mỗi tương tác. Điều này làm các cập nhật thường xuyên mượt hơn, đặc biệt với danh sách, bảng và form.
Phân tích khi build cũng tăng hiệu quả tree-shaking và loại bỏ mã chết. Lợi ích không chỉ là file nhỏ hơn—mà là ít đường code mà trình duyệt phải tải và chạy.
Hydration là một khu vực khác nơi lựa chọn khi build giúp được. Hydration là bước biến trang render phía server thành tương tác bằng cách gán handler và phục hồi state. Nếu bước build có thể đánh dấu phần nào cần tương tác, bạn có thể giảm công việc tải đầu.
Ngoài ra, compilation thường cải thiện scoping CSS. Build có thể viết lại tên class, loại bỏ style không dùng và giảm rò rỉ style giữa component. Điều đó hạ chi phí bất ngờ khi UI mở rộng.
Hãy tưởng tượng một dashboard với bộ lọc và bảng dữ liệu lớn. Cách tiếp cận compiler-first có thể giữ tải ban đầu nhẹ, chỉ cập nhật các ô thay đổi sau khi click lọc, và tránh hydrate những phần không bao giờ tương tác.
Runtime lớn không đồng nghĩa xấu. Nó thường mang lại tính linh hoạt: patterns quyết định khi runtime, nhiều component bên thứ ba, và workflow đã được thử nghiệm qua năm tháng.
Framework nặng runtime tỏa sáng khi quy tắc UI thay đổi thường xuyên. Nếu bạn cần routing phức tạp, layout lồng nhau, form phong phú và mô hình state sâu, một runtime trưởng thành có thể giống như một tấm lưới an toàn.
Runtime hữu ích khi bạn muốn framework xử lý nhiều việc trong lúc app chạy, không chỉ khi build. Điều đó có thể giúp đội nhanh hơn hằng ngày, dù thêm chi phí.
Những lợi ích thường gặp: hệ sinh thái lớn, patterns quen thuộc cho state và fetch dữ liệu, dev tools mạnh, mở rộng theo kiểu plugin dễ hơn và onboarding mượt khi tuyển người từ pool chung.
Sự quen thuộc của đội là một chi phí thực sự và là lợi ích thực sự. Một framework hơi chậm hơn mà đội bạn có thể deploy tự tin có thể thắng một cách tiếp cận nhanh hơn nhưng cần đào tạo lại, kỷ luật chặt hơn hoặc tooling tuỳ chỉnh để tránh lỗi.
Nhiều phàn nàn “app chậm” không phải do runtime framework gây ra. Nếu trang đang chờ API chậm, ảnh nặng, quá nhiều font, hoặc script bên thứ ba, đổi framework sẽ không sửa được vấn đề cốt lõi.
Dashboard nội bộ phía sau login thường vẫn ổn dù runtime lớn, vì người dùng dùng thiết bị mạnh và công việc bị chi phối bởi bảng, phân quyền và truy vấn backend.
“Đủ nhanh” có thể là mục tiêu đúng lúc ban đầu. Nếu bạn còn chứng minh giá trị sản phẩm, giữ tốc độ lặp cao, đặt ngân sách cơ bản và chỉ áp dụng phức tạp compiler-first khi có bằng chứng là nó quan trọng.
Tốc độ lặp là thời gian để nhận phản hồi: bao lâu để ai đó thay đổi màn, chạy, thấy lỗi và sửa. Các đội giữ vòng lặp này ngắn phát hành nhiều hơn và học nhanh hơn. Đó là lý do framework nặng runtime có thể cảm thấy năng suất ban đầu: patterns quen, kết quả nhanh, nhiều hành vi built-in.
Công việc tối ưu hiệu năng làm chậm vòng lặp khi thực hiện quá sớm hoặc quá rộng. Nếu mỗi pull request biến thành tranh luận vi mô về tối ưu, đội sẽ ngừng chấp nhận rủi ro. Nếu bạn xây pipeline phức tạp trước khi biết sản phẩm là gì, người ta sẽ tốn thời gian đấu tranh với tooling thay vì nói chuyện với người dùng.
Mẹo là đồng ý về điều “đủ tốt” và lặp trong hộp đó. Ngân sách hiệu năng cho bạn cái hộp đó. Không phải săn điểm hoàn hảo, mà là giới hạn bảo vệ trải nghiệm trong khi giữ nhịp phát triển.
Một ngân sách thực tế có thể gồm:
Nếu bạn bỏ qua hiệu năng, thường sẽ trả giá sau này. Khi sản phẩm lớn lên, chậm trở thành vấn đề kiến trúc, không chỉ vài tweak. Việc viết lại muộn có thể nghĩa là đóng băng tính năng, đào tạo lại đội và phá vỡ những workflow từng hoạt động.
Tooling compiler-first có thể dịch chuyển đánh đổi này. Bạn có thể chấp nhận build hơi lâu hơn, nhưng giảm khối công việc mà mỗi thiết bị, mỗi lượt truy cập phải làm.
Xem lại ngân sách khi sản phẩm chứng minh được giá trị. Ban đầu, bảo vệ những điều cơ bản. Khi traffic và doanh thu tăng, siết chặt ngân sách và đầu tư nơi các thay đổi ảnh hưởng tới các số đo thực, không phải cái tôi.
Tranh luận hiệu năng trở nên rối khi không ai đồng ý “nhanh” nghĩa là gì. Chọn vài chỉ số nhỏ, ghi chúng lại và coi như bảng điểm chung.
Một bộ khởi đầu đơn giản:
Đo trên thiết bị đại diện, không chỉ laptop dev. CPU mạnh, cache nóng và server local có thể che giấu độ trễ xuất hiện trên điện thoại tầm trung qua mạng di động trung bình.
Giữ cho thực tế: chọn hai hoặc ba thiết bị khớp người dùng thực và chạy cùng một luồng mỗi lần (màn hình chính, đăng nhập, một tác vụ phổ biến). Làm điều đó nhất quán.
Trước khi đổi framework, chụp baseline. Ghi lại build hiện tại, thu số liệu cho cùng các luồng và giữ chúng hiển thị. Baseline đó là ảnh “trước”.
Đừng đánh giá hiệu năng chỉ bằng một điểm lab. Công cụ lab hữu ích, nhưng có thể khen điều sai (tải đầu tốt) trong khi bỏ qua điều người dùng phàn nàn (menu giật, gõ chậm, độ trễ sau màn hình đầu tiên).
Khi số liệu xấu đi, đừng đoán. Kiểm tra những gì đã được phát hành, cái gì chặn render, và thời gian đi đâu: mạng, JavaScript hay API.
Để đưa ra lựa chọn bình tĩnh, có thể lặp lại, hãy coi quyết định framework và rendering như quyết định sản phẩm. Mục tiêu không phải công nghệ hay nhất. Mà là cân bằng đúng giữa hiệu năng và nhịp độ đội cần.
Một thin slice nên bao gồm phần rắc rối: dữ liệu thực, auth, và màn hình chậm nhất.
Nếu muốn prototype thin slice nhanh, Koder.ai (koder.ai) cho phép bạn xây web, backend và luồng mobile qua chat, rồi xuất source. Điều đó giúp bạn thử một route thực tế sớm và giữ thử nghiệm có thể đảo lại bằng snapshot và rollback.
Ghi lại quyết định bằng ngôn ngữ giản dị, bao gồm điều gì sẽ khiến bạn xem lại (tăng traffic, tỷ lệ mobile, mục tiêu SEO). Điều đó làm lựa chọn bền vững khi đội thay đổi.
Các quyết định hiệu năng thường sai khi đội tối ưu những gì họ thấy hôm nay, không phải cảm nhận của người dùng sau ba tháng.
Một lỗi là tối ưu quá mức tuần đầu. Đội dành cả ngày để bớt mili-giây cho một trang vẫn thay đổi hàng ngày, trong khi vấn đề thực là người dùng chưa có tính năng đúng. Ban đầu, tăng tốc độ học hỏi đã hơn cả. Khóa công việc tối ưu sâu khi routes và component ổn định.
Một lỗi khác là phớt lờ tăng trưởng bundle cho tới khi nó gây hại. Mọi thứ ổn ở 200 KB, rồi vài “thêm nhỏ” sau đó bạn gửi megabyte. Thói quen đơn giản hữu ích: theo dõi kích thước bundle theo thời gian và coi nhảy vọt là bug.
Các đội cũng mặc định render chỉ client cho mọi thứ, dù vài route phần lớn tĩnh (trang giá, nội dung kiểu docs, bước onboarding). Những trang đó thường có thể giao tới thiết bị ít việc hơn.
Một hiểm họa thầm lặng là thêm thư viện UI lớn cho tiện lợi mà không đo chi phí trong build production. Tiện lợi có giá trị. Chỉ cần rõ bạn trả bao nhiêu cho JavaScript, CSS và tương tác chậm hơn trên điện thoại tầm trung.
Cuối cùng, pha trộn các cách tiếp cận mà không ranh giới rõ tạo app khó debug. Nếu một nửa app giả định cập nhật do compiler sinh trong khi nửa kia dựa vào phép màu runtime, bạn sẽ có quy tắc mơ hồ và lỗi khó hiểu.
Một vài nguyên tắc giữ ổn thật sự:
Tưởng tượng đội 3 người xây SaaS cho lịch và thanh toán. Nó có hai mặt: site marketing công khai (landing, pricing, docs) và dashboard đã auth (lịch, hóa đơn, báo cáo, cài đặt).
Với đường runtime-first, họ chọn setup runtime-heavy vì đổi UI nhanh. Dashboard trở thành app client-side lớn với component tái sử dụng, thư viện state và tương tác phong phú. Lặp nhanh. Theo thời gian, tải đầu bắt đầu nặng trên điện thoại tầm trung.
Với đường compiler-first, họ chọn framework đẩy nhiều việc về build để giảm JavaScript client. Các luồng phổ biến như mở dashboard, chuyển tab và tìm kiếm mượt hơn. Đổi lại, đội cần chặt chẽ hơn về pattern và tooling, và một số trick runtime không còn cắm vào dễ dàng.
Thay đổi hiếm khi do sở thích. Thường do áp lực thực tế: trang chậm làm giảm đăng ký, nhiều người dùng đến từ thiết bị yếu, khách doanh nghiệp yêu cầu ngân sách dự đoán, dashboard luôn mở và bộ nhớ quan trọng, hoặc ticket hỗ trợ ghi slowness trên mạng thực.
Phương án hybrid thường thắng. Giữ trang marketing nhẹ (server-rendered hoặc hầu như tĩnh, ít mã client) và chấp nhận runtime nặng hơn ở dashboard nơi tương tác mang lại giá trị.
Dùng bước quyết định: họ liệt kê hành trình quan trọng (signup, hóa đơn đầu tiên, báo cáo tuần), đo trên điện thoại tầm trung, đặt ngân sách và chọn hybrid. Compiler-first mặc định cho trang công khai và component chia sẻ, runtime-heavy chỉ dùng khi nó thực sự cải thiện tốc độ thử nghiệm.
Cách dễ nhất để hiện thực ý tưởng là vòng lặp hàng tuần ngắn.
Bắt đầu với scan 15 phút: kích thước bundle có tăng không, route nào cảm thấy chậm, thành phần UI lớn nhất trên các route đó là gì (bảng, chart, editor, map), và dependency nào đóng góp nhiều nhất. Rồi chọn một nút thắt bạn có thể sửa mà không viết lại toàn bộ stack.
Tuần này, giữ nhỏ:
Để giữ lựa chọn có thể đảo, vẽ ranh giới rõ ràng giữa routes và features. Ưu tiên module có thể thay thế sau (chart, rich text editor, SDK analytics) mà không đụng cả app.
Phần lớn không chỉ là mạng—đó là chi phí runtime: trình duyệt tải xuống, phân tích và chạy JavaScript, dựng UI và tiếp tục làm thêm công việc ở mỗi lần cập nhật.
Đó là lý do một app có thể cảm thấy “nặng” ngay cả trên laptop mạnh khi khối lượng JavaScript tăng lên.
Mục tiêu giống nhau (làm ít hơn ở phía client), nhưng cơ chế khác nhau.
Nó có nghĩa là framework phân tích các component của bạn khi build và xuất ra mã phù hợp với app, thay vì gửi một engine UI lớn và chung chung.
Lợi ích thực tế thường là bundle nhỏ hơn và ít CPU hơn khi tương tác (click, gõ, cuộn).
Bắt đầu với:
Đo trên các thiết bị đại diện cho người dùng thực, không chỉ laptop dev. Chọn cùng một luồng dùng mỗi lần để so sánh build.
Có thể có. Nếu nguyên nhân là API chậm, ảnh nặng, nhiều font, hoặc script bên thứ ba, đổi framework không loại bỏ được những nút thắt đó.
Hãy coi việc chọn framework là một trong nhiều đòn bẩy: trước tiên xác định thời gian tiêu ở đâu—mạng, CPU JavaScript, render hay backend.
Chọn runtime-heavy khi bạn cần linh hoạt và tốc độ lặp nhanh:
Nếu runtime không phải là nút cổ chai, tiện lợi có thể bù đắp bytes thừa.
Một mặc định đơn giản:
Hybrid thường tốt nhất nếu bạn ghi rõ ranh giới để tránh hỗn loạn giả định.
Ngân sách nên bảo vệ cảm nhận người dùng mà không chặn việc phát triển. Ví dụ:
Ngân sách là đường rào, không phải cuộc thi điểm số hoàn hảo.
Hydration là quá trình làm cho trang render phía server trở nên tương tác bằng cách gán event handlers và phục hồi đủ state trong trình duyệt.
Nếu bạn hydrate quá nhiều, lần tải đầu sẽ chậm mặc dù HTML xuất hiện nhanh. Công cụ build có thể giảm hydrate bằng cách đánh dấu những phần thật sự cần tương tác.
Một thin-slice tốt nên có những phần rối thực tế:
Khi prototype thin-slice, Koder.ai có thể giúp bạn xây web + backend qua chat và xuất source để đo và so sánh sớm mà không phải viết lại toàn bộ.