Tìm hiểu trình quét tải trước của trình duyệt là gì, cách trình quét này giúp cải thiện hiệu suất và cách bạn có thể tránh can thiệp vào trình quét này.
Một khía cạnh thường bị bỏ qua khi tối ưu hoá tốc độ trang là hiểu biết một chút về cấu trúc nội bộ của trình duyệt. Trình duyệt thực hiện một số hoạt động tối ưu hoá nhất định để cải thiện hiệu suất theo cách mà chúng ta không thể làm với tư cách là nhà phát triển, nhưng chỉ khi những hoạt động tối ưu hoá đó không bị cản trở một cách vô tình.
Một tính năng tối ưu hoá trình duyệt nội bộ cần tìm hiểu là trình quét tải trước của trình duyệt. Bài đăng này sẽ trình bày cách hoạt động của trình quét tải trước và quan trọng hơn là cách bạn có thể tránh cản trở trình quét này.
Trình quét tải trước là gì?
Mỗi trình duyệt đều có một trình phân tích cú pháp HTML chính giúp mã hoá mã đánh dấu thô và xử lý mã đó thành mô hình đối tượng. Quá trình này diễn ra suôn sẻ cho đến khi trình phân tích cú pháp tạm dừng khi tìm thấy một tài nguyên chặn, chẳng hạn như một biểu định kiểu được tải bằng phần tử <link> hoặc tập lệnh được tải bằng phần tử <script> mà không có thuộc tính async hoặc defer.
<link> cho tệp CSS bên ngoài, khiến trình duyệt không thể phân tích cú pháp phần còn lại của tài liệu (hoặc thậm chí là không thể hiển thị bất kỳ phần nào của tài liệu) cho đến khi CSS được tải xuống và phân tích cú pháp.
Trong trường hợp tệp CSS, quá trình kết xuất sẽ bị chặn để ngăn nội dung không có kiểu hiển thị nhanh (FOUC), tức là khi người dùng có thể nhìn thấy nhanh phiên bản không có kiểu của một trang trước khi các kiểu được áp dụng cho trang đó.
Trình duyệt cũng chặn việc phân tích cú pháp và hiển thị trang khi gặp các phần tử <script> không có thuộc tính defer hoặc async.
Lý do là trình duyệt không thể biết chắc chắn liệu một tập lệnh nhất định có sửa đổi DOM hay không trong khi trình phân tích cú pháp HTML chính vẫn đang thực hiện công việc của mình. Đây là lý do tại sao bạn nên tải JavaScript ở cuối tài liệu để giảm thiểu ảnh hưởng của việc chặn phân tích cú pháp và kết xuất.
Đây là những lý do chính đáng khiến trình duyệt nên chặn cả quá trình phân tích cú pháp và kết xuất. Tuy nhiên, việc chặn một trong hai bước quan trọng này là không mong muốn, vì chúng có thể làm chậm quá trình hiển thị bằng cách trì hoãn việc khám phá các tài nguyên quan trọng khác. Rất may là các trình duyệt luôn cố gắng hết sức để giảm thiểu những vấn đề này bằng một trình phân tích cú pháp HTML phụ có tên là trình quét tải trước.
<body>, nhưng trình quét tải trước có thể xem trước trong mã đánh dấu thô để tìm tài nguyên hình ảnh đó và bắt đầu tải tài nguyên đó trước khi trình phân tích cú pháp HTML chính được bỏ chặn.
Vai trò của trình quét tải trước mang tính suy đoán, nghĩa là trình quét này kiểm tra mã đánh dấu thô để tìm tài nguyên nhằm tìm nạp một cách cơ hội trước khi trình phân tích cú pháp HTML chính phát hiện ra các tài nguyên đó.
Cách nhận biết khi trình quét tải trước đang hoạt động
Trình quét tải trước tồn tại vì quá trình kết xuất và phân tích cú pháp bị chặn. Nếu hai vấn đề về hiệu suất này không bao giờ tồn tại, thì trình quét tải trước sẽ không hữu ích lắm. Chìa khoá để xác định xem một trang web có hưởng lợi từ trình quét tải trước hay không phụ thuộc vào các hiện tượng chặn này. Để làm việc này, bạn có thể áp dụng độ trễ nhân tạo cho các yêu cầu để tìm ra vị trí mà trình quét tải trước đang hoạt động.
Hãy lấy trang này làm ví dụ về văn bản và hình ảnh cơ bản có biểu định kiểu. Vì các tệp CSS chặn cả quá trình hiển thị và phân tích cú pháp, nên bạn sẽ tạo ra độ trễ nhân tạo là 2 giây cho biểu định kiểu thông qua một dịch vụ proxy. Độ trễ này giúp bạn dễ dàng xem trong thác nước mạng nơi trình quét tải trước đang hoạt động.
Như bạn có thể thấy trong biểu đồ thác nước, trình quét tải trước phát hiện phần tử <img> ngay cả khi quá trình kết xuất và phân tích cú pháp tài liệu bị chặn. Nếu không có tính năng tối ưu hoá này, trình duyệt không thể tìm nạp nội dung một cách cơ hội trong khoảng thời gian chặn và nhiều yêu cầu tài nguyên sẽ liên tiếp thay vì đồng thời.
Sau khi xem qua ví dụ đơn giản đó, hãy cùng tìm hiểu một số mẫu thực tế mà trình quét tải trước có thể bị đánh bại và những việc có thể làm để khắc phục.
Đã chèn async tập lệnh
Giả sử bạn có HTML trong <head> bao gồm một số JavaScript cùng dòng như sau:
<script>
const scriptEl = document.createElement('script');
scriptEl.src = '/yall.min.js';
document.head.appendChild(scriptEl);
</script>
Tập lệnh được chèn là async theo mặc định, vì vậy, khi tập lệnh này được chèn, tập lệnh này sẽ hoạt động như thể thuộc tính async đã được áp dụng cho tập lệnh đó. Điều này có nghĩa là tập lệnh sẽ chạy sớm nhất có thể và không chặn quá trình kết xuất. Nghe có vẻ tối ưu, phải không? Tuy nhiên, nếu bạn cho rằng <script> cùng dòng này xuất hiện sau một phần tử <link> tải tệp CSS bên ngoài, thì bạn sẽ nhận được kết quả không tối ưu:
async được chèn. Trình quét tải trước không thể phát hiện tập lệnh trong giai đoạn chặn hiển thị vì tập lệnh được chèn vào ứng dụng.
Hãy cùng phân tích những gì đã xảy ra:
- Tại giây thứ 0, tài liệu chính được yêu cầu.
- Ở giây thứ 1,4, byte đầu tiên của yêu cầu điều hướng sẽ đến.
- Tại giây thứ 2, CSS và hình ảnh được yêu cầu.
- Vì trình phân tích cú pháp bị chặn tải biểu định kiểu và JavaScript cùng dòng chèn tập lệnh
asyncxuất hiện sau biểu định kiểu đó ở giây thứ 2,6, nên chức năng mà tập lệnh đó cung cấp không hoạt động ngay khi có thể.
Điều này không tối ưu vì yêu cầu cho tập lệnh chỉ xảy ra sau khi biểu định kiểu tải xuống xong. Điều này khiến tập lệnh bị trì hoãn chạy càng sớm càng tốt. Ngược lại, vì phần tử <img> có thể phát hiện được trong mã đánh dấu do máy chủ cung cấp, nên trình quét tải trước sẽ phát hiện được phần tử này.
Vậy điều gì sẽ xảy ra nếu bạn sử dụng thẻ <script> thông thường có thuộc tính async thay vì chèn tập lệnh vào DOM?
<script src="/yall.min.js" async></script>
Đây là kết quả:
async <script>. Trình quét tải trước sẽ phát hiện tập lệnh trong giai đoạn chặn hiển thị và tải tập lệnh đó đồng thời với CSS.
Có thể bạn sẽ muốn đề xuất rằng những vấn đề này có thể được khắc phục bằng cách sử dụng rel=preload. Cách này chắc chắn sẽ hiệu quả, nhưng có thể gây ra một số tác dụng phụ. Suy cho cùng, tại sao phải dùng rel=preload để khắc phục một vấn đề có thể tránh được bằng cách không chèn phần tử <script> vào DOM?
async được chèn, nhưng tập lệnh async được tải trước để đảm bảo tập lệnh này được phát hiện sớm hơn.
Tải trước "khắc phục" vấn đề ở đây, nhưng lại gây ra một vấn đề mới: tập lệnh async trong hai bản minh hoạ đầu tiên (mặc dù được tải trong <head>) được tải ở mức độ ưu tiên "Thấp", trong khi biểu định kiểu được tải ở mức độ ưu tiên "Cao nhất". Trong bản minh hoạ cuối cùng, nơi tập lệnh async được tải trước, biểu định kiểu vẫn được tải ở mức ưu tiên "Cao nhất", nhưng mức ưu tiên của tập lệnh đã được nâng lên thành "Cao".
Khi mức độ ưu tiên của tài nguyên được nâng lên, trình duyệt sẽ phân bổ thêm băng thông cho tài nguyên đó. Điều này có nghĩa là mặc dù biểu định kiểu có mức độ ưu tiên cao nhất, nhưng mức độ ưu tiên cao của tập lệnh có thể gây ra tranh chấp băng thông. Điều này có thể là một yếu tố ảnh hưởng đến các kết nối chậm hoặc trong trường hợp tài nguyên khá lớn.
Câu trả lời ở đây rất đơn giản: nếu cần một tập lệnh trong quá trình khởi động, đừng can thiệp vào trình quét tải trước bằng cách chèn tập lệnh đó vào DOM. Thử nghiệm khi cần với vị trí của phần tử <script>, cũng như với các thuộc tính như defer và async.
Tải chậm bằng JavaScript
Tải chậm là một phương pháp tuyệt vời để tiết kiệm dữ liệu, thường được áp dụng cho hình ảnh. Tuy nhiên, đôi khi tính năng tải chậm được áp dụng không chính xác cho những hình ảnh "trong màn hình đầu tiên".
Điều này gây ra các vấn đề tiềm ẩn về khả năng khám phá tài nguyên liên quan đến trình quét tải trước, đồng thời có thể làm chậm trễ không cần thiết thời gian khám phá tệp đối chiếu đến hình ảnh, tải xuống, giải mã và hiển thị hình ảnh đó. Hãy xem ví dụ về mã đánh dấu hình ảnh sau đây:
<img data-src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">
Việc sử dụng tiền tố data- là một mẫu phổ biến trong trình tải lười dựa trên JavaScript. Khi hình ảnh được cuộn vào khung nhìn, trình tải từng phần sẽ loại bỏ tiền tố data-, nghĩa là trong ví dụ trước, data-src sẽ trở thành src. Nội dung cập nhật này nhắc trình duyệt tìm nạp tài nguyên.
Mẫu này không có vấn đề gì cho đến khi được áp dụng cho các hình ảnh trong khung nhìn trong quá trình khởi động. Vì trình quét tải trước không đọc thuộc tính data-src theo cách giống như thuộc tính src (hoặc srcset), nên tham chiếu hình ảnh không được phát hiện sớm hơn. Tệ hơn nữa, hình ảnh sẽ bị trì hoãn tải cho đến sau khi JavaScript tải từng phần tải xuống, biên dịch và thực thi.
Tuỳ thuộc vào kích thước của hình ảnh (có thể phụ thuộc vào kích thước của khung nhìn), hình ảnh đó có thể là một phần tử đề xuất cho Nội dung lớn nhất hiển thị (LCP). Khi trình quét tải trước không thể tìm nạp trước tài nguyên hình ảnh (có thể là trong thời điểm (các) biểu định kiểu của trang chặn quá trình kết xuất), LCP sẽ bị ảnh hưởng.
Giải pháp là thay đổi mã đánh dấu hình ảnh:
<img src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">
Đây là mẫu tối ưu cho hình ảnh trong khung nhìn trong quá trình khởi động, vì trình quét tải trước sẽ khám phá và tìm nạp tài nguyên hình ảnh nhanh hơn.
Kết quả trong ví dụ đơn giản này là LCP được cải thiện 100 mili giây trên kết nối chậm. Đây có vẻ không phải là một điểm cải tiến lớn, nhưng thực ra là có nếu bạn cân nhắc rằng giải pháp này là một cách khắc phục mã đánh dấu nhanh chóng và hầu hết các trang web đều phức tạp hơn bộ ví dụ này. Điều này có nghĩa là các đề xuất LCP có thể phải tranh giành băng thông với nhiều tài nguyên khác, vì vậy, những hoạt động tối ưu hoá như thế này ngày càng trở nên quan trọng.
Hình nền CSS
Hãy nhớ rằng trình quét tải trước của trình duyệt sẽ quét mã đánh dấu. Googlebot không quét các loại tài nguyên khác, chẳng hạn như CSS có thể liên quan đến việc tìm nạp hình ảnh được tham chiếu bằng thuộc tính background-image.
Giống như HTML, trình duyệt xử lý CSS thành mô hình đối tượng riêng, được gọi là CSSOM. Nếu tài nguyên bên ngoài được phát hiện khi CSSOM được tạo, thì những tài nguyên đó sẽ được yêu cầu tại thời điểm phát hiện chứ không phải bằng trình quét tải trước.
Giả sử phần tử LCP tiềm năng của trang là một phần tử có thuộc tính CSS background-image. Sau đây là những gì xảy ra khi tài nguyên tải:
background-image (hàng 3). Hình ảnh mà nó yêu cầu sẽ không bắt đầu tìm nạp cho đến khi trình phân tích cú pháp CSS tìm thấy hình ảnh đó.
Trong trường hợp này, trình quét tải trước không bị ảnh hưởng nhiều vì không liên quan. Mặc dù vậy, nếu một đề xuất LCP trên trang là từ thuộc tính CSS background-image, thì bạn nên tải trước hình ảnh đó:
<!-- Make sure this is in the <head> below any
stylesheets, so as not to block them from loading -->
<link rel="preload" as="image" href="lcp-image.jpg">
Gợi ý rel=preload đó tuy nhỏ nhưng giúp trình duyệt khám phá hình ảnh sớm hơn so với bình thường:
background-image (hàng 3). Gợi ý rel=preload giúp trình duyệt khám phá hình ảnh sớm hơn khoảng 250 mili giây so với khi không có gợi ý.
Nhờ gợi ý rel=preload, ứng cử viên LCP được phát hiện sớm hơn, giúp giảm thời gian LCP. Mặc dù gợi ý đó giúp khắc phục vấn đề này, nhưng lựa chọn tốt hơn có thể là đánh giá xem ứng cử viên LCP hình ảnh của bạn có phải được tải từ CSS hay không. Với thẻ <img>, bạn sẽ có nhiều quyền kiểm soát hơn đối với việc tải hình ảnh phù hợp với khung nhìn, đồng thời cho phép trình quét tải trước khám phá hình ảnh đó.
Đưa quá nhiều tài nguyên vào cùng dòng
Nội tuyến là một phương pháp đặt tài nguyên bên trong HTML. Bạn có thể chèn biểu định kiểu cùng dòng trong phần tử <style>, tập lệnh trong phần tử <script> và hầu như mọi tài nguyên khác bằng cách sử dụng mã hoá base64.
Việc chèn tài nguyên cùng dòng có thể nhanh hơn việc tải tài nguyên xuống vì không có yêu cầu riêng nào được đưa ra cho tài nguyên đó. Nội dung này nằm ngay trong tài liệu và tải tức thì. Tuy nhiên, có một số nhược điểm đáng kể:
- Nếu bạn không lưu HTML vào bộ nhớ đệm (và bạn không thể làm vậy nếu phản hồi HTML là động), thì các tài nguyên cùng dòng sẽ không bao giờ được lưu vào bộ nhớ đệm. Điều này ảnh hưởng đến hiệu suất vì không thể sử dụng lại các tài nguyên cùng dòng.
- Ngay cả khi bạn có thể lưu HTML vào bộ nhớ đệm, tài nguyên cùng dòng cũng không được chia sẻ giữa các tài liệu. Điều này làm giảm hiệu quả lưu vào bộ nhớ đệm so với các tệp bên ngoài có thể được lưu vào bộ nhớ đệm và sử dụng lại trên toàn bộ nguồn gốc.
- Nếu chèn quá nhiều, bạn sẽ trì hoãn trình quét tải trước khám phá tài nguyên sau này trong tài liệu, vì việc tải nội dung bổ sung, được chèn nội tuyến đó xuống sẽ mất nhiều thời gian hơn.
Hãy lấy trang này làm ví dụ. Trong một số điều kiện nhất định, phần tử LCP đề xuất là hình ảnh ở đầu trang và CSS nằm trong một tệp riêng biệt được tải bằng phần tử <link>. Trang này cũng sử dụng 4 phông chữ web được yêu cầu dưới dạng các tệp riêng biệt từ tài nguyên CSS.
<img>, nhưng được trình quét tải trước phát hiện vì CSS và phông chữ cần thiết cho trang tải trong các tài nguyên riêng biệt, điều này không làm chậm trình quét tải trước thực hiện công việc của mình.
Bây giờ, điều gì sẽ xảy ra nếu CSS và tất cả phông chữ đều được chèn cùng dòng dưới dạng tài nguyên base64?
<img>, nhưng việc chèn nội dung CSS và 4 tài nguyên phông chữ của trang vào `` sẽ khiến trình quét tải trước trì hoãn việc khám phá hình ảnh cho đến khi các tài nguyên đó được tải xuống hoàn toàn.
Trong ví dụ này, việc chèn nội dung cùng dòng gây ra hậu quả tiêu cực cho LCP và hiệu suất nói chung. Phiên bản trang không cùng dòng bất kỳ nội dung nào sẽ hiển thị hình ảnh LCP trong khoảng 3,5 giây. Trang nội tuyến mọi thứ không hiển thị hình ảnh LCP cho đến khi chỉ hơn 7 giây.
Có nhiều yếu tố khác ngoài trình quét tải trước. Việc chèn phông chữ không phải là một chiến lược hay vì base64 là một định dạng không hiệu quả cho tài nguyên nhị phân. Một yếu tố khác là tài nguyên phông chữ bên ngoài sẽ không được tải xuống trừ phi CSSOM xác định là cần thiết. Khi các phông chữ đó được chèn dưới dạng base64, chúng sẽ được tải xuống cho dù có cần thiết cho trang hiện tại hay không.
Liệu việc tải trước có thể cải thiện mọi thứ ở đây không? Chắc chắn rồi. Bạn có thể tải trước hình ảnh LCP và giảm thời gian LCP, nhưng việc làm phình to HTML có thể không lưu vào bộ nhớ đệm bằng tài nguyên cùng dòng sẽ gây ra các hậu quả tiêu cực khác về hiệu suất. Nội dung đầu tiên hiển thị (FCP) cũng chịu ảnh hưởng của mẫu này. Trong phiên bản trang không có nội dung nào được chèn cùng dòng, FCP là khoảng 2,7 giây. Trong phiên bản mà mọi thứ đều được chèn cùng dòng, FCP là khoảng 5,8 giây.
Hãy hết sức cẩn thận khi chèn nội dung vào HTML, đặc biệt là các tài nguyên được mã hoá base64. Nói chung, bạn không nên làm như vậy, ngoại trừ trường hợp tài nguyên rất nhỏ. Chèn càng ít càng tốt, vì chèn quá nhiều là chơi với lửa.
Hiển thị mã đánh dấu bằng JavaScript phía máy khách
Không còn nghi ngờ gì nữa: JavaScript chắc chắn ảnh hưởng đến tốc độ trang. Nhà phát triển không chỉ phụ thuộc vào JavaScript để cung cấp tính tương tác, mà còn có xu hướng dựa vào JavaScript để phân phối nội dung. Điều này giúp cải thiện trải nghiệm của nhà phát triển theo một số cách, nhưng lợi ích cho nhà phát triển không phải lúc nào cũng mang lại lợi ích cho người dùng.
Một mẫu có thể đánh bại trình quét tải trước là hiển thị mã đánh dấu bằng JavaScript phía máy khách:
Khi tải trọng đánh dấu được chứa trong và hiển thị hoàn toàn bằng JavaScript trong trình duyệt, mọi tài nguyên trong mã đánh dấu đó sẽ không hiển thị với trình quét tải trước. Điều này làm chậm quá trình khám phá các tài nguyên quan trọng, chắc chắn sẽ ảnh hưởng đến LCP. Trong trường hợp của những ví dụ này, yêu cầu về hình ảnh LCP bị trì hoãn đáng kể so với trải nghiệm tương đương do máy chủ kết xuất mà không cần JavaScript xuất hiện.
Điều này hơi khác so với trọng tâm của bài viết này, nhưng ảnh hưởng của việc hiển thị mã đánh dấu trên máy khách vượt xa việc đánh bại trình quét tải trước. Thứ nhất, việc sử dụng JavaScript để hỗ trợ một trải nghiệm không cần đến JavaScript sẽ làm tăng thời gian xử lý không cần thiết, từ đó có thể ảnh hưởng đến Lượt tương tác đến nội dung hiển thị tiếp theo (INP). Việc kết xuất lượng mã đánh dấu cực lớn trên máy khách có nhiều khả năng tạo ra tác vụ cần nhiều thời gian hơn so với cùng một lượng mã đánh dấu do máy chủ gửi. Lý do cho việc này (ngoài quá trình xử lý bổ sung mà JavaScript liên quan) là các trình duyệt truyền trực tuyến mã đánh dấu từ máy chủ và phân chia quá trình kết xuất theo cách có xu hướng hạn chế các tác vụ cần nhiều thời gian. Mặt khác, mã đánh dấu do ứng dụng kết xuất được xử lý dưới dạng một tác vụ nguyên khối duy nhất, có thể ảnh hưởng đến INP của trang.
Biện pháp khắc phục cho trường hợp này phụ thuộc vào câu trả lời cho câu hỏi sau: Có lý do nào khiến máy chủ không thể cung cấp mã đánh dấu của trang thay vì hiển thị trên máy khách không? Nếu câu trả lời là "không", bạn nên cân nhắc sử dụng tính năng kết xuất phía máy chủ (SSR) hoặc mã đánh dấu được tạo tĩnh nếu có thể, vì tính năng này sẽ giúp trình quét tải trước khám phá và tìm nạp các tài nguyên quan trọng trước thời hạn.
Nếu trang của bạn cần JavaScript để đính kèm chức năng vào một số phần của mã đánh dấu trang, thì bạn vẫn có thể làm như vậy bằng SSR, bằng JavaScript thuần tuý hoặc hydration để tận dụng cả hai.
Giúp trình quét tải trước giúp bạn
Trình quét tải trước là một tính năng tối ưu hoá trình duyệt rất hiệu quả, giúp trang tải nhanh hơn trong quá trình khởi động. Bằng cách tránh các mẫu làm mất khả năng khám phá trước các tài nguyên quan trọng, bạn không chỉ giúp việc phát triển trở nên đơn giản hơn mà còn tạo ra trải nghiệm người dùng tốt hơn, mang lại kết quả tốt hơn trong nhiều chỉ số, bao gồm cả một số Web Vitals.
Tóm lại, sau đây là những điều bạn cần ghi nhớ trong bài đăng này:
- Trình quét tải trước của trình duyệt là một trình phân tích cú pháp HTML phụ, quét trước trình phân tích cú pháp chính nếu trình phân tích cú pháp chính bị chặn để tìm tài nguyên mà trình duyệt có thể tìm nạp sớm hơn.
- Trình quét tải trước không thể phát hiện các tài nguyên không có trong mã đánh dấu do máy chủ cung cấp trong yêu cầu điều hướng ban đầu. Sau đây là một số cách có thể khiến trình quét tải trước không hoạt động (nhưng không giới hạn ở):
- Chèn tài nguyên vào DOM bằng JavaScript, cho dù đó là tập lệnh, hình ảnh, biểu định kiểu hay bất kỳ nội dung nào khác, tốt hơn hết là nên nằm trong tải trọng đánh dấu ban đầu từ máy chủ.
- Tải chậm hình ảnh hoặc iframe trong màn hình đầu tiên bằng giải pháp JavaScript.
- Hiển thị mã đánh dấu trên ứng dụng có thể chứa thông tin tham chiếu đến tài nguyên phụ của tài liệu bằng JavaScript.
- Trình quét tải trước chỉ quét HTML. Trình quét trước không kiểm tra nội dung của các tài nguyên khác (đặc biệt là CSS) có thể chứa thông tin tham chiếu đến các thành phần quan trọng, bao gồm cả các đề xuất LCP.
Nếu vì lý do nào đó mà bạn không thể tránh được một mẫu ảnh hưởng tiêu cực đến khả năng tăng tốc hiệu suất tải của trình quét tải trước, hãy cân nhắc gợi ý tài nguyên rel=preload. Nếu bạn có sử dụng rel=preload, hãy kiểm thử trong các công cụ phòng thí nghiệm để đảm bảo rằng thuộc tính này mang lại hiệu quả như mong muốn. Cuối cùng, đừng tải trước quá nhiều tài nguyên, vì khi bạn ưu tiên mọi thứ, sẽ không có gì được ưu tiên.
Tài nguyên
- "Tập lệnh không đồng bộ" chèn vào tập lệnh được coi là có hại
- Cách trình tải trước của trình duyệt giúp trang tải nhanh hơn
- Tải trước các thành phần quan trọng để cải thiện tốc độ tải
- Thiết lập kết nối mạng sớm để cải thiện tốc độ trang mà người dùng cảm nhận được
- Tối ưu hoá Nội dung lớn nhất hiển thị