[PageSpeed] Quản lý thứ tự tài nguyên và kích thước/số lượng yêu cầu để cải thiện tốc độ trang và khả năng thu thập dữ liệu

Mối quan hệ vô cùng chặt chẽ tồn tại giữa thứ tự tài nguyên của trang và thời gian tải trang, đặc biệt là khi so sánh với các yếu tố khác về tốc độ trang. Cụ thể, cảm nhận về tốc độ tải trang và quá trình tải phần trang web ngay trên màn hình ban đầu (above the fold) có liên quan mật thiết đến thứ tự tài nguyên.

Để tạo ấn tượng ban đầu tích cực với người dùng và giảm thời gian cần thiết để hiển thị nội dung quan trọng nhất (largest contentful paint), chúng ta cần hiểu cách thứ tự tài nguyên có thể tác động đến điểm hiệu suất của bạn.

Cần lưu ý rằng không có phần màu xanh lá cây (TTFB, hoặc thời gian đến byte đầu tiên), vì đây là ví dụ dạng waterfall từ máy tính của tôi, không phải từ máy chủ. Các phần màu trắng đang chờ kết nối, màu xanh lam là thời gian tải xuống và màu xám biểu thị cho trạng thái “dừng”.

Đây là bài viết cuối cùng trong loạt bốn bài viết về tốc độ trang web hiện đại. Để hiểu rõ hơn về một số chủ đề sẽ được thảo luận trong bài viết này, bạn nên đọc các bài viết trước đó:

Bài viết này sẽ đề cập đến những nội dung gì?

Trong phạm vi SEO kỹ thuật, bài viết này sẽ phân tích trình tự các tài nguyên ảnh hưởng thế nào đến các giai đoạn xây dựng một trang web. Chúng ta sẽ xem xét những câu hỏi liên quan đến những ý tưởng đã được khám phá trong các bài viết trước, chẳng hạn như:

• Những loại tệp JS nào nên được đặt ở đầu trang web?
• Tại sao việc sử dụng phức tạp nhiều tệp CSS và JS lại làm trình duyệt tải trang chậm hơn?
• Những mẹo cần biết về việc tải tài nguyên giúp tăng tốc độ trang web?
• Các khái niệm về “Dịch chuyển Bố cục Tích lũy” (Cumulative Layout Shifting), “Tổng Thời gian Chặn” (Total Block Time), và “Vẽ Nội dung Lớn nhất” (Largest Contentful Paint) mà Google vừa tích hợp vào Thuật toán Xếp hạng (Pagespeed Algorithm) là gì?
• Thứ tự tài nguyên có ảnh hưởng đến ngân sách thu thập dữ liệu trang (crawl budget)?
• Preconnect và DNS-Prefetch: cái nào tối ưu hơn cho tốc độ trang?
• Có tác dụng phụ nào khi sử dụng thuộc tính async hoặc defer cho các nguồn JS?

Tại sao cần xem xét thứ tự tài nguyên?

Trong ví dụ trên, một tệp CSS đã mở rộng quá trình CSSOM đơn giản bằng cách chồng chéo dữ liệu được tạo bởi một tệp khác. Ngoài ra, tệp đầu tiên đã thêm một số hiệu ứng kiểu trực quan quan trọng vào các phần tử trang lớn. Vì vậy, việc tải tệp CSS ảnh hưởng nhiều hơn đến trang trước các tài nguyên khác đã tạo ra một khoảng thời gian giảm tải cho sự kiện DOMContentLoaded.

Đối với một trang web tin tức hoặc thương mại điện tử với hàng triệu URL, sự khác biệt này có thể tạo ra lợi ích đáng kể và tạo ra sự khác biệt lớn trong hiệu suất SEO trong vòng một năm.

Ưu tiên tải tài nguyên là gì?

Nhóm IT nên làm theo phương pháp tương tự khi tối ưu hóa các số liệu tốc độ trang khác nhau, bao gồm:

• Tổng thời gian bị chặn (Total Blocked Time)
• Vẽ nội dung lớn nhất (Largest Contentful Paint)
• Đường dẫn hiển thị quan trọng (Critical Rendering Path)
• Thứ tự tải tài nguyên (Resource Load Order)

Bất kỳ chuyên gia SEO kỹ thuật nào cần hướng dẫn khách hàng hoặc nhóm IT nội bộ của họ nên biết các kỹ thuật hoặc phương pháp này.

Tại sao điều này quan trọng? Hãy cùng xem một ví dụ:

Trong ví dụ này, tất cả các tệp CSS quan trọng được tải sau các tệp JS bằng thuộc tính tải trước (preload). Trên biểu đồ waterfall, bạn có thể thấy rằng trình duyệt đã tải chúng trước bất chấp thứ tự/ưu tiên tài nguyên được yêu cầu. Bạn sẽ tìm thấy một sơ đồ cho ví dụ này bên dưới.

Cho đến nay, chúng ta đã xem xét cách Mô hình Đối tượng Tài liệu (DOM), Mô hình Đối tượng Bảng định kiểu Tầng (CSSOM), cây kết xuất và JavaScript được xử lý. Chúng ta đã thấy các tác động cùng với một số chỉ số hiện đại về tốc độ trang và UX như LCP, TBT và CLS để tối ưu hóa đường dẫn kết xuất quan trọng và thứ tự/tải tài nguyên.

Tuy nhiên, chúng ta cũng cần biết về các ưu tiên của tải trọng, các gợi ý và các lệnh.

Chúng ta sẽ sử dụng chúng, cùng với sự hiểu biết về các loại DOM khác nhau, để tạo đường dẫn kết xuất quan trọng nhanh nhất.

Với cú pháp tài nguyên phù hợp, bạn có thể cung cấp cho người dùng cùng dung lượng và số lượng tài nguyên trong thời gian ngắn hơn, từ đó gia tăng chuyển đổi. Nguồn ảnh: Varvy.

Gợi ý Tài nguyên: Dùng ở đâu, cách dùng, lý do nên dùng hay không nên dùng

Một số gợi ý trước khi duyệt hoặc về tài nguyên là preload (tải trước), prefetch (tải trước dữ liệu), preconnect (kết nối trước), DNS-Prefetch (lấy trước DNS), prerender (kết xuất trước).

Prefetch (Tải trước dữ liệu)

Prefetch là một gợi ý về tài nguyên, có tác dụng tải xuống một số nội dung quan trọng cho các trang tiếp theo mà không cần khởi động phiên trên chúng.

Đây là gợi ý tài nguyên có mức độ ưu tiên thấp. Có nghĩa là một số trình duyệt hiện đại thậm chí có thể không để ý đến gợi ý này.

Ngoài ra, nó lưu các nguồn đã truy xuất trước vào bộ nhớ của trình duyệt. Khi người dùng nhấp vào điều hướng tiếp theo, trình duyệt ngay lập tức hiển thị tài nguyên đã được truy xuất trước và tải xuống phần còn lại của tài nguyên trang sau.

Lưu ý rằng bạn không nên bắt đầu quá trình tải trước dữ liệu (prefetching) trong lúc trang web đang chạy hoặc bạn có thể làm chậm quá trình tải xuống và xây dựng trang web hiện tại.

Ví dụ: <link rel=”prefetch” href=”https://example.com/next-page.” />

Trong ví dụ trên, nguồn “aboutBG.jpg” là “prefetch” (tải trước). Khi chuyển sang trang tiếp theo, chúng ta thấy rằng nguồn tải trước với 0 MS và 0 WTTFB được tải từ phần “memory” (bộ nhớ). Do đó, “aboutBG.jpg” không có bất kỳ giá trị màu xanh lục nào (Thời gian cho Byte đầu tiên – Time for First Byte).

Bạn có thể thấy các nguồn ‘prefetch’ từ phần Khác (Other).

Prerender (kết xuất trước)

Prerender hơi khác so với prefetch. Về cơ bản, nó tải xuống tất cả các trang web điều hướng tiếp theo với đầy đủ các tài nguyên ở chế độ nền. Khi người dùng nhấp vào trang tiếp theo, trình duyệt sẽ hiển thị trang đó ngay lập tức.

Nếu bạn sử dụng tính năng này, bạn phải trì hoãn nó cho đến khi trang hiện tại kết thúc quá trình được trình duyệt hiển thị. Bạn cũng sẽ cần sử dụng Google Analytics hoặc Guess.js để dự đoán trang tiếp theo trong hành trình của người dùng.

Nếu bạn sử dụng ‘prerender’ hoặc ‘prefetch’ không đúng cho các trang điều hướng tiếp theo, rất có thể bạn sẽ khiến điện thoại/ máy tính của người dùng tải mọi thứ một cách vô ích.

Ví dụ: <link rel=”prerender” href=”https://example.com/next-page.” />

Như bạn có thể nhận thấy ở trên, tất cả các tài nguyên được lưu trữ trong bộ nhớ đệm trước khi trang web mở. Một số tài nguyên được lưu vào bộ nhớ đệm ở mức 95% thay vì 100%, nhưng điều này không ảnh hưởng đến trải nghiệm tải trang tức thì.

Google đã công bố một thư viện có tên Guess.js tại I/O 2018. Guess.js được tích hợp với Google Analytics, lập bản đồ hành trình chuyển đổi/nhấp chuột của người dùng và trích xuất các đường dẫn “điều hướng dự đoán”. Điều này cho phép bạn sử dụng các tùy chọn tải trước (prefetch) hoặc kết xuất trước (prerender) với giá trị điều hướng dự đoán cao.

Lưu ý rằng Google Chrome và Firefox sẽ tắt cài đặt kết xuất trước cho người dùng trong một số trường hợp (nguồn: https://guess-js.github.io/).

Giải thích thêm:

• Lưu trữ trong bộ nhớ đệm (caching): Kỹ thuật lưu trữ tạm thời dữ liệu (hình ảnh, tập tin, v.v…) của trang web để giảm tải cho lần truy cập tiếp theo, giúp trang web tải nhanh hơn.

• Tải trước (prefetch) và kết xuất trước (prerender): Kỹ thuật dự đoán những gì người dùng có thể cần tiếp theo và chuẩn bị trước các tài nguyên đó. Prerender mạnh mẽ hơn prefetch vì nó thực sự kết xuất toàn bộ trang web trong nền.

• Guess.js: Một thư viện JavaScript giúp các nhà phát triển web dự đoán hành vi của người dùng và tối ưu hóa việc tải trước tài nguyên để cải thiện tốc độ trang web

Đây là một ví dụ điển hình về hành trình nhấp chuột mà người dùng có khả năng thực hiện, được lập bản đồ bởi Guess.js. Với vai trò Chuyên gia SEO Kỹ thuật, bạn có thể đề xuất nhóm phát triển của mình kết hợp các kết quả trải nghiệm của loại công nghệ này.

Bạn cũng có thể bắt đầu ghi lại các hoạt động mạng của mình thông qua Chromium trên PC. Truy cập “chrome://net-export/” và bắt đầu ghi lại để theo dõi các sự kiện hiển thị trước hoặc tải trước trong tương lai trên trình duyệt. Bằng cách này, bạn có thể phân tích hành trình web hàng ngày của mình.

DNS-Prefetch và Preconnect

DNS-Prefetch và Preconnect là hai gợi ý tài nguyên (resource hints) có điểm tương đồng và khác biệt.

• DNS-Prefetch: Chức năng duy nhất là tra cứu DNS ngược. Nghĩa là công cụ này được dùng để cố gắng tìm ra trước các địa chỉ miền (domain) của các tài nguyên bên ngoài.

• Preconnect: Không chỉ phục vụ việc tra cứu địa chỉ DNS/tên miền. Preconnect còn hoàn tất các quá trình đàm phán TLS và bắt tay TCP cho nội dung được mã hóa. Theo đó, sử dụng Preconnect hiệu quả hơn so với chỉ dùng DNS-Prefetch.

Ví dụ:

1. <link rel=”preconnect” href=”//example.com”>
2. <link rel=”dns-prefetch” href=”//example.com”>

Bạn có thể kiểm tra TTFB của mình với Webpagetest waterfall như trên. Khi sử dụng Preconnect, bạn sẽ thấy tốc độ TTFB và kết nối ban đầu tăng 10-20 MS. Bạn cũng nên sử dụng độ lệch chuẩn cho các chủ đề kiểm tra không ổn định như thế này. Bằng cách này, bạn sẽ báo cáo một kết quả chắc chắn hơn cho nhóm phát triển của mình.

Bạn cũng có thể sử dụng công cụ này để kiểm tra DomInteractive. Dưới đây là một kiểm tra TTFB chi tiết hơn cho cùng một tài nguyên:

Preload (Tải trước)

Sự khác biệt chính giữa Preload và Preconnect là Preload sẽ tải xuống tài nguyên. Nếu bạn có các tài nguyên quan trọng cho quá trình hiển thị trang web cốt lõi, bạn cũng nên cân nhắc sử dụng tùy chọn Preload cho chúng.

Điều này sẽ tạo ra một header phản hồi (response header) dựa vào loại tài nguyên, đây cũng là một lợi thế nhỏ khác góp phần tối ưu tốc độ trang web.

Phía trên, bạn có thể thấy một lưu ý quan trọng: Firefox không hỗ trợ các gợi ý Preload (Tải trước) theo mặc định. Trình duyệt này chỉ hỗ trợ nó trong mục “network.preload” nếu người dùng đã thay đổi cài đặt mặc định.

Ví dụ về mã:

<link rel=”preload” href=”example-big.png”> or <link rel=”preload” href=”example.css” as=”style” onload=”this.rel=’stylesheet’”>

Bạn nên sửa đổi các phần “as” và “onload” cho phù hợp với tài nguyên của mình (“as =”media”, as =”script” v.v…)

Ở đây, chúng ta có thể thấy rằng mặc dù các tệp CSS được đặt sau Javascript trong quá trình tải, thời gian liên hệ ban đầu đã được cải thiện hơn 15% bằng cách “tải trước” những tệp quan trọng.

Những cải thiện hơn nữa sẽ xuất hiện nếu mã CSS không cần thiết bị loại bỏ và nếu CSS cho phần phía trên màn hình hiển thị ban đầu (above the fold) được cung cấp trực tiếp (inline). Tuy nhiên, nếu thời gian yêu cầu cho “Tổng thời gian bị chặn” không quá dài, CSS trực tiếp sẽ không đóng góp đáng kể cho các yêu cầu dưới 50 MS.

Tác động của Số lượng và Kích thước Yêu cầu Tài nguyên

Mặc dù bài viết này chủ yếu nói về thứ tự tài nguyên và các gợi ý về mức độ ưu tiên tải, nhưng trước khi kết thúc cũng cần đề cập đến ảnh hưởng của mối quan hệ giữa số lượng và kích thước của các yêu cầu tài nguyên lên tốc độ trang web và ngân sách thu thập dữ liệu (crawl budget).

Dưới đây là kích thước trang web trung bình theo ngành và quốc gia:

Đây là số lượng tài nguyên trung bình trên mỗi trang web được phân loại theo lĩnh vực và quốc gia.

Sự khác biệt về địa lý trong biểu mẫu này phần lớn là do sự khác biệt về truyền thống của nhà phát triển. Tuy nhiên, ở các quốc gia có giới hạn internet thấp trên đầu người, chẳng hạn như ở Nhật Bản, thì việc thấy các trang quá lớn và thực hiện quá nhiều yêu cầu là điều thú vị.

Kiểm tra tự động Tốc độ Trang qua Google Sheets và Pagespeed API dành cho thiết bị di động. Công cụ này cho phép bạn xác định và cải thiện các trang web có hiệu suất không đạt chuẩn Pagespeed.

Theo Addy Osmani:

• Chỉ số Tốc độ (Speed Index) nên ở mức dưới 3 giây.
• Thời gian tương tác (Time to Interactive) tối đa 5 giây.
• Vẽ nội dung chính (Largest Contentful Paint) trong 1 giây.
• Độ trễ đầu vào đầu tiên (First Input Delay) dưới 130 mili giây.
• Kích thước yêu cầu tài nguyên và thứ tự tải tài nguyên thậm chí còn quan trọng hơn để đạt được các tiêu chuẩn này, vốn được thiết lập cho một chiếc điện thoại Android tầm giá $200.

Sử dụng Chrome DevTools (không cần thêm các công cụ bên thứ ba) để tìm hiểu mọi thứ về Tổng số/Kích thước tài nguyên và bản tóm tắt Sự kiện tải trang web của bạn. Bạn có thể tạo so sánh cho từng trang web cho trang web của mình và các đối thủ cạnh tranh nhờ Pagespeed API, Google Sheets với Tự động hóa và từ đó lập nên một số biểu đồ trực quan cho các nhóm phát triển của bạn.

Đối với các lượt truy cập lặp lại, các giới hạn trên này thậm chí còn nghiêm ngặt hơn.

Tài nguyên bạn sẽ tải đầu tiên và tài nguyên bạn đưa lên hàng đầu thậm chí còn quan trọng hơn do khái niệm TCP Khởi động Chậm (TCP Slow Start). TCP Slow Start đánh dấu phần đầu tiên trong số 1460 byte đầu tiên của tệp HTML có thể được gửi trong 1,4 giây.

Nhằm loại bỏ TCP Slow Start, Google đã cải tiến công nghệ TCP BBR (Băng thông tắc nghẽn và Thời gian khứ hồi), dành riêng cho YouTube. Nhờ đó họ đã đạt được mức cải thiện 33% về độ trễ và thời gian khứ hồi. Dưới đây là hình ảnh minh họa từ Google:

Trong phần này, chúng ta sẽ tập trung vào một vài vấn đề khác nhau liên quan đến số lượng tài nguyên và kích thước yêu cầu tài nguyên.

Tại sao lại nói về kích thước và số lượng yêu cầu tài nguyên?

Xét về cả tốc độ trang và hiệu quả ngân sách thu thập thông tin, kích thước và số lượng yêu cầu quan trọng hơn thứ tự tải tài nguyên.

Bạn có thể tăng tốc độ tải trang của mình nhiều hơn bằng cách giảm kích thước yêu cầu so với việc thay đổi thứ tự tải. Bạn có thể thay đổi kích thước yêu cầu bằng cách tạo các gói tài nguyên và các phần JavaScript, đồng thời ngăn chặn việc tải mã không cần thiết. Nếu bạn tải lên mọi tệp JS cho mỗi danh mục, bạn sẽ tạo ra một gánh nặng không cần thiết cho khách hàng của mình. Bạn có thể sử dụng Webpack được tạo bởi Google hoặc Babel để tạo ra các phần JavaScript. Bạn có thể tải xuống chỉ những phần cần thiết từ các gói JS bằng cách này. Để tạo phần JS hiệu quả hơn, bạn cũng có thể muốn sử dụng Trình biên dịch Closure của Google.

Các Tệp JavaScript được Liên kết với Trình theo dõi-Quảng cáo của Người dùng Bên thứ Ba

Các công cụ của bên thứ ba đóng góp đáng kể vào các vấn đề về kích thước và số lượng tài nguyên, ảnh hưởng đến tốc độ, trải nghiệm người dùng và ngân sách thu thập thông tin. Tất cả các công cụ của bên thứ ba, bao gồm Google Tag Manager, Doubleclicks, Google Analytics, Yandex Metrica hoặc Google AdSense, đều có thể gây ra các vấn đề với người dùng có kết nối internet chậm và điện thoại cấp thấp hoặc trung bình. Chúng cũng chịu trách nhiệm cho các vấn đề về trải nghiệm người dùng và có thể là gánh nặng cho các công cụ tìm kiếm về mặt ngân sách thu thập thông tin.

Bạn không nên sử dụng các công cụ của bên thứ ba làm lý do để chặn kết xuất trong khi thực hiện kết xuất phía máy khách, ngay cả cho mục đích đo lường và thu thập dữ liệu. Nếu đặt các công cụ của bên thứ ba trước các tệp CSS và JS quan trọng của bạn, thì tốc độ trang, ngân sách thu thập thông tin và tỷ lệ chuyển đổi của bạn sẽ bị ảnh hưởng tiêu cực và thời gian tải trang của bạn sẽ tăng lên, gây thêm tải cho cả người dùng và máy chủ của bạn.

Ảnh chụp màn hình từ Google Canary và kết quả thử nghiệm mẫu

Vì lý do này, Google đã ra mắt Bản thử nghiệm Quảng cáo Nhà xuất bản (Publisher Ads Beta) bằng cách đặt Công cụ Quảng cáo Nhà xuất bản (Publisher Ads Tools) trong Chrome Canary. Do đó, Google đã đưa thiết kế công cụ này vào Chrome Updates, cung cấp các đề xuất cần thiết để vừa tải thẻ quảng cáo nhanh hơn, vừa ngăn các thẻ quảng cáo vượt lên trước các phần chức năng của trang.

Chặn các tệp JS không cần thiết để Googlebot cải thiện Ngân sách Thu thập dữ liệu (Crawl Budget)

Mặc dù phần lớn chúng ta đang nói về việc tối ưu hóa cho người dùng, bạn cũng có thể tối ưu hóa việc tải tài nguyên cho Googlebot.

Khi tôi hỏi John Mueller trong Google Webmaster Hangout rằng liệu việc chặn quảng cáo thông qua tệp robots.txt có phải là một vấn đề hay không, tôi đã nhận được câu trả lời rõ ràng là “không”.

Điều này có nghĩa là nếu bạn không thể xóa tất cả các tài nguyên không cần thiết cho Googlebot khỏi trang web của mình bằng các phương pháp như kết xuất động (dynamic rendering), bạn có thể chặn cả tệp quảng cáo và tất cả tài nguyên JS chạy ở định dạng do người dùng kích hoạt thông qua tệp robots.txt.

Googlebot không quan tâm đến các tài nguyên này trừ khi nó ảnh hưởng đến bố cục và nội dung. Ngoài ra, sau khi chặn quảng cáo, bạn có thể đánh dấu chúng bằng thẻ <meta name="robots" content="noindex"> trong semantic HTML nếu muốn.

Bạn có thể thấy tác động và chi phí của mã JavaScript bên thứ ba trong biểu đồ này. Chi phí trung bình và mức độ ảnh hưởng trung bình quá cao đối với Google/DoubleClick, YouTube, Facebook, Hotjar và các loại thực thể theo dõi/quảng cáo khác. Để tìm hiểu thêm: 3rd Web Today

Kết xuất động (Dynamic rendering) cũng là một chủ đề quan trọng khác. Bạn có thể loại bỏ tất cả các tệp JavaScript bên thứ ba, tệp quảng cáo và tệp JS được kích hoạt do người dùng khỏi các trang web của mình cùng với mã CSS/JS không sử dụng.

Đây là một lược đồ kết xuất động (dynamic rendering). Các đường màu đen đại diện cho người gửi yêu cầu, màu vàng cho phản hồi của người dùng, màu xanh cho phản hồi của trình thu thập dữ liệu.

Bạn có thể tự động hóa việc này với Rendertron hoặc Puppeteer (Bạn có thể thực hành tại đây: https://codelabs.developers.google.com/codelabs/dynamic-rendering/#0) và cung cấp trang sạch này chỉ cho các trình thu thập dữ liệu của công cụ tìm kiếm bằng tính năng phân phối nội dung động. Hầu hết các trang web sẽ nhận thấy mức tăng lưu lượng truy cập tự nhiên từ 15% -25% chỉ trong một ngày với sự kết hợp giữa các phương thức kết xuất khác nhau này, đặc biệt nếu họ gặp vấn đề về ngân sách thu thập/kết xuất.

Tốc độ ảnh hưởng như thế nào đến trải nghiệm người dùng (UX) … và ngân sách thu thập dữ liệu Sự giao thoa giữa tốc độ trang web với SEO/UX là một chủ đề thuộc phạm vi khoa học hiệu suất web.

Con người có thể nhận ra một khung hình sau mỗi 16 mili giây (MS). Mọi trình duyệt cần 6 MS để bắt đầu một hoạt ảnh mới. Vì vậy, bạn cần tạo một khung hình sau mỗi 10 MS. Nếu trang web bị đứng hình chỉ trong 50 MS, mọi người sẽ nhận ra nhưng không quá bận tâm; nếu là 100 MS trở lên, họ sẽ thấy có gì đó không ổn. Hơn 300 MS, và họ cho rằng chất lượng của trang web không tốt.

Theo các thí nghiệm về hành vi duyệt web của Google, mọi người mất tập trung sau 2 giây chờ đợi trên một trang web thương mại điện tử. Nếu người dùng phải chờ đợi hơn 2 giây trên một trang web chỉ cho một quá trình tải đơn giản, mức độ căng thẳng của họ tăng lên như thể họ đang ở trong một cuộc chiến thực sự.

Khi đề cập đến tốc độ trang web, có vô số chủ đề nhỏ hơn, chẳng hạn như sự khác biệt giữa Gzip, Deflate, Brotli hoặc xung đột JavaScript, breakpoint, trình nghe sự kiện và trình xử lý sự kiện, dịch vụ siêu nhỏ, cấu trúc N tầng, v.v.

Nhanh hơn trong việc tải xuống, nhiều thời gian/tài nguyên hơn để thu thập dữ liệu.

Thời gian người dùng tải trang càng lâu thì số trang họ truy cập sẽ càng ít. Điều này cũng đúng với Googlebot hoặc các trình thu thập dữ liệu của công cụ tìm kiếm khác. Việc này ảnh hưởng đến cả ngân sách thu thập dữ liệu của bạn lẫn chi phí, thông tin bạn tạo ra cho các công cụ tìm kiếm trên trang web của mình, đồng thời làm giảm tỷ lệ chuyển đổi của bạn.

Hãy thử theo dõi các tệp nhật ký (log files) của một trang web cụ thể đối với Googlebot sau khi bạn giảm kích thước và tăng tốc độ của nó. Bạn sẽ thấy mối tương quan giữa tần suất thu thập dữ liệu và thứ hạng từ khóa được cải thiện.

Tôi sẽ kết thúc chủ đề này, vốn đã được tôi nghiên cứu ở phạm vi rộng nhất có thể trong loạt bài viết, bằng một phép tính đơn giản về ngân sách thu thập dữ liệu và tỷ lệ chuyển đổi:

Nếu bạn giảm thời gian tải trung bình của một trang web chỉ 200 mili giây (MS), điều đó có nghĩa là Googlebot có thể hoàn thành yêu cầu thu thập dữ liệu của nó sớm hơn 200 MS. Nếu bạn là một trang web thương mại điện tử với 2 triệu URL và Googlebot thực hiện tổng cộng 1,5 triệu yêu cầu cho trang web của bạn mỗi tháng, điều này sẽ cộng dồn thành tiết kiệm được 300.000.000 MS. 300.000.000 MS tương đương với 83.333,333 giờ. Tức 3.472 ngày.

Nói cách khác, bạn có thể tác động đáng kể đến tốc độ duyệt web, lập chỉ mục và hiệu suất SEO của toàn bộ trang web bằng một phép tính lý thuyết mà bạn chỉ cần tối ưu cho 200 MS.

Bạn cũng có thể khám phá mức tăng tỷ lệ chuyển đổi thương mại điện tử mà 200 MS sẽ tạo ra cho bạn bằng các công thức hồi quy tuyến tính.

Trong SEO, bạn đang chạy đua với từng mili giây. Một ví dụ về một trang web tải qua kết nối 3G chậm

Cuối cùng, tôi tin chắc rằng nếu không biết đọc mã code và không quen thuộc với các thuật ngữ dành cho nhà phát triển, chúng ta không thể tạo ra những phép màu SEO nữa. Và, tôi nghĩ, trong năm nay hoặc năm sau, biết cách lập trình bằng nhiều ngôn ngữ sẽ trở thành yêu cầu cơ bản đối với công việc SEO toàn diện. Và tất nhiên, tôi thậm chí không thể hình dung ra một hồ sơ SEO mà không có tầm nhìn tổng thể bao gồm sự hiểu biết về các lĩnh vực tiếp thị kỹ thuật số khác nhau. SEO đang thay đổi, và SEO-er cũng sẽ thay đổi theo.