Tìm hiểu trình quét tải trước của trình duyệt là gì, tác dụng của trình quét này đối với hiệu suất và cách bạn có thể sử dụng trình quét này.
Một khía cạnh bị bỏ qua của việc tối ưu hoá tốc độ trang là việc biết một chút về bên trong trình duyệt. Các trình duyệt thực hiện một số biện pháp tối ưu hoá để cải thiện hiệu suất theo cách mà các nhà phát triển không làm được, nhưng chỉ miễn là các hoạt động tối ưu hoá đó không vô tình bị cản trở.
Một trong những cách tối ưu hoá nội bộ của trình duyệt là trình quét tải trước trình duyệt. Bài đăng này sẽ đề cập đến cách hoạt động của trình quét tải trước và quan trọng hơn là làm thế nào để bạn có thể tránh sử dụng 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 để mã hoá mã đánh dấu thô rồi xử lý mã đó thành mô hình đối tượng. Quá trình này sẽ diễn ra 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ư 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. Tệp này sẽ chặn trình duyệt 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à hiển thị bất kỳ phần tử nào trong đó) 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, cả phân tích cú pháp và hiển thị đều bị chặn để ngăn nhấp nháy nội dung chưa định kiểu (FOUC), đó là khi phiên bản chưa được định kiểu của trang có thể hiển thị trong thời gian ngắn trước khi áp dụng kiểu.
Trình duyệt cũng chặn hoạt động 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.
Nguyên nhân là do trình duyệt không thể biết chắc chắn liệu có tập lệnh cụ thể nào sẽ 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 người ta thường tải JavaScript của bạn vào cuối tài liệu để những ảnh hưởng của việc phân tích cú pháp bị chặn và hiển thị là không đáng kể.
Đây là những lý do chính đáng cho lý do trình duyệt nên chặn cả phân tích cú pháp và hiển thị. Tuy nhiên, bạn không nên chặn một trong hai bước quan trọng này vì chúng có thể giữ lại chương trình 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 sẽ nỗ lực hết sức để giảm thiểu những vấn đề này thông qua 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>. Tuy nhiên, trình quét tải trước có thể xem xét mã đánh dấu thô để tìm tài nguyên hình ảnh đó và bắt đầu tải 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à chức năng này kiểm tra thẻ đánh dấu thô để tìm tài nguyên có thể tìm nạp trước khi trình phân tích cú pháp HTML chính phát hiện ra chúng.
Cách nhận biết thời điểm trình quét tải trước đang hoạt động
Trình quét tải trước tồn tại do tính năng kết xuất và phân tích cú pháp bị chặn. Nếu 2 vấn đề về hiệu suất này chưa từng tồn tại, thì trình quét tải trước sẽ không hữu ích lắm. Chìa khóa để xác định xem một trang web có đượ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 điều đó, bạn có thể đưa ra độ trễ giả tạo cho các yêu cầu để tìm hiểu vị trí mà trình quét tải trước đang hoạt động.
Hãy lấy trang này chứa văn bản và hình ảnh cơ bản cùng với biểu định kiểu làm ví dụ. Do tệp CSS chặn cả hiển thị và phân tích cú pháp, bạn đưa vào độ trễ giả tạo 2 giây cho biểu định kiểu thông qua dịch vụ proxy. Độ trễ này giúp bạn dễ dàng xem thông tin 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 thác nước, trình quét tải trước phát hiện phần tử <img> ngay cả khi tính năng kết xuất hình ảnh 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 nhanh mọi thứ 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.
Với ví dụ về đồ chơi đó, hãy cùng xem một số mô hình thực tế mà trình quét tải trước có thể bị đánh bại và những gì có thể được thực hiện để khắc phục chúng.
Đã 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>
Các tập lệnh được chèn là async theo mặc định. Vì vậy, khi đượ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 đó có nghĩa là hoạt động này 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 cho rằng <script> cùng dòng này xuất hiện sau phần tử <link> tải tệp CSS bên ngoài, thì bạn sẽ nhận được kết quả dưới mức 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 này được chèn vào ứng dụng.
Hãy phân tích những gì đã xảy ra ở đây:
- Sau 0 giây, tài liệu chính được yêu cầu.
- Vào 1,4 giây, byte đầu tiên của yêu cầu điều hướng đến.
- Vào 2 giây, CSS và hình ảnh được yêu cầu.
- Vì trình phân tích cú pháp bị chặn trong việc tải biểu định kiểu và JavaScript cùng dòng chèn tập lệnh
asyncxuất hiện sau khi biểu định kiểu đó ở thời điểm 2,6 giây, nên chức năng mà tập lệnh cung cấp sẽ không có sẵn ngay khi có thể.
Điều này chưa 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 sẽ trì hoãn việc chạy tập lệnh sớm nhất có thể. Ngược lại, vì người dùng có thể tìm thấy phần tử <img> 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 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 với 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.
Bạn có thể nghĩ rằng cách khắc phục những vấn đề này bằng cách sử dụng rel=preload. Cách này chắc chắn sẽ mang lại hiệu quả, nhưng có thể phát sinh một số tác dụng phụ. Suy cho cùng, tại sao bạn nên sử 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.
Việc tải trước "khắc phục" vấn đề ở đây, nhưng nó 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>—nhưng đượ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 khi 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 tăng lên "Cao".
Khi mức độ ưu tiên của tài nguyên tăng lên, trình duyệt sẽ phân bổ nhiều băng thông hơn 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, mức độ ưu tiên cao hơn của tập lệnh có thể gây ra tranh chấp băng thông. Đó có thể là nguyên nhân làm 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 tập lệnh trong quá trình khởi động, đừng đánh bại trình quét tải trước bằng cách chèn tập lệnh đó vào DOM. Thử nghiệm với vị trí phần tử <script> cũng như các thuộc tính như defer và async nếu cần.
Tải từng phần bằng JavaScript
Tải từng phần là một phương pháp tuyệt vời để bảo toàn dữ liệu, thường được áp dụng cho hình ảnh. Tuy nhiên, đôi khi tính năng tải từng phần được áp dụng không chính xác cho hình ảnh nằm "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 phát hiện tài nguyên khi có liên quan đến trình quét tải trước và có thể trì hoãn thời gian cần thiết để phát hiện tham chiếu đến một hình ảnh, tải xuống, giải mã và hiển thị hình ảnh một cách không cần thiết. Hãy xem ví dụ về mã đánh dấu hình ảnh nà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 các trình tải từng phần 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ẽ xoá tiền tố data-, có nghĩa là trong ví dụ trước, data-src sẽ trở thành src. Bản cập nhật này sẽ 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 những 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 tương tự như thuộc tính src (hoặc srcset), nên hệ thống không thể phát hiện tham chiếu hình ảnh sớm hơn. Tồi tệ hơn, 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à 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 theo suy đoán — có thể là tại thời điểm hiển thị khối biểu định kiểu của trang — LCP 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ẽ phát hiện 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à sự cải thiện LCP 100 mili giây trên kết nối chậm. Điều này có vẻ không phải là một cải tiến lớn, nhưng đó là khi bạn cho rằng giải pháp này là một cách khắc phục nhanh chóng và hầu hết các trang web đều phức tạp hơn tập hợp ví dụ này. Điều đó có nghĩa là các ứng viên LCP có thể phải cạnh tranh về băng thông với nhiều tài nguyên khác, vì vậy, những biện pháp 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 duyệt tải trước, trình quét sẽ quét đánh dấu. Tính năng này 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 những hình ảnh được tham chiếu bởi thuộc tính background-image.
Giống như HTML, các trình duyệt xử lý CSS thành mô hình đối tượng riêng của nó, được gọi là CSSOM. Nếu hệ thống phát hiện thấy các tài nguyên bên ngoài trong quá trình tạo CSSOM, thì các tài nguyên đó sẽ được yêu cầu tại thời điểm khám phá chứ không phải bằng trình quét tải trước.
Giả sử đề xuất LCP của trang là một phần tử có thuộc tính CSS background-image. Dưới đây là những gì sẽ xảy ra khi tài nguyên tải:
background-image của CSS (hàng 3). Hình ảnh mà công cụ này 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ị thất bại vì không có liên quan. Mặc dù vậy, nếu một đề xuất LCP trên trang đến từ một thuộc tính CSS background-image, thì bạn vẫ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 phát hiện ra hình ảnh sớm hơn:
background-image của CSS (hàng 3). Gợi ý rel=preload giúp trình duyệt phát hiện hình ảnh sớm hơn khoảng 250 mili giây so với khi không có gợi ý.
Với gợi ý rel=preload, ứng viên LCP sẽ được phát hiện sớm hơn, làm giảm thời gian LCP. Mặc dù gợi ý đó có thể giúp khắc phục vấn đề này, nhưng tốt hơn là bạn nên đánh giá xem ứng viên LCP cho hình ảnh của bạn có được tải qua 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 một 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 tìm ra hình ảnh đó.
Cùng dòng quá nhiều tài nguyên
Cùng dòng là một phương pháp đặt tài nguyên bên trong HTML. Bạn có thể cùng dòng biểu định kiểu 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 phương thức mã hoá base64.
Tài nguyên cùng dòng có thể nhanh hơn so với việc tải chúng xuống vì không có yêu cầu riêng cho tài nguyên. Tệp này nằm ngay trong tài liệu và tải ngay lập tức. Tuy nhiên, có một số hạn chế đáng kể:
- Nếu bạn không lưu vào bộ nhớ đệm HTML và thực sự không thể lưu nếu phản hồi HTML là động – các tài nguyên cùng dòng 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ì các tài nguyên cùng dòng không thể sử dụng lại được.
- Ngay cả khi bạn có thể lưu HTML vào bộ nhớ đệm, tài nguyên cùng dò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 bạn nội tuyến quá nhiều, bạn sẽ trì hoãn việc trình quét tải trước phát hiện các tài nguyên sau này trong tài liệu, vì việc tải xuống nội dung bổ sung, cùng dò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, đề xuất LCP là hình ảnh ở đầu trang và CSS nằm trong một tệp riêng biệt do phần tử <link> tải. Trang 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 với 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 để tải trang trong các tài nguyên riêng biệt. Điều này không trì hoãn việc trình quét tải trước thực hiện công việc.
Bây giờ điều gì sẽ xảy ra nếu CSS và tất cả các phông chữ được chèn dưới dạng tài nguyên base64?
<img>, nhưng nội tuyến của CSS và 4 tài nguyên phông chữ của CSS đó trong "" sẽ trì hoãn việc trình quét tải trước phát hiện ra hình ảnh cho đến khi các tài nguyên đó được tải xuống hoàn toàn.
Tác động của nội tuyến sẽ gây ra các hệ quả tiêu cực cho LCP trong ví dụ này và đối với hiệu suất nói chung. Phiên bản của trang không cùng dòng bất kỳ nội dung nào sẽ hiển thị hình ảnh LCP sau khoảng 3,5 giây. Trang nằm cùng dòng mọi thứ sẽ không hiển thị hình ảnh LCP cho đến chỉ hơn 7 giây.
Ngoài trình quét tải trước, bạn còn có thể sử dụng nhiều tính năng khác ở đây. Phông chữ cùng dòng không phải là một chiến lược tốt vì base64 là định dạng không hiệu quả cho các tài nguyên nhị phân. Một yếu tố khác đang diễn ra là các tài nguyên phông chữ bên ngoài sẽ không được tải xuống trừ khi CSSOM xác định rằng các tài nguyên đó là cần thiết. Khi các phông chữ đó nằm trong dòng base64, các phông chữ đó sẽ được tải xuống cho dù chúng có cần thiết cho trang hiện tại hay không.
Tính năng tải trước có thể giúp cải thiện thông tin ở đâ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. Tuy nhiên, việc làm tăng tối đa HTML có thể không thể lưu vào bộ nhớ đệm với các tài nguyên cùng dòng cũng gây ra những hậu quả tiêu cực khác. Mẫu này cũng ảnh hưởng đến Nội dung đầu tiên hiển thị (FCP). Trong phiên bản của trang không có nội dung nào cùng dòng, FCP là khoảng 2,7 giây. Trong phiên bản mà mọi thứ cùng dòng, FCP là khoảng 5,8 giây.
Hãy thật cẩn thận với việc chèn nội dung vào HTML, đặc biệt là các tài nguyên được mã hoá base64. Nhìn chung, không nên dùng tuỳ chọn này, ngoại trừ các tài nguyên rất nhỏ. Đặt cùng dòng càng ít càng tốt, vì việc đặt quá nhiều sẽ khiến bạn đùa 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 về điều này: JavaScript chắc chắn ảnh hưởng đến tốc độ trang. Các nhà phát triển không chỉ dựa vào công cụ này để cung cấp tính tương tác mà còn có xu hướng dựa vào công cụ này để phân phối nội dung. Việc này giúp nhà phát triển có trải nghiệm tốt hơ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 chuyển thành lợi ích cho người dùng.
Một mẫu có thể vượt qua trình quét tải trước là kết xuất mã đánh dấu bằng JavaScript phía máy khách:
Khi tải trọng đánh dấu được đưa vào và hiển thị hoàn toàn bằng JavaScript trong trình duyệt, trình quét tải trước sẽ không nhìn thấy bất kỳ tài nguyên nào trong mã đánh dấu đó. Việc 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 ảnh hưởng đến LCP. Trong những ví dụ này, yêu cầu đối với hình ảnh LCP bị trễ đáng kể khi so sánh với trải nghiệm tương đương do máy chủ hiển thị không yêu cầu JavaScript xuất hiện.
Mặc dù nội dung này có phần khác biệt so với trọng tâm của bài viết này, nhưng tác động của việc kết xuất mã đánh dấu trên ứng dụng không chỉ dừng lại ở chức năng quét tải trước. Thứ nhất, việc giới thiệu JavaScript để hỗ trợ một trải nghiệm không yêu cầu sẽ gây ra thời gian xử lý không cần thiết có thể ảnh hưởng đến Lượt tương tác với nội dung hiển thị tiếp theo (INP). Nếu hiển thị quá nhiều mã đánh dấu trên máy khách, bạn sẽ có nhiều khả năng tạo ra các nhiệm vụ dài hơn so với cùng một số lượng mã đánh dấu mà máy chủ gửi. Lý do cho điều này – ngoài việc xử lý bổ sung liên quan đến JavaScript – là do các trình duyệt truyền trực tuyến mã đánh dấu từ máy chủ và phân chia hiển thị theo cách có xu hướng hạn chế các tác vụ dài. 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, có thể ảnh hưởng đến INP của một trang.
Cách 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 trên trang của bạn chứ không thể hiển thị trên máy khách? Nếu câu trả lời cho câu hỏi này là "không", thì bạn nên cân nhắc phương thức kết xuất phía máy chủ (SSR) hoặc mã đánh dấu được tạo tĩnh, vì điều này sẽ giúp trình quét tải trước phát hiện và có thể tìm nạp trước các tài nguyên quan trọng.
Nếu trang của bạn cần phải có 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 với SSR (với JavaScript vani) hoặc dùng công nghệ hydrat hoá để tận dụng tối đa cả hai phương pháp trên.
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 hiệu quả cao giúp trang tải nhanh hơn trong khi khởi động. Bằng cách tránh các mẫu không thể khám phá trước tài nguyên quan trọng, bạn không chỉ đơn giản hoá quá trình phát triể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 về nhiều chỉ số, bao gồm cả một vài chỉ số quan trọng của trang web.
Tóm lại, sau đây là những điểm mà bạn nên rút ra từ 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 quét chính nếu trình quét này bị chặn để có thể khám phá các 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 phát hiện được những 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. (nhưng không giới hạn ở những cách sau) có thể giúp chặn trình quét tải trước:
- Chèn tài nguyên vào DOM bằng JavaScript, có thể là tập lệnh, hình ảnh, biểu định kiểu hoặc bất kỳ nội dung nào khác sẽ tốt hơn trong tải trọng đánh dấu ban đầu từ máy chủ.
- Tải từng phần 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 nội dung tham chiếu đến các nguồn tài liệu phụ bằng JavaScript.
- Trình quét tải trước chỉ quét HTML. Công cụ này không kiểm tra nội dung của các tài nguyên khác (đặc biệt là CSS) mà có thể bao gồm các tệp đối chiếu đến các tài sản quan trọng, bao gồm cả các đề xuất LCP.
Nếu vì bất cứ lý do gì mà bạn không thể tránh được 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 tra các công cụ trong phòng thí nghiệm để đảm bảo rằng phương pháp này mang lại hiệu quả mong muốn cho bạ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ì.
Tài nguyên
- "Tập lệnh không đồng bộ" chèn vào tập lệnh bị 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 được cảm nhận
- Tối ưu hoá nội dung lớn nhất hiển thị
Hình ảnh chính trên trang Unsplash của Mohammad Rahmani .