Bạn có nhận thấy một số trang web của mình mất hơn 10 giây để tải không? Bạn không đơn độc. Các trang web tải chậm là nguyên nhân chính dẫn đến tỷ lệ thoát trang cao, gây ảnh hưởng tiêu cực đến trải nghiệm người dùng và hiệu suất SEO. Công cụ hiện đại và các kỹ thuật truyền thống đôi khi lại chính là thủ phạm. May mắn thay, với một chút kiến thức chuyên sâu và chiến lược thông minh, bạn hoàn toàn có thể khắc phục vấn đề phổ biến này một cách dễ dàng, biến tốc độ tải trang thành lợi thế cạnh tranh vượt trội.
Mục tiêu chung của bạn nên là xây dựng các trang web nhẹ, tránh tạo ra nhiều yêu cầu mạng không cần thiết trong quá trình tải trang ban đầu, và tập trung vào việc hiển thị nội dung cho người dùng càng nhanh càng tốt. Trang bị cho mình những kỹ thuật tiên tiến dưới đây và hạn chế sử dụng các công cụ, framework hay thư viện làm tăng kích thước trang một cách không cần thiết. Cách tiếp cận độc đáo, ưu tiên hiệu suất này sẽ giúp website của bạn nổi bật so với đối thủ trong ngành công nghệ thông tin.
Tránh Các Framework Cồng Kềnh
Bàn tay chạm vào biểu tượng kỹ thuật và thiết kế tinh gọn (lean engineering & design) trong phát triển phần mềm, minh họa cho việc tránh các framework cồng kềnh và tối ưu hiệu suất.
Trong một bài viết trước đó về lời khuyên cho nhà phát triển web mới bắt đầu, chúng tôi đã gợi ý rằng người mới nên tránh các framework vì chúng khó học. Tuy nhiên, một lý do khác quan trọng không kém là chúng tiêu tốn nhiều tài nguyên khi chạy. Hầu hết các framework hiện nay đều “phát minh lại bánh xe” bằng cách ủy quyền rất nhiều công việc cho JavaScript, điều này thường không tối ưu về hiệu suất.
Chiến lược của bạn nên tập trung vào việc tạo ra một trang web tinh gọn và nhanh chóng, do đó, việc lựa chọn một framework có thể là không phù hợp. Các giá trị cốt lõi mà một framework mang lại thường là khả năng xây dựng ứng dụng trang đơn (Single-Page Applications – SPA), tổ chức mã nguồn tốt hơn và được cho là cập nhật DOM hiệu quả hơn. Hai giá trị đầu tiên còn gây tranh cãi, và giá trị thứ ba chỉ đúng trong một số trường hợp nhất định.
Đối với các dự án nhỏ hơn, tập trung hơn, chúng tôi khuyến nghị sử dụng Web Components. Chúng không chỉ tinh gọn hơn mà còn có tính bền vững cao: rất lâu sau khi các framework như React, Angular và Vue không còn phổ biến, Web Components vẫn sẽ tiếp tục hoạt động vì chúng là một phần của tiêu chuẩn W3C. Framework Lit (từ Google) là một lớp wrapper nhẹ xung quanh Web Components và đang cho thấy tiềm năng rất lớn; nó giúp xử lý một số đoạn mã boilerplate (mã lặp lại, tẻ nhạt) một cách hiệu quả.
Vì vậy, nếu có thể, hãy tránh các framework nặng. Phần lớn các lời khuyên dưới đây giả định rằng bạn không sử dụng chúng. Tuy nhiên, nếu bạn vẫn chọn sử dụng một framework (như React), một số kỹ thuật có thể không áp dụng trực tiếp, nhưng chúng vẫn là những nguyên tắc cơ bản quan trọng.
Tối Thiểu Hóa và Tối Ưu Hóa Các Thư Viện Phụ Thuộc (Dependencies)
Khi trang web tải lần đầu, các yêu cầu mạng để tải về các thư viện phụ thuộc (dependencies) là một trong những nguyên nhân chính gây ra hiệu suất kém. Chúng tôi cố gắng hết sức để tránh các thư viện phụ thuộc bằng mọi giá, đặc biệt là các thư viện hỗ trợ như Lodash hoặc Ramda. Thật không may, điều này có nghĩa là bạn phải tự triển khai các giải pháp tùy chỉnh cho một số tác vụ.
Ví dụ, đã có lần chúng tôi cần một event bus đơn giản, một lớp đóng vai trò kênh giao tiếp được chia sẻ trong mã nguồn của mình. Một giải pháp phổ biến là thư viện RxJS, nhưng thay vì thêm nó như một thư viện phụ thuộc có kích thước 17.7 kB (đã nén), chúng tôi đã tự viết một lớp chỉ nặng 200 byte. Điều này chỉ giúp tiết kiệm khoảng 100 ms thời gian tải ban đầu, nhưng tất cả những tiết kiệm nhỏ này sẽ cộng dồn lại.
Phương pháp truyền thống để viết mã cho trình duyệt liên quan đến quá trình đóng gói (bundling). Quy trình này yêu cầu bạn viết mã bằng Node.js và sử dụng một công cụ như webpack để chuyển đổi nó thành định dạng mà trình duyệt có thể sử dụng. Kết quả là một khối mã lớn chứa tất cả mọi thứ, và thường thì kích thước này có thể lên tới hơn 100 KB. Các kỹ thuật sau đó đã phát triển để giải quyết vấn đề này, chẳng hạn như chia tách mã (code-splitting), phân chia mã thành các khối nhỏ hơn; sau đó framework hoặc trình duyệt sẽ chỉ tải chúng khi cần. Một kỹ thuật khác là loại bỏ mã chết (tree-shaking), phân tích mã để chỉ trích xuất những gì cần thiết; ESM cũng có cơ chế hoạt động tương tự.
ESM (ECMAScript Modules) là hệ thống module JavaScript hiện đại và là tiêu chuẩn mới để nhập các thư viện. Đây là một ví dụ về ESM:
<script type="module"> const {foo} from "https://example.com/all-the-things.js"</script>Ví dụ trên sẽ tải module mong muốn và bất kỳ module nào khác mà nó phụ thuộc. Đây là cách ESM hoạt động và có một số điểm tương đồng mơ hồ với tree-shaking.
ESM không phải là một giải pháp toàn diện và chắc chắn có những hạn chế. Mặc dù chúng tôi khuyến nghị bạn nên sử dụng nó, chúng tôi vẫn giữ vững lời khuyên ban đầu về việc tự viết các giải pháp tối thiểu của riêng mình (nếu có thể) – điều này có nghĩa là bạn sẽ tránh được một cây phụ thuộc cồng kềnh cho các thư viện bên thứ ba. Nếu mất chưa đến 30 phút để viết, vậy tại sao không?
Một hạn chế của ESM là nếu một module phụ thuộc vào nhiều module khác, trình duyệt phải tải tất cả chúng – tập hợp này được gọi là cây phụ thuộc (dependency tree). Ví dụ, việc nhập hàm capitalize từ Lodash yêu cầu tải nhiều tệp bổ sung:
<script type="module"> import capitalize from 'https://cdn.jsdelivr.net/npm/[email protected]/capitalize.js'; alert(capitalize("hello world!"))</script>Bạn có thể thấy rằng việc sử dụng Lodash để viết hoa chữ cái đầu tiên của một từ sẽ tạo ra 23 yêu cầu và mất 4.4 giây trên kết nối GPRS (20 KB/s); trong khi trên kết nối 100 Mb, nó vẫn mất 2.2 giây. Nếu tốc độ kết nối nhanh hơn 5000 lần mà chỉ cho kết quả tải nhanh hơn 2 lần, điều đó cho thấy băng thông không phải là vấn đề chính.
Trong ảnh minh họa, phần được đánh dấu 1 cho thấy trình duyệt tải các yêu cầu theo kiểu thác nước (cascades requests), chỉ tải mã mà nó cần (tương tự như tree-shaking). Trình duyệt tải từng tệp, kiểm tra các phần nhập (dependencies) của nó, và sau đó tải các phần đó. Kết nối sử dụng HTTP/2, hoạt động nhanh hơn đáng kể so với HTTP/1 trong một số kịch bản. Điều này là do HTTP/2 duy trì một kết nối duy nhất, liên tục, trong khi trong một số trường hợp, HTTP/1 dựa vào nhiều kết nối riêng biệt, mỗi kết nối đều phát sinh chi phí đàm phán. Bây giờ hãy tưởng tượng một trình duyệt cũ tải trang web này và nó sử dụng HTTP/1 để tải từng module.
Để viết hoa chữ cái đầu tiên của một câu, chỉ cần rất ít mã:
function capitalize(str) { return str.charAt(0).toUpperCase() + str.slice(1);}Hãy ưu tiên triển khai giải pháp tùy chỉnh nếu nó dễ dàng; điều này giữ cho mã nguồn nhẹ và tập trung vào mục tiêu của bạn. Ngoài ra, hãy hiểu rằng các lệnh nhập (imports) rất tốn kém khi sử dụng ESM, và bạn nên suy nghĩ cẩn thận về cách bạn phân chia mã nguồn của mình; hãy cố gắng giảm thiểu sự phụ thuộc giữa các module. Đồng thời, việc đóng gói (bundling) vẫn là một cách rất hiệu quả để giảm thiểu số lượng yêu cầu mà trình duyệt tạo ra. Có rất nhiều điều cần cân nhắc, vì vậy hãy dành thời gian cho vấn đề này.
Bài học rút ra ở đây là hãy sử dụng các thư viện phụ thuộc một cách tiết kiệm. Các framework là một thư viện phụ thuộc khổng lồ, và các thư viện khác cũng là một gánh nặng tiềm ẩn. Mục tiêu là sự tinh gọn và tốc độ, và độ trễ mạng sẽ làm giảm hiệu suất của bạn.
Tận Dụng Thuộc Tính Defer và Async Cho Thẻ Script
Cả defer và async đều là các thuộc tính bạn có thể sử dụng trên thẻ script để thay đổi cách chúng hoạt động. Cả hai đều ảnh hưởng đến hiệu suất, nhưng chúng hoạt động hơi khác nhau, và có những trường hợp sử dụng rõ ràng cho từng loại.
Loại trừ defer, async và ESM ra khỏi phạm vi thảo luận hiện tại, hãy lưu ý rằng tất cả các thẻ script bình thường đều được tải xuống song song với nhau nhưng thực thi trước khi trình phân tích cú pháp HTML hoàn tất. Đây là cách thẻ script thường hoạt động.
Biểu đồ minh họa cơ chế tải script song song và chặn parser của thẻ script HTML thông thường, với một script có độ trễ 2000ms và một script không có độ trễ.
Sử dụng một máy chủ web tùy chỉnh, chúng tôi đã cố tình đặt độ trễ tải xuống cho script 1 và 2. Đối với chú thích 5, hãy lưu ý rằng cả hai script đều bắt đầu tải xuống gần như cùng một lúc, và script có độ trễ 2000 ms bắt đầu trước. Nếu quá trình tải xuống không diễn ra song song, script dài hơn (2000 ms) sẽ chặn script kia tải xuống cho đến khi nó hoàn tất.
Nhìn vào chú thích 4, bạn cũng có thể thấy rằng HTML (chú thích 3) chỉ được phân tích cú pháp sau khi tất cả các script đã hoàn tất. Điều này cho thấy rằng các script chặn trình phân tích cú pháp HTML trong khi chúng đang được tải xuống và thực thi.
Thuộc tính Defer
Thuộc tính defer trên thẻ script chỉ dẫn trình duyệt trì hoãn việc thực thi script cho đến khi nó đã hiển thị xong HTML. Điều này rất quan trọng, vì chúng ta không muốn chặn việc hiển thị nội dung trang ban đầu trong khi chờ đợi mã JavaScript nặng tải xuống và thực thi. Cũng cần lưu ý rằng các script được defer sẽ thực thi theo thứ tự chúng xuất hiện trong HTML.
<html> <head> <script src="/js/foo.js" defer></script> </head> <p>I render before the script.</p></html>ESM cũng được defer theo mặc định.
Một script được defer sẽ chạy sau khi HTML được tải đầy đủ, vì vậy bạn có thể truy cập DOM một cách an toàn. Nếu bạn cần chạy mã sau khi tất cả các script được defer đã hoàn tất, hãy sử dụng sự kiện DOMContentLoaded – nó kích hoạt khi HTML đã được phân tích cú pháp và tất cả các script được defer đã chạy:
// /js/foo.js
document.addEventListener("DOMContentLoaded", () => {
console.log("The DOM is fully loaded!")
})Tuy nhiên, DOMContentLoaded không chờ hình ảnh, script async hoặc iframe tải xong. Các script được defer cũng chờ cho đến khi trình duyệt tải xuống và phân tích cú pháp tất cả các stylesheet, điều này khác với hành vi của thẻ script thông thường.
Có rất nhiều điều cần nhớ, nhưng tóm lại: một script được defer sẽ chờ trình render HTML và các stylesheet hoàn tất trước. Để đảm bảo 100% rằng trang đã sẵn sàng, hãy lắng nghe sự kiện DOMContentLoaded.
Thuộc tính Async
Thuộc tính async chỉ dẫn trình duyệt tải script trong khi vẫn phân tích cú pháp HTML. Script có thể chạy bất kỳ lúc nào. Script và trình phân tích cú pháp HTML không chờ đợi nhau, nhưng script có thể tạm thời ngắt trình phân tích cú pháp HTML nếu cần thiết. Nó giống như sự kết hợp giữa script bình thường và script được defer.
Tóm Tắt Khác Biệt Giữa Các Loại Script
- Script được
defer(và ESM): Tải xuống ngay lập tức và thực thi sau khi trình phân tích cú pháp HTML và các stylesheet hoàn tất. - Script
async: Tải xuống ngay lập tức và thực thi bất cứ khi nào, có thể tạm thời ngắt trình phân tích cú pháp HTML. - Script bình thường: Tải xuống ngay lập tức và thực thi trước khi trình phân tích cú pháp HTML.
Hình ảnh sau đây cho thấy dòng thời gian cho từng loại script, chỉ ra khi chúng được tải xuống và thực thi so với trình phân tích cú pháp HTML:
Bảng so sánh trực quan về thời điểm tải (fetch), thực thi (execution) và tác động lên HTML parser của các loại thẻ script: normal, defer, và async.
Hãy sử dụng script async cho các script bên thứ ba độc lập như quảng cáo – những script không tương tác với phần còn lại của trang. Sử dụng script defer càng nhiều càng tốt. Việc sử dụng script được defer sẽ rất quan trọng trong phần tiếp theo, thảo luận về Critical CSS.
Ưu Tiên Inline Critical CSS (CSS Quan Trọng)
Khi một trang web hiển thị ban đầu, chúng ta gọi các kiểu hiển thị trên màn hình là “above the fold” (phần trên màn hình) và các kiểu bên dưới màn hình là “below the fold” (phần dưới màn hình). Critical CSS tập trung vào việc hiển thị các kiểu “above the fold” nhanh nhất có thể để tạo ấn tượng cho người dùng về một trang web tải nhanh và tránh làm họ mất kiên nhẫn. Điều này quan trọng vì người dùng càng chờ đợi trang tải lâu, khả năng họ rời đi càng cao.
Để hiển thị nội dung “above the fold” nhanh nhất có thể, chúng ta cần chia các kiểu của mình thành hai gói, một cho nội dung “above the fold” và một cho nội dung “below the fold”. Để đạt được điều này, đơn giản là bạn cần phân tích thủ công những kiểu nào áp dụng cho từng phần – cho cả máy tính để bàn và thiết bị di động.
Để chia các kiểu của bạn thành hai gói, ví dụ cơ bản nhất trông như thế này:
<html><html lang="en"><p><head> <script src="below-the-fold.js" defer></script> <style> /* Critical CSS. */ </style></head></p><p><body> <aside>Above the fold.</aside></p><p> <main> <p>Below the fold.</p> </main></p><p> <link rel="stylesheet" type="text/css" href="below-the-fold.css"></body></p><p></html></p>Để dễ đọc hơn, ví dụ trên chưa hoàn chỉnh; một ví dụ trong thế giới thực trông như thế này:
Mã HTML và hiển thị trang web minh họa cách triển khai Critical CSS, với các phần nội dung 'above the fold' và 'below the fold' được đánh dấu.
Thẻ style trong phần 1 chứa Critical CSS, nên chứa các kiểu “above the fold”. Trong ví dụ của chúng ta, thẻ aside (phần 6) chứa tất cả nội dung “above the fold”. Nếu bạn muốn tạo kiểu cho nó, hãy chỉnh sửa phần 1.
Khi trang hiển thị ban đầu, nội dung “below the fold” sẽ không có kiểu, vì vậy nó sẽ nhấp nháy nhanh, hiển thị nội dung không được tạo kiểu – đây được gọi là hiện tượng FOUC (Flash of Unstyled Content – nhấp nháy nội dung không kiểu). Để khắc phục điều này, chúng tôi ẩn nội dung bằng opacity: 0 (phần 1). Khi JavaScript (phần 4) thực thi, nó sẽ thay đổi opacity này thành 1. Sẽ có hiệu ứng chuyển tiếp mềm mại, vì vậy nó sẽ xuất hiện đẹp mắt.
Bởi vì các stylesheet trong phần <head> chặn trình render HTML, thay vào đó chúng ta tải CSS không quan trọng (non-critical CSS) gần cuối phần <body> (phần 3) sau khi tất cả HTML khác đã được render. Về cơ bản, trình duyệt sẽ render HTML trước và sau đó tải stylesheet ở cuối <body>, trước khi nó thực thi script được defer.
Chúng ta sử dụng script được defer vì nó thực thi sau khi tất cả HTML đã render xong và một khi tất cả các stylesheet đã được tải xuống và áp dụng.
Quá trình trông như thế này:
- Trình duyệt yêu cầu HTML.
- Trình duyệt bắt đầu phân tích cú pháp tài liệu.
- Trình duyệt tải JavaScript trong nền và chuyển sang bước tiếp theo ngay lập tức (phần 5).
- Trình duyệt phân tích cú pháp các kiểu inline (phần 1).
- Trình duyệt render thẻ
aside, là phần “above the fold” (phần 6). - Trình duyệt render nội dung chính (phần 2), là phần “below the fold” và có
opacity: 0, nhờ vào Critical CSS (phần 1). - Trình duyệt tải CSS không quan trọng (phần 3).
- Trình duyệt hoàn tất phân tích cú pháp HTML và các kiểu, sau đó kích hoạt sự kiện
DOMContentLoaded. - JavaScript kích hoạt để làm cho nội dung “below the fold” hiển thị (chú thích 4).
Tóm lại: Trình duyệt hoạt động xuống đến CSS ở cuối tài liệu, render tất cả HTML và làm cho nội dung “below the fold” không hiển thị. Khi quá trình đó hoàn tất, JavaScript sẽ kích hoạt để làm cho nội dung “below the fold” hiển thị.
Nói tóm lại: Hãy render phần “above the fold” thật nhanh và ẩn mọi thứ khác cho đến khi chúng sẵn sàng.
Hãy dành thời gian để hiểu sâu sắc những gì đã được trình bày ở đây và xây dựng dựa trên đó. Chúng tôi gợi ý rằng bạn nên bỏ qua các khuyến nghị điển hình về React, Angular và hàng nghìn thư viện phụ thuộc. Thay vào đó, bạn nên:
- Kiểm tra kỹ các thư viện phụ thuộc của bạn và giữ chúng ở mức tối thiểu. Ít yêu cầu hơn đồng nghĩa với tải trang nhanh hơn.
- Hiểu cách thẻ script hoạt động, thời điểm chúng tải và cách tránh chặn trình phân tích cú pháp HTML.
- Hiểu khi nào các stylesheet tải – cả trong
<head>và<body>– và sau đó hiểu liệu chúng có chặn trình render HTML hay không. - Render HTML hiển thị càng nhanh càng tốt; tải mọi thứ khác theo đúng thời điểm.
Nếu bạn muốn áp dụng những gì mình vừa học nhưng cần một số tài nguyên để trợ giúp, hãy xem các hướng dẫn khác của chúng tôi về tối ưu hiệu suất hoặc các công cụ hữu ích dành cho nhà phát triển web. Hãy bắt tay vào hành động ngay để biến website của bạn thành một tài sản công nghệ tốc độ cao!
