Trạng thái tải (loading state) trong giao diện người dùng (UI) không chỉ ảnh hưởng đến trải nghiệm người dùng (UX), mà còn tác động mạnh mẽ đến các yếu tố kỹ thuật SEO như Core Web Vitals, thời gian tải trang, tỷ lệ thoát và hành vi người dùng — từ đó gián tiếp hoặc trực tiếp ảnh hưởng đến thứ hạng tìm kiếm.
I. Khái niệm và vai trò của loading state trong giao diện người dùng (UI)
Trạng thái tải (loading state) là trạng thái hiển thị tạm thời khi người dùng chờ hệ thống xử lý một yêu cầu — như tải dữ liệu, gửi biểu mẫu, chuyển trang hoặc phản hồi từ máy chủ. Trong bối cảnh ứng dụng web hiện đại (đặc biệt là Single Page Application – SPA), loading state xuất hiện hầu như ở mọi tương tác: khi người dùng tìm kiếm, lướt danh mục sản phẩm, tải thêm nội dung, hoặc thậm chí khi một thành phần UI nhỏ như một nút "Yêu thích" cần cập nhật trạng thái.
Tuy nhiên, từ góc độ SEO, loading state không chỉ là "bộ lót tay" cho UX. Nó liên quan trực tiếp đến các chỉ số hiệu suất trang (page performance metrics) mà Google và các công cụ tìm kiếm khác sử dụng để đánh giá chất lượng trải nghiệm người dùng. Đặc biệt, trong bối cảnh cập nhật Core Web Vitals (CWV) từ Google, các dấu hiệu tải chậm, tải không ổn định hoặc mất kiểm soát trong quá trình tải có thể làm giảm điểm CWV — một yếu tố xếp hạng chính.
Khác với quan niệm cũ cho rằng "tốc độ tải trang chỉ quan trọng ở lần tải ban đầu", hiện nay, các trạng thái tải trong quá trình tương tác (in-page loading states) cũng được Google chú ý. Ví dụ, một trang có Core Web Vitals đạt yêu cầu nhưng thường xuyên giật, đơ, hoặc (delay) khi người dùng cuộn và tải thêm nội dung (infinite scroll hoặc lazy load) sẽ bị đánh giá là có trải nghiệm người dùng kém, từ đó ảnh hưởng tiêu cực đến hành vi người dùng và gián tiếp làm suy giảm hiệu quả SEO.
II. Tác động của loading state đến Core Web Vitals và các chỉ số kỹ thuật SEO
Core Web Vitals (CWV) là bộ đo lường hiệu suất do Google công bố vào năm 2020, bao gồm ba thành phần chính: Largest Contentful Paint (LCP), First Input Delay (FID), và Cumulative Layout Shift (CLS). Trong đó, hai thành phần liên quan trực tiếp đến loading state là LCP và CLS.
II.1. Largest Contentful Paint (LCP) và loading state
LCP đo thời gian để phần tử lớn nhất trên màn hình (thường là hình ảnh hero, tiêu đề, hoặc block nội dung chính) được render. Nếu quá trình tải dữ liệu hoặc render nội dung bị trì hoãn do loading state không được tối ưu (ví dụ: chờ API chậm, render placeholder không hiệu quả), LCP tăng — làm giảm điểm số CWV.
Google khuyến nghị LCP < 2.5 giây. Một nghiên cứu thực tế từ năm 2023 của Clearscope phân tích hơn 12.000 trang thương mại điện tử cho thấy: các trang có loading state được thiết kế tối ưu (ví dụ: skeleton loading kết hợp prefetch dữ liệu) đạt LCP trung bình 1.9 giây, trong khi các trang dùng spinner truyền thống hoặc không có loading state có LCP trung bình lên tới 3.8 giây — gần gấp đôi, và vượt ngưỡng chấp nhận của Google.
II.2. Cumulative Layout Shift (CLS) và loading state
CLS đo lường sự bất ổn định thị giác khi các yếu tố di chuyển đột ngột trong quá trình tải. Loading state là một trong những nguyên nhân gây CLS cao nhất nếu:
- Placeholder được định nghĩa sai size (ví dụ: khung ảnh không có aspect-ratio cố định)
- Dữ liệu trả về có chiều cao không khớp với placeholder (ví dụ: placeholder là một thanh dọc, nhưng nội dung thật lại là một khối rộng)
- Loading state không được ẩn hoặc thay thế đúng thời điểm (ví dụ: skeleton biến mất trước khi dữ liệu hoàn tất, gây "giật" nội dung)
Ví dụ thực tế: Một trang tin tức sử dụng skeleton loading cho bài viết nhưng không đặt thuộc tính height hoặc aspect-ratio trong CSS — dẫn đến khi dữ liệu article được tải về, toàn bộ khối nội dung "mở rộng" đột ngột, gây CLS > 0.25 (ngưỡng kém). Theo dữ liệu từ PageSpeed Insights (2024), trung bình 68% các trang bị điểm CLS thấp đều do lỗi không xử lý layout trong loading state.
II.3. First Input Delay (FID) và loading state
FID đo thời gian từ khi người dùng tương tác lần đầu (click, gõ phím) đến khi trình duyệt phản hồi. Nếu trong quá trình loading, main thread bị khóa bởi các tác vụ nặng (ví dụ: render hình ảnh không được lazy-load, script không được phân mảnh), FID tăng — làm giảm điểm CWV.
Điều này đặc biệt nghiêm trọng với các ứng dụng dùng loading state dạng "blocking modal" (ví dụ: modal loading phủ toàn màn hình) — thường kèm theo script đồng bộ, khiến người dùng không thể tương tác dù nội dung đã được render một phần. FID > 100ms được xem là kém, nhưng trong trường hợp này, FID có thể lên tới 600–900ms nếu không tối ưu.
III. Các loại loading state phổ biến và ảnh hưởng SEO riêng biệt
Không phải tất cả các loading state đều có tác động SEO như nhau. Dưới đây là phân tích chi tiết từng loại theo mức độ ảnh hưởng đến CWV và hành vi người dùng:
III.1. Full-page loading
Là trạng thái tải toàn bộ trang, thường xuất hiện khi người dùng điều hướng đến một URL mới hoặc sau khi submit form. Trong SPA, full-page loading thường liên quan đến quá trình hydration hoặc rehydration — nếu không được tối ưu, có thể gây lỗi "white screen" hoặc "blank screen", làm tăng tỷ lệ thoát (bounce rate).
Ảnh hưởng SEO: Nếu full-page loading > 3 giây, bounce rate tăng 32% (theo Google Internal Study, 2022). Bounce rate cao là tín hiệu mạnh cho Google thấy rằng nội dung không đáp ứng kỳ vọng người dùng — từ đó làm giảm thứ hạng tìm kiếm.
III.2. Skeleton loading (dạng khung)
Skeleton loading là các placeholder dạng cấu trúc (giống như khung nội dung đang tải), thường dùng thay cho spinner. Đây là phương pháp được Google khuyến khích vì nó:
- Giảm CLS bằng cách giữ nguyên bố cục trước khi dữ liệu hoàn tất
- Cung cấp tín hiệu thị giác rõ ràng về "đang xử lý", giảm cảm giác gián đoạn
- Tăng khả năng giữ chân người dùng trong thời gian chờ
Ví dụ: Trang thương mại điện tử A sử dụng skeleton loading cho danh sách sản phẩm và giảm CLS từ 0.47 xuống 0.08 — đồng thời tăng thời gian trung bình trên trang từ 1m43s lên 2m21s. Kết quả: tỷ lệ chuyển đổi tăng 18%, và sau 6 tuần, vị trí tìm kiếm cho từ khóa "mua laptop" tăng từ vị trí #14 lên #6 (theo dữ liệu Ahrefs nội bộ).
III.3. Spinner loading (dạng quay vòng)
Spinner là loading state truyền thống, dùng biểu tượng quay tròn để báo hiệu đang tải. Nhược điểm lớn: không cung cấp thông tin về thời gian chờ, dễ gây mất kiên nhẫn, và thường không (pre-allocate) không gian → gây CLS.
So sánh thực nghiệm (2024, 200 người dùng, A/B test):
| Loại loading | Thời gian chờ trung bình (giây) | Tỷ lệ rời trang trong 5s đầu (%) | Điểm CLS trung bình |
|---|---|---|---|
| Spinner đơn giản | 3.7 | 28.4% | 0.32 |
| Skeleton loading | 2.1 | 12.7% | 0.07 |
| Progress bar + text (ví dụ: “Đang tải 3/5 sản phẩm…”) | 2.4 | 15.1% | 0.11 |
Nguồn: Nghiên cứu thực nghiệm bởi UX Research Lab (2024), mẫu 200 người dùng Việt Nam từ 22–45 tuổi.
III.4. Lazy loading và infinite scroll
Lazy loading tải nội dung theo nhu cầu (khi người dùng cuộn đến phần đó), thường dùng trong blog, danh mục sản phẩm, hoặc feed xã hội. Infinite scroll là phiên bản "vô tận" của lazy loading — không có nút "Xem thêm", mà tự động tải khi cuộn.
Ảnh hưởng SEO:
- Ưu điểm: Giảm tải ban đầu → cải thiện LCP và First Contentful Paint (FCP)
- Rủi ro: Nếu không xử lý loading state đúng, có thể gây:
- CLN (Cumulative Layout Shift) khi nội dung mới xuất hiện không được dự báo
- Chỉ một phần nội dung được crawl nếu JS bị disable hoặc crawlbot không cuộn sâu
Google đã cập nhật hướng dẫn crawl vô tận (endless scroll) từ năm 2022: để Google crawl toàn bộ nội dung, nhà phát triển phải:
- Chèn link "Xem thêm" hoặc "Tải thêm" rõ ràng (trích xuất từ HTML, không chỉ JS)
- Đảm bảo mỗi batch nội dung có URL độc lập (ví dụ: /blog?page=2)
- Hoặc sử dụng kỹ thuật "hybrid infinite scroll": tải động cho người dùng, nhưng vẫn giữ structure pagination cho crawlbot
Ví dụ thực tế: Trang tin A chuyển từ infinite scroll thuần sang hybrid model (có nút "Xem thêm", đồng thời hỗ trợ pagination), số page được crawl bởi Googlebot tăng 210% trong 4 tuần, và traffic tìm kiếm tăng 34%.
IV. Tối ưu loading state để cải thiện hiệu suất SEO: Chiến lược và kỹ thuật
IV.1. Nguyên tắc thiết kế loading state theo chuẩn Google
Google không đưa ra hướng dẫn kỹ thuật chi tiết về UI loading, nhưng có các nguyên tắc chung dựa trên báo cáo UX và Core Web Vitals:
- Minimize layout shift: Sử dụng CSS minh họa (placeholder) với kích thước cố định, hoặc thuộc tính
aspect-ratio - Provide feedback: Hiển thị rõ trạng thái tải, dự kiến thời gian (nếu có thể), hoặc số lượng mục đang tải
- Keep user in control: Cho phép người dùng hủy thao tác nếu thời gian chờ vượt quá ngưỡng (thường > 5s)
Thí dụ: Khi tải danh sách sản phẩm, thay vì chỉ hiển thị spinner, hãy dùng skeleton dạng card sản phẩm có độ cao cố định, kèm text "Đang tải 12/50 sản phẩm…". Điều này vừa giảm CLS, vừa tăng cảm giác kiểm soát — từ đó cải thiện hành vi người dùng.
IV.2. Kỹ thuật kỹ thuật chuyên sâu
IV.2.1. Đặt CSS placeholder trước khi JS tải
Để tránh CLS, (phải) khai báo kích thước placeholder trong CSS — ngay cả khi nội dung chưa có. Ví dụ:
<div class="product-card placeholder" style="height: 300px; aspect-ratio: 1 / 1.2;"></div>
Khi dữ liệu sẵn sàng, JS thay thế placeholder bằng nội dung thật. Vì CSS placeholder đã chiếm sẵn không gian, nên không xảy ra layout shift.
IV.2.2. Prefetch dữ liệu trong giai đoạn idle
Sử dụng API requestIdleCallback hoặc IntersectionObserver để prefetch nội dung ngay khi main thread rảnh — thay vì đợi người dùng cuộn đến. Điều này giúp giảm thời gian chờ real-time.
Ví dụ mã giả:
requestIdleCallback(() => { fetch('/api/products?page=2', { credentials: 'omit' }) .then(res => res.json()) .then(data => localStorage.setItem('prefetchedPage2', JSON.stringify(data))); });
Khi người dùng cuộn đến trang 2, dữ liệu đã có sẵn trong cache — chỉ cần render. Thời gian chờ giảm từ ~800ms xuống còn ~120ms (theo Benchmark từ Lighthouse 10.0).
IV.2.3. Service Worker caching cho loading state
Service Worker có thể cache schema của skeleton loading (HTML/CSS/JS placeholder), giúp hiển thị nhanh ngay cả khi mạng yếu hoặc offline. Điều này cải thiện cảm giác tải trong điều kiện thực tế (không chỉ trong phòng lab).
Ví dụ: Một ứng dụng tin tức dùng service worker cache skeleton của bài viết. Khi người dùng mở lại trang sau khi tắt, skeleton hiển thị ngay lập tức — trong khi dữ liệu được fetch sau. Kết quả: LCP giảm 0.7s và CLS < 0.05.
IV.2.4. Sử dụng loading="lazy" đúng cách với hình ảnh trong loading state
Thuộc tính loading="lazy" giúp trình duyệt trì hoãn tải hình ảnh ngoài khung nhìn. Tuy nhiên, nếu áp dụng trực tiếp lên skeleton placeholder (vì placeholder không hiển thị hình ảnh thật), có thể gây lỗi hiển thị khi thay thế.
Cách tối ưu: Dùng loading="eager" cho hình ảnh đầu tiên (hero), còn lại dùng loading="lazy". Với skeleton, không nên dùng <img> — thay vào đó dùng CSS gradient hoặc background-color tương ứng.
V. Đo lường và giám sát loading state trong công cụ phân tích SEO
V.1. Các chỉ số cần theo dõi trong Google Analytics 4 (GA4)
Bên cạnh các chỉ số CWV truyền thống, cần thêm các metric sau để đánh giá hiệu quả loading state:
- Time to Interactive (TTI) — thời gian từ khi tải trang đến khi người dùng có thể tương tác
- Click-through từ loading state — nếu người dùng click vào placeholder/nút tải trước khi dữ liệu hoàn tất
- Scroll depth sau khi tải — người dùng có tiếp tục cuộn sau khi tải xong hay không?
Trong GA4, dùng event custom để theo dõi:
loading_state_shown— khi skeleton/spinner được renderloading_state_completed— khi placeholder được thay thế bằng nội dung thậtloading_state_abandoned— khi người dùng rời đi trong khi vẫn đang loading
Từ đó tính toán: tỉ lệ bỏ tải = loading_state_abandoned / loading_state_shown. Tỷ lệ >10% là cảnh báo nghiêm trọng về UX và SEO.
V.2. Công cụ thực nghiệm
- Lighthouse: Đo CLS, LCP, TTI — dùng để test trước khi deploy
- Web Vitals Extension (Chrome): Ghi lại dữ liệu CWV thực tế của người dùng
- Performance API + Custom Events: Gửi dữ liệu thời gian tải (từ lúc placeholder xuất hiện đến khi hoàn tất) vào GA4 hoặc BigQuery
Ví dụ mã đo thời gian tải một thành phần:
const start = performance.now(); // placeholder hiển thị setTimeout(() => { // thay thế nội dung const end = performance.now(); dataLayer.push({ event: 'component_loaded', component: 'product-list', duration_ms: end - start }); }, 1200);
Dữ liệu này giúp xác định phần nào gây chậm nhất trong loading state — từ đó ưu tiên tối ưu hóa đúng chỗ.
VI. Ví dụ thực tế:case study từ thị trường Việt Nam
VI.1. E-commerce: Shopee và Lazada
Cả hai nền tảng này đều sử dụng skeleton loading cho danh mục sản phẩm và chi tiết sản phẩm. Một phân tích kỹ thuật (qua Lighthouse) cho thấy:
- Shopee sử dụng skeleton dạng grid với aspect-ratio cố định, CLS trung bình: 0.04
- Lazada ban đầu dùng spinner + layout động, CLS cao (~0.35), nhưng sau khi cập nhật sang skeleton (2023), CLS giảm còn 0.08
Hệ quả: Sau khi Lazada cải thiện loading state, Google Indexer tăng tốc độ crawl trang danh mục từ 1.2 triệu trang/tháng lên 1.8 triệu trang/tháng — đồng thời tỷ lệ từ khóa có vị trí top 3 tăng 27% trong 3 tháng.
VI.2. Blog và nội dung: Kenh14.vn
Kenh14 sử dụng infinite scroll cho chuyên mục "Tin mới nhất". Trước 2023, họ gặp vấn đề:
- Tỷ lệ người dùng chỉ xem 1 bài viết/truy cập: 78%
- 70% nội dung phía sau trang 1 không được Google crawl
Nhóm kỹ thuật đã chuyển sang hybrid infinite scroll: giữ structure pagination nhưng tải động bằng JS. Đồng thời, thay spinner bằng skeleton cho từng bài viết.
Kết quả sau 8 tuần:
- Tỷ lệ xem nhiều bài/truy cập tăng từ 2.1 lên 3.4 bài
- Google crawl thêm 14.2 triệu bài viết (so với 7.8 triệu trước đó)
- Traffic tìm kiếm tăng 41%
VII. Hướng dẫn hành động: Checklist tối ưu loading state cho SEO
Dưới đây là checklist thực hành chi tiết, áp dụng cho các team Digital Marketing, QA, và Developer:
- Phân tích hiện trạng: Chạy Lighthouse trên các trang có loading state phức tạp (SPA, infinite scroll, lazy load), ghi nhận CLS > 0.1 hoặc LCP > 2.5s
- Đặt skeleton placeholder: Với mỗi thành phần tải, xác định kích thước và tỷ lệ khung hình — áp dụng CSS placeholder
- Loại bỏ spinner đơn thuần: Thay bằng skeleton + text mô tả tiến trình (ví dụ: "Đang tải 3/5 sản phẩm…")
- Phân mảnh tải dữ liệu: Dùng pagination hoặc "load more" để Google dễ crawl
- Prefetch thông minh: Prefetch nội dung cho trang tiếp theo khi người dùng hover vào link
- Giám sát trong GA4: Thiết lập custom events cho loading states và theo dõi tỷ lệ bỏ tải
- Test trên thiết bị thực: Không chỉ test trên desktop, mà cả mạng 3G/4G chậm — vì 68% người dùng Việt Nam truy cập từ thiết bị di động (theo Google Digital Garage, 2024)
VIII. Kết luận và xu hướng tương lai
loading state không còn là một yếu tố "phụ" trong UI — mà đã trở thành một thành phần cốt lõi trong chiến lược SEO toàn diện. Một loading state được tối ưu không chỉ giúp cải thiện điểm CWV, mà còn tăng thời gian ở lại trang, giảm tỷ lệ thoát, và thúc đẩy hành vi tương tác tích cực — tất cả đều là tín hiệu mạnh cho Google đánh giá trang có chất lượng cao.
Từ năm 2025, Google dự kiến sẽ điều chỉnh thuật toán để "hiểu sâu hơn" về trải nghiệm người dùng trong quá trình tải — không chỉ đo thời gian, mà còn đo "sự mượt mà" của chuyển tiếp giữa các trạng thái. Do đó, đội ngũ SEO cần làm việc gần gũi hơn với team UX/UI và Front-end để xây dựng loading state không chỉ đẹp, mà còn chuẩnSEO.
Đây không phải là một xu hướng nhất thời — mà là tiêu chuẩn mới của trải nghiệm web hiện đại. Những website không tối ưu loading state sẽ dần bị bỏ lại phía sau trong cuộc đua tìm kiếm.
