Hướng dẫn how does a browser handle javascript and html - trình duyệt xử lý javascript và html như thế nào

Tổng quan

Các trang web nhanh cung cấp trải nghiệm người dùng tốt hơn. Người dùng muốn và mong đợi trải nghiệm web với nội dung nhanh để tải và mượt mà để tương tác.

Hai vấn đề chính trong hiệu suất web là hiểu các vấn đề phải làm với độ trễ và các vấn đề phải làm với thực tế là đối với hầu hết các phần, các trình duyệt được đưa ra một lần.

Độ trễ là mối đe dọa chính của chúng tôi để vượt qua để đảm bảo tải nhanh. Để tải nhanh, các mục tiêu của các nhà phát triển bao gồm gửi thông tin được yêu cầu càng nhanh càng tốt, hoặc ít nhất là có vẻ siêu nhanh. Độ trễ mạng là thời gian cần thiết để truyền các byte qua không trung đến máy tính. Hiệu suất web là những gì chúng ta phải làm để làm cho tải trang diễn ra nhanh nhất có thể.

Đối với hầu hết các phần, các trình duyệt được coi là một luồng. Đối với các tương tác suôn sẻ, mục tiêu của nhà phát triển là đảm bảo các tương tác trang web hiệu suất, từ cuộn trơn tru đến phản ứng với chạm vào. Thời gian kết xuất là chìa khóa, với việc đảm bảo luồng chính có thể hoàn thành tất cả các công việc chúng tôi ném vào nó và vẫn luôn có sẵn để xử lý các tương tác của người dùng. Hiệu suất web có thể được cải thiện bằng cách hiểu bản chất đơn của trình duyệt và giảm thiểu trách nhiệm của luồng chính, nếu có thể và phù hợp, để đảm bảo kết xuất là trơn tru và phản ứng với các tương tác là ngay lập tức.

dẫn đường

Điều hướng là bước đầu tiên trong việc tải một trang web. Nó xảy ra bất cứ khi nào người dùng yêu cầu một trang bằng cách nhập URL vào thanh địa chỉ, nhấp vào liên kết, gửi biểu mẫu, cũng như các hành động khác.

Một trong những mục tiêu của hiệu suất web là giảm thiểu lượng thời gian mà một điều hướng phải hoàn thành. Trong điều kiện lý tưởng, điều này thường không mất quá nhiều thời gian, nhưng độ trễ và băng thông là kẻ thù có thể gây ra sự chậm trễ.

Tra cứu DNS

Bước đầu tiên của việc điều hướng đến một trang web là tìm nơi tài sản cho trang đó được đặt. Nếu bạn điều hướng đến script2, trang HTML được đặt trên máy chủ với địa chỉ IP là script3. Nếu bạn chưa bao giờ truy cập trang web này, việc tra cứu DNS phải xảy ra.

Trình duyệt của bạn yêu cầu tra cứu DNS, cuối cùng được đặt ra bởi một máy chủ tên, từ đó trả lời bằng một địa chỉ IP. Sau yêu cầu ban đầu này, IP có thể sẽ được lưu trữ trong một thời gian, giúp tăng tốc các yêu cầu tiếp theo bằng cách truy xuất địa chỉ IP từ bộ đệm thay vì liên hệ lại với máy chủ tên.

Tra cứu DNS thường chỉ cần được thực hiện một lần trên mỗi tên máy chủ cho tải trang. Tuy nhiên, việc tra cứu DNS phải được thực hiện cho mỗi tên máy chủ duy nhất là tham chiếu trang được yêu cầu. Nếu phông chữ, hình ảnh, tập lệnh, quảng cáo và số liệu của bạn đều có tên máy chủ khác nhau, thì tra cứu DNS sẽ phải được thực hiện cho từng tên máy chủ.

Điều này có thể có vấn đề cho hiệu suất, đặc biệt là trên các mạng di động. Khi người dùng ở trên mạng di động, mỗi lần tra cứu DNS phải đi từ điện thoại đến tháp di động để đến máy chủ DNS có thẩm quyền. Khoảng cách giữa điện thoại, tháp di động và máy chủ tên có thể thêm độ trễ đáng kể.

TCP bắt tay

Khi đã biết địa chỉ IP, trình duyệt đã thiết lập kết nối với máy chủ thông qua bắt tay ba chiều TCP. Cơ chế này được thiết kế sao cho hai thực thể cố gắng liên lạc với nhau trong trường hợp này, trình duyệt và máy chủ web có thể đàm phán các tham số của kết nối ổ cắm TCP mạng trước khi truyền dữ liệu, thường qua HTTPS.

Kỹ thuật bắt tay ba chiều của TCP thường được gọi là "syn-syn-ack" Có, điều này có nghĩa là ba tin nhắn khác qua lại giữa mỗi máy chủ và yêu cầu vẫn chưa được thực hiện.

Đàm phán TLS

Đối với các kết nối an toàn được thiết lập trên HTTPS, một "cái bắt tay" khác là bắt buộc. Điều bắt tay này, hay đúng hơn là đàm phán TLS, xác định mật mã nào sẽ được sử dụng để mã hóa giao tiếp, xác minh máy chủ và thiết lập rằng kết nối an toàn được áp dụng trước khi bắt đầu chuyển dữ liệu thực tế. Điều này đòi hỏi thêm ba chuyến đi vòng nữa đến máy chủ trước khi yêu cầu nội dung thực sự được gửi.

Mặc dù việc kết nối bảo mật thêm thời gian cho tải trang, một kết nối an toàn có giá trị chi phí độ trễ, vì dữ liệu được truyền giữa trình duyệt và máy chủ web không thể được giải mã bởi bên thứ ba.

Sau 8 chuyến đi vòng, trình duyệt cuối cùng đã có thể đưa ra yêu cầu.

Phản ứng

Khi chúng tôi có kết nối được thiết lập với máy chủ web, trình duyệt sẽ gửi yêu cầu HTTP script4 ban đầu thay mặt cho người dùng, đối với các trang web thường là tệp HTML. Khi máy chủ nhận được yêu cầu, nó sẽ trả lời với các tiêu đề phản hồi có liên quan và nội dung của HTML.

DOCTYPE html>
<html lang="en-US">
  <head>
    <meta charset="UTF-8" />
    <title>My simple pagetitle>
    <link rel="stylesheet" href="styles.css" />
    <script src="myscript.js">script>
  head>
  <body>
    <h2 class="heading">My Pageh2>
    <p>A paragraph with a <a href="https://example.com/about">linka>p>
    <div>
      <img src="myimage.jpg" alt="image description" />
    div>
    <script src="anotherscript.js">script>
  body>
html>

Phản hồi này cho yêu cầu ban đầu này chứa byte dữ liệu đầu tiên nhận được. Thời gian cho byte đầu tiên (TTFB) là thời gian giữa khi người dùng thực hiện yêu cầu, nói bằng cách nhấp vào liên kết và nhận được gói HTML đầu tiên này. Phần đầu tiên của nội dung thường là 14kb dữ liệu.

Trong ví dụ của chúng tôi ở trên, yêu cầu chắc chắn là dưới 14kb, nhưng các tài nguyên được liên kết không được yêu cầu cho đến khi trình duyệt gặp các liên kết trong quá trình phân tích cú pháp, được mô tả bên dưới.

TCP Slow Start / 14kb Quy tắc

Gói phản hồi đầu tiên sẽ là 14kb. Đây là một phần của TCP Slow Start, một thuật toán cân bằng tốc độ của kết nối mạng. Bắt đầu chậm tăng dần lượng dữ liệu được truyền cho đến khi có thể xác định được băng thông tối đa của mạng.

Trong TCP Slow Start, sau khi nhận được gói ban đầu, máy chủ tăng gấp đôi kích thước của gói tiếp theo lên khoảng 28kb. Các gói tiếp theo tăng kích thước cho đến khi đạt đến ngưỡng được xác định trước, hoặc bị tắc nghẽn.

Nếu bạn đã từng nghe về quy tắc 14kb cho tải trang ban đầu, thì TCP Slow Start là lý do tại sao phản hồi ban đầu là 14KB và tại sao Tối ưu hóa hiệu suất web lại gọi để tập trung tối ưu hóa với phản hồi 14KB ban đầu này. Khởi động chậm TCP dần dần xây dựng tốc độ truyền phù hợp với khả năng của mạng để tránh tắc nghẽn.

Điều khiển tắc nghẽn

Khi máy chủ gửi dữ liệu trong các gói TCP, máy khách của người dùng xác nhận giao hàng bằng cách trả lại xác nhận hoặc ACK. Kết nối có công suất hạn chế tùy thuộc vào điều kiện phần cứng và mạng. Nếu máy chủ gửi quá nhiều gói quá nhanh, chúng sẽ bị loại bỏ. Có nghĩa là, sẽ không có sự thừa nhận. Máy chủ đăng ký điều này là thiếu acks. Các thuật toán kiểm soát tắc nghẽn sử dụng luồng này của các gói và ACK đã gửi để xác định tỷ lệ gửi.

Phân tích cú pháp

Khi trình duyệt nhận được đoạn dữ liệu đầu tiên, nó có thể bắt đầu phân tích thông tin nhận được. Phân tích cú pháp là bước mà trình duyệt thực hiện để biến dữ liệu mà nó nhận được qua mạng thành DOM và CSSOM, được trình kết xuất sử dụng để vẽ một trang lên màn hình.

DOM là đại diện nội bộ của đánh dấu cho trình duyệt. DOM cũng được phơi bày và có thể được thao tác thông qua các API khác nhau trong JavaScript.

Ngay cả khi HTML của trang yêu cầu lớn hơn gói 14kb ban đầu, trình duyệt sẽ bắt đầu phân tích cú pháp và cố gắng hiển thị trải nghiệm dựa trên dữ liệu mà nó có. Đây là lý do tại sao điều quan trọng là tối ưu hóa hiệu suất web để bao gồm mọi thứ mà trình duyệt cần để bắt đầu hiển thị một trang hoặc ít nhất là một mẫu của trang - CSS và HTML cần thiết cho kết xuất đầu tiên - trong 14 kilobyte đầu tiên. Nhưng trước khi mọi thứ được hiển thị lên màn hình, HTML, CSS và JavaScript phải được phân tích cú pháp.

Xây dựng cây Dom

Chúng tôi mô tả năm bước trong đường dẫn quan trọng.

Bước đầu tiên là xử lý đánh dấu HTML và xây dựng cây Dom. Phân tích cú pháp HTML liên quan đến việc xây dựng mã thông báo và xây dựng cây. Mã thông báo HTML bao gồm các thẻ bắt đầu và kết thúc, cũng như tên và giá trị thuộc tính. Nếu tài liệu được hình thành tốt, phân tích cú pháp thì đơn giản và nhanh hơn. Trình phân tích cú pháp phân tích cú pháp đầu vào vào tài liệu, xây dựng cây tài liệu.

Cây Dom mô tả nội dung của tài liệu. Phần tử script5 là thẻ đầu tiên và nút gốc của cây tài liệu. Cây phản ánh các mối quan hệ và hệ thống phân cấp giữa các thẻ khác nhau. Thẻ lồng nhau trong các thẻ khác là các nút con. Số lượng các nút DOM càng lớn, càng mất nhiều thời gian để xây dựng cây Dom.

Khi trình phân tích cú pháp tìm thấy các tài nguyên không chặn, chẳng hạn như hình ảnh, trình duyệt sẽ yêu cầu các tài nguyên đó và tiếp tục phân tích cú pháp. Phân tích cú pháp có thể tiếp tục khi gặp phải tệp CSS, nhưng script6 thẻ, đặc biệt là các thẻ không có thuộc tính async hoặc defer, và tạm dừng phân tích cú pháp HTML. Mặc dù máy quét tải trước của trình duyệt đã thúc đẩy quá trình này, các tập lệnh quá mức vẫn có thể là một nút cổ chai đáng kể.

Máy quét tải trước

Trong khi trình duyệt xây dựng cây DOM, quá trình này chiếm chủ đề chính. Khi điều này xảy ra, máy quét preload sẽ phân tích thông qua nội dung có sẵn và yêu cầu các tài nguyên ưu tiên cao như CSS, JavaScript và phông chữ web. Nhờ máy quét preload, chúng tôi không phải đợi cho đến khi trình phân tích cú pháp tìm thấy một tham chiếu đến tài nguyên bên ngoài để yêu cầu nó. Nó sẽ lấy tài nguyên trong nền để vào thời điểm trình phân tích cú pháp HTML chính đạt được tài sản được yêu cầu, chúng có thể đã được bay hoặc đã được tải xuống. Tối ưu hóa Máy quét preload cung cấp giảm tắc giảm.

<link rel="stylesheet" href="styles.css" />
<script src="myscript.js" async>script>
<img src="myimage.jpg" alt="image description" />
<script src="anotherscript.js" async>script>

Trong ví dụ này, trong khi luồng chính là phân tích HTML và CSS, máy quét tải trước sẽ tìm thấy các tập lệnh và hình ảnh và cũng bắt đầu tải xuống chúng. Để đảm bảo tập lệnh không chặn quy trình, hãy thêm thuộc tính async hoặc thuộc tính defer nếu lệnh phân tích cú pháp và thực thi JavaScript là quan trọng.

Chờ đợi để có được CSS không chặn phân tích cú pháp HTML hoặc tải xuống, nhưng nó chặn JavaScript, vì JavaScript thường được sử dụng để truy vấn tác động của các thuộc tính CSS đối với các phần tử.

Xây dựng CSSOM

Bước thứ hai trong đường dẫn kết xuất quan trọng là xử lý CSS và xây dựng cây CSSOM. Mô hình đối tượng CSS tương tự như DOM. DOM và CSSOM là cả hai cây. Chúng là cấu trúc dữ liệu độc lập. Trình duyệt chuyển đổi các quy tắc CSS thành bản đồ các kiểu mà nó có thể hiểu và làm việc cùng. Trình duyệt đi qua từng quy tắc được đặt trong CSS, tạo ra một cây các nút với các mối quan hệ cha mẹ, con và anh chị em dựa trên các bộ chọn CSS.

Như với HTML, trình duyệt cần chuyển đổi các quy tắc CSS nhận được thành một cái gì đó có thể hoạt động. Do đó, nó lặp lại quy trình HTML-to-Ecject, nhưng đối với CSS.

CSSOM cây bao gồm các kiểu từ bảng kiểu tác nhân người dùng. Trình duyệt bắt đầu với quy tắc chung nhất áp dụng cho một nút và tinh chỉnh đệ quy các kiểu được tính toán bằng cách áp dụng các quy tắc cụ thể hơn. Nói cách khác, nó xếp các giá trị tài sản.

Xây dựng CSSOM là rất, rất nhanh và không được hiển thị với màu duy nhất trong các công cụ phát triển hiện tại. Thay vào đó, "phong cách tính toán lại" trong các công cụ nhà phát triển cho thấy tổng thời gian cần thiết để phân tích CSS, xây dựng cây CSSOM và tính toán các kiểu tính toán. Về mặt tối ưu hóa hiệu suất web, có trái cây treo thấp hơn, vì tổng thời gian để tạo CSSOM thường ít hơn thời gian để tra cứu một DNS.

Các quy trình khác

Tổng hợp JavaScript

Mặc dù CSS đang được phân tích cú pháp và CSSOM được tạo, các tài sản khác, bao gồm các tệp JavaScript, đang tải xuống (nhờ trình quét preload). JavaScript được giải thích, biên dịch, phân tích cú pháp và thực thi. Các tập lệnh được phân tích cú pháp vào các cây cú pháp trừu tượng. Một số công cụ trình duyệt lấy cây cú pháp trừu tượng và chuyển nó vào một trình thông dịch, xuất mã byte được thực thi trên luồng chính. Điều này được gọi là tổng hợp JavaScript.

Xây dựng cây tiếp cận

Trình duyệt cũng xây dựng một cây khả năng truy cập mà các thiết bị hỗ trợ sử dụng để phân tích và giải thích nội dung. Mô hình đối tượng khả năng truy cập (AOM) giống như một phiên bản ngữ nghĩa của DOM. Trình duyệt cập nhật cây khả năng truy cập khi DOM được cập nhật. Cây khả năng tiếp cận không thể sửa đổi bởi chính các công nghệ hỗ trợ.

Cho đến khi AOM được xây dựng, nội dung không thể truy cập được cho người đọc màn hình.

Kết xuất

Các bước kết xuất bao gồm phong cách, bố cục, sơn và, trong một số trường hợp, tổng hợp. Các cây CSSOM và DOM được tạo ra trong bước phân tích cú pháp được kết hợp thành một cây kết xuất sau đó được sử dụng để tính toán bố cục của mọi phần tử có thể nhìn thấy, sau đó được vẽ lên màn hình. Trong một số trường hợp, nội dung có thể được quảng bá lên các lớp của riêng họ và được tổng hợp, cải thiện hiệu suất bằng cách vẽ các phần của màn hình trên GPU thay vì CPU, giải phóng luồng chính.

Phong cách

Bước thứ ba trong đường dẫn kết xuất quan trọng là kết hợp DOM và CSSOM thành cây kết xuất. Cây kiểu được tính toán, hoặc cây kết xuất, xây dựng bắt đầu với gốc của cây Dom, đi qua từng nút có thể nhìn thấy.

Các thẻ sẽ không được hiển thị, như script1 và trẻ em của nó và bất kỳ nút nào có script2, chẳng hạn như script3 bạn sẽ tìm thấy trong các kiểu dáng của tác nhân người dùng, không được bao gồm trong cây kết xuất vì chúng sẽ không xuất hiện trong đầu ra kết xuất . Các nút có script4 được áp dụng được bao gồm trong cây kết xuất, vì chúng chiếm không gian. Vì chúng tôi chưa đưa ra bất kỳ chỉ thị nào để ghi đè mặc định của tác nhân người dùng, nút script trong ví dụ mã của chúng tôi ở trên sẽ không được đưa vào cây kết xuất.

Mỗi nút có thể nhìn thấy có các quy tắc CSSOM được áp dụng cho nó. Cây kết xuất chứa tất cả các nút có thể nhìn thấy với nội dung và các kiểu được tính toán - khớp với tất cả các kiểu có liên quan với mọi nút có thể nhìn thấy trong cây Dom và xác định, dựa trên tầng CSS, các kiểu được tính toán cho mỗi nút.

Cách trình bày

Bước thứ tư trong đường dẫn kết xuất quan trọng đang chạy bố cục trên cây kết xuất để tính toán hình học của mỗi nút. Bố cục là quá trình theo đó chiều rộng, chiều cao và vị trí của tất cả các nút trong cây kết xuất được xác định, cộng với việc xác định kích thước và vị trí của mỗi đối tượng trên trang. Reflow là bất kỳ kích thước và xác định vị trí tiếp theo của bất kỳ phần nào của trang hoặc toàn bộ tài liệu.

Khi cây kết xuất được xây dựng, bố cục bắt đầu. Cây kết xuất được xác định các nút nào được hiển thị (ngay cả khi vô hình) cùng với các kiểu tính toán của chúng, nhưng không phải là kích thước hoặc vị trí của mỗi nút. Để xác định kích thước và vị trí chính xác của từng đối tượng, trình duyệt bắt đầu ở gốc của cây kết xuất và đi qua nó.

Trên trang web, hầu hết mọi thứ đều là một hộp. Các thiết bị khác nhau và các tùy chọn máy tính để bàn khác nhau có nghĩa là một số kích thước chế độ xem khác nhau không giới hạn. Trong giai đoạn này, xem xét kích thước chế độ xem, trình duyệt xác định kích thước của tất cả các hộp khác nhau sẽ được đặt trên màn hình. Lấy kích thước của chế độ xem làm cơ sở, bố cục thường bắt đầu bằng cơ thể, đưa ra kích thước của tất cả các hậu duệ của cơ thể, với các thuộc tính mô hình hộp của mỗi yếu tố, cung cấp không gian giữ chỗ cho các yếu tố thay thế mà nó không biết kích thước của như hình ảnh của chúng tôi.

Lần đầu tiên kích thước và vị trí của các nút được xác định được gọi là bố cục. Các tính toán lại sau đó của kích thước nút và vị trí được gọi là phản xạ. Trong ví dụ của chúng tôi, giả sử bố cục ban đầu xảy ra trước khi hình ảnh được trả về. Vì chúng tôi không khai báo kích thước của hình ảnh của chúng tôi, sẽ có một phản xạ một khi kích thước hình ảnh được biết đến.

Sơn

Bước cuối cùng trong đường dẫn quan trọng là vẽ các nút riêng lẻ lên màn hình, lần xuất hiện đầu tiên được gọi là sơn có ý nghĩa đầu tiên. Trong giai đoạn vẽ hoặc rasterization, trình duyệt chuyển đổi từng hộp được tính toán trong giai đoạn bố cục thành các pixel thực tế trên màn hình. Vẽ tranh liên quan đến việc vẽ mọi phần trực quan của một yếu tố lên màn hình, bao gồm văn bản, màu sắc, đường viền, bóng tối và các yếu tố thay thế như nút và hình ảnh. Trình duyệt cần phải làm điều này siêu nhanh.

Để đảm bảo cuộn trơn tru và hoạt hình, mọi thứ chiếm giữ chủ đề chính, bao gồm các kiểu tính toán, cùng với Reflow và Paint, phải lấy trình duyệt dưới 16,67ms để hoàn thành. Tại 2048 x 1536, iPad có hơn 3.145.000 pixel được vẽ lên màn hình. Đó là rất nhiều pixel phải được sơn rất nhanh. Để đảm bảo sơn lại có thể được thực hiện thậm chí nhanh hơn sơn ban đầu, bản vẽ lên màn hình thường được chia thành nhiều lớp. Nếu điều này xảy ra, thì việc tổng hợp là cần thiết.

Vẽ tranh có thể phá vỡ các yếu tố trong cây bố cục thành các lớp. Thúc đẩy nội dung thành các lớp trên GPU (thay vì luồng chính trên CPU) cải thiện hiệu suất sơn và sơn lại. Có các thuộc tính và phần tử cụ thể khởi tạo một lớp, bao gồm script6 và script7, và bất kỳ phần tử nào có thuộc tính CSS của script8, 3D script9, 0 và một vài thuộc tính khác. Các nút này sẽ được vẽ lên lớp của chính họ, cùng với con cháu của chúng, trừ khi một hậu duệ đòi hỏi lớp của chính nó cho một (hoặc nhiều) lý do trên.

Các lớp cải thiện hiệu suất, nhưng rất tốn kém khi quản lý bộ nhớ, vì vậy không nên sử dụng quá mức như một phần của các chiến lược tối ưu hóa hiệu suất web.

Tổng hợp

Khi các phần của tài liệu được vẽ theo các lớp khác nhau, chồng chéo lẫn nhau, việc tổng hợp là cần thiết để đảm bảo chúng được vẽ vào màn hình theo đúng thứ tự và nội dung được hiển thị chính xác.

Khi trang tiếp tục tải tài sản, Reflow có thể xảy ra (nhớ lại hình ảnh ví dụ của chúng tôi đã đến muộn). Một Reflow Sparks một bản sơn lại và một kết hợp lại. Nếu chúng tôi xác định kích thước của hình ảnh của chúng tôi, không cần phải có phản xạ, và chỉ có lớp cần được sơn lại mới được sơn lại và được tổng hợp nếu cần thiết. Nhưng chúng tôi đã không bao gồm kích thước hình ảnh! Khi hình ảnh được lấy từ máy chủ, quá trình kết xuất quay trở lại các bước bố cục và khởi động lại từ đó.

Tương tác

Một khi chủ đề chính được thực hiện để vẽ trang, bạn sẽ nghĩ rằng chúng tôi sẽ là "tất cả đã được thiết lập". Điều đó không nhất thiết là trường hợp. Nếu tải bao gồm JavaScript, điều đó đã được hoãn lại chính xác và chỉ được thực hiện sau vụ cháy sự kiện 1, luồng chính có thể bận và không có sẵn để cuộn, chạm và các tương tác khác.

Thời gian tương tác (TTI) là phép đo thời gian từ yêu cầu đầu tiên đó dẫn đến việc tra cứu DNS và kết nối SSL đến khi trang tương tác - tương tác là thời điểm sau khi sơn nội dung đầu tiên khi trang phản hồi Tương tác của người dùng trong vòng 50ms. Nếu luồng chính bị chiếm phân tích, biên dịch và thực hiện JavaScript, thì nó không có sẵn và do đó không thể phản hồi các tương tác của người dùng theo kiểu kịp thời (dưới 50ms).

Trong ví dụ của chúng tôi, có thể hình ảnh được tải nhanh chóng, nhưng có lẽ tệp 2 là 2MB và kết nối mạng của người dùng của chúng tôi chậm. Trong trường hợp này, người dùng sẽ thấy trang siêu nhanh, nhưng sẽ không thể cuộn mà không cần jank cho đến khi tập lệnh được tải xuống, phân tích cú pháp và thực thi. Đó không phải là một trải nghiệm người dùng tốt. Tránh chiếm chủ đề chính, như đã được trình bày trong ví dụ WebPagetest này:

Trong ví dụ này, quá trình tải nội dung DOM mất hơn 1,5 giây và luồng chính đã bị chiếm hoàn toàn trong toàn bộ thời gian đó, không phản hồi để nhấp vào các sự kiện hoặc vòi màn hình.

Xem thêm