Text/HTML ratio là gì? Cách tối ưu Text/HTML chuẩn

Text/HTML Ratio là tỷ lệ ước tính giữa lượng văn bản mà một công cụ trích xuất được và dung lượng mã HTML của một trang. Chỉ số này có thể giúp gợi ý rằng trang đang có ít nội dung, HTML response quá lớn hoặc cấu trúc DOM phức tạp, nhưng không phải yếu tố xếp hạng trực tiếp của Google và cũng không có ngưỡng SEO chuẩn như 15%, 25%, 40% hay 70%.

Hai trang có cùng tỷ lệ Text/HTML vẫn có thể khác nhau hoàn toàn về chất lượng. Một trang sản phẩm ngắn nhưng có thông tin rõ, hình ảnh, giá, đánh giá và chức năng mua hàng có thể phục vụ người dùng tốt hơn một bài viết dài được thêm chữ chỉ để nâng tỷ lệ. Ngược lại, một trang có tỷ lệ cao vẫn có thể tải chậm vì hình ảnh, JavaScript, font hoặc tài nguyên bên thứ ba.

Do đó, không nên sửa website theo mục tiêu “làm xanh Text/HTML Ratio”. Cần xác định cảnh báo xuất phát từ nội dung mỏng, HTML response lớn, DOM quá nhiều node, dữ liệu hydration, mã inline, plugin tạo markup thừa hay chỉ do cách công cụ tính. Bài viết này trình bày cách kiểm tra và xử lý theo từng nguyên nhân.

Text/HTML Ratio là gì?

Text/HTML Ratio là tỷ lệ phần trăm giữa lượng văn bản được một công cụ xác định là nội dung và dung lượng mã HTML dùng để tạo tài liệu. Công thức khái quát thường được viết như sau:

Text/HTML Ratio = Dung lượng văn bản / Dung lượng HTML × 100%

Ví dụ, nếu công cụ ghi nhận phần văn bản có dung lượng 20 KB và tài liệu HTML có dung lượng 100 KB, tỷ lệ được báo cáo là 20%.

Tuy nhiên, con số này chỉ có ý nghĩa khi biết công cụ đang đo:

• HTML response ban đầu hay DOM sau khi JavaScript chạy.
• Văn bản trong toàn bộ tài liệu hay chỉ phần nội dung chính.
• Số ký tự, số byte hay số từ.
• Dung lượng trước hay sau nén Gzip/Brotli.
• Có tính text ẩn, menu, footer, cookie banner và dữ liệu có cấu trúc hay không.
• Có loại bỏ script, style, SVG, comment và thuộc tính HTML hay không.

Vì không có phương pháp tính thống nhất, hai công cụ có thể trả kết quả khác nhau cho cùng một URL. Text/HTML Ratio nên được xem là chỉ số do công cụ SEO tự xây dựng, không phải tiêu chuẩn HTML hoặc chỉ số chính thức của Google Search.

Có tỷ lệ Text/HTML chuẩn cho SEO không?

Không có ngưỡng chuẩn được Google, WHATWG, W3C hoặc Chrome công bố. Những mốc như “không dưới 15%”, “lý tưởng 25–70%”, “blog phải trên 40%” thường là quy ước của công cụ hoặc kinh nghiệm cá nhân, không phải yêu cầu xếp hạng.

Một ngưỡng phần trăm chung không phù hợp vì mỗi loại trang có mục đích khác nhau:

Thay vì hỏi “tỷ lệ bao nhiêu là tốt?”, hãy hỏi:

• Trang có đáp ứng đúng nhu cầu người dùng không?
• Nội dung chính có hiện diện trong HTML hoặc DOM được render không?
• HTML response có lớn bất thường không?
• DOM có nhiều node không cần thiết không?
• Tài nguyên CSS, JavaScript và hình ảnh có gây chậm không?
• Googlebot có truy cập, render và lập chỉ mục được nội dung không?

Text/HTML Ratio có phải yếu tố xếp hạng Google không?

Google không liệt kê Text/HTML Ratio trong tài liệu về hệ thống xếp hạng, Search Essentials, Core Web Vitals hoặc metadata được hỗ trợ. Không có cơ sở để coi một tỷ lệ cụ thể là tín hiệu trực tiếp giúp từ khóa tăng hoặc giảm thứ hạng.

Google tập trung vào việc cung cấp nội dung hữu ích, đáng tin cậy, dễ truy cập và có trải nghiệm phù hợp. Một công cụ audit có thể cảnh báo tỷ lệ thấp vì nó dùng bộ quy tắc riêng, nhưng cảnh báo đó không có nghĩa Google đã áp dụng hình phạt.

Ảnh hưởng đến SEO chỉ có thể xuất hiện gián tiếp nếu tỷ lệ thấp là biểu hiện của một vấn đề thật, chẳng hạn:

• Nội dung chính quá ít so với nhu cầu tìm kiếm.
• HTML đầu ra chứa lượng dữ liệu hoặc markup lớn không cần thiết.
• DOM phức tạp làm tăng chi phí style, layout và tương tác.
• Nội dung chỉ xuất hiện sau JavaScript nhưng quá trình render gặp lỗi.
• Website chậm, thiếu ổn định hoặc khó sử dụng trên thiết bị thật.
• Template tạo hàng loạt trang ít giá trị.

Trong các trường hợp trên, cần sửa vấn đề gốc. Việc nâng tỷ lệ từ 12% lên 25% không phải mục tiêu SEO nếu trang vẫn chậm, nội dung không hữu ích hoặc conversion bị lỗi.

Text/HTML Ratio có ảnh hưởng crawl budget không?

Không nên khẳng định code HTML nhiều sẽ trực tiếp “làm cạn crawl budget”. Google định nghĩa crawl budget là số URL Googlebot có thể và muốn thu thập, dựa trên crawl capacity và crawl demand. Vấn đề này chủ yếu quan trọng với website rất lớn, thay đổi nhanh hoặc tạo nhiều URL.

HTML response rất lớn có thể làm tăng lượng dữ liệu cần tải và xử lý, nhưng tỷ lệ text thấp không cho biết crawl budget đang bị lãng phí. Một trang có 10% text nhưng HTML chỉ 40 KB có thể nhẹ hơn trang có 50% text nhưng HTML 500 KB.

Tài liệu Googlebot hiện hành nêu Google Search thu thập phần đầu tiên khoảng 2 MB của các loại tệp được hỗ trợ; mỗi tài nguyên CSS hoặc JavaScript được tham chiếu cũng được lấy riêng và chịu giới hạn tương ứng. Đây là giới hạn kích thước tệp, không phải ngưỡng Text/HTML Ratio.

Nếu HTML gần hoặc vượt mức megabyte, cần điều tra vì đó là trường hợp bất thường đối với phần lớn trang nội dung. Tuy nhiên, việc bài mới chậm index thường liên quan nhiều yếu tố khác:

• Internal link yếu.
• Sitemap chưa cập nhật.
• Server lỗi hoặc phản hồi chậm.
• Canonical, noindex hoặc robots cấu hình sai.
• Nội dung trùng lặp hoặc ít nhu cầu crawl.
• Không gian URL quá lớn.
• JavaScript render lỗi.

Text/HTML Ratio có phản ánh tốc độ tải trang không?

Không trực tiếp. HTML chỉ là một phần của tổng tải trang. Theo Web Almanac 2025, trang desktop trung vị có tổng dung lượng khoảng 2,9 MB; trang chủ mobile trung vị khoảng 2,6 MB. Phần lớn tăng trưởng dung lượng đến từ hình ảnh và JavaScript, còn HTML thường chỉ chiếm phần nhỏ.

Một trang có tỷ lệ Text/HTML cao vẫn có thể tải chậm vì:

• Ảnh hero vài megabyte.
• Video hoặc iframe bên thứ ba.
• JavaScript thực thi lâu.
• Font tải nhiều weight.
• Server phản hồi chậm.
• Quảng cáo và tracking.
• CSS chặn render.

Một trang có tỷ lệ thấp vẫn có thể tải nhanh nếu HTML nhỏ, được nén, cache tốt và tài nguyên được tối ưu.

HTML transfer size khác HTML resource size

Trong DevTools, cần phân biệt:

• Resource size: Dung lượng nội dung trước nén hoặc kích thước tài nguyên logic.
• Transferred: Số byte truyền qua mạng sau cache và nén.
• DOM size: Số node sau khi trình duyệt phân tích HTML và JavaScript thay đổi tài liệu.
• Total page weight: Tổng HTML, CSS, JavaScript, ảnh, font và tài nguyên khác.

Text/HTML Ratio chỉ so sánh hai đại lượng do công cụ lựa chọn. Nó không thay thế các chỉ số trên.

Text/HTML Ratio khác DOM size như thế nào?

HTML là chuỗi mã nguồn; DOM là cây đối tượng được trình duyệt tạo ra sau khi phân tích HTML và thực thi JavaScript. Một đoạn HTML ngắn có thể tạo DOM lớn nếu script sinh thêm nhiều phần tử. Ngược lại, HTML chứa dữ liệu lớn trong script có thể nặng nhưng không tạo nhiều node hiển thị.

Chrome cảnh báo khi phần <body> có khoảng hơn 800 node và coi mức hơn khoảng 1.400 node là nghiêm trọng trong audit “Avoid an excessive DOM size”. Đây là ngưỡng chẩn đoán của Lighthouse, không phải yếu tố xếp hạng hoặc giới hạn cứng.

DOM lớn có thể làm:

• Tăng thời gian tính style và layout.
• Tăng bộ nhớ.
• Làm thao tác DOM chậm hơn.
• Tăng chi phí khi tương tác thay đổi giao diện.
• Làm JavaScript query và cập nhật nhiều phần tử hơn.

Do đó, khi nghi ngờ page builder tạo code bloat, nên kiểm tra DOM node, độ sâu và số phần tử con lớn nhất thay vì chỉ nhìn tỷ lệ text.

Text/HTML Ratio khác thin content như thế nào?

Thin content là khái niệm chất lượng và giá trị, không phải số từ hoặc tỷ lệ byte. Một trang có ít chữ vẫn có thể hữu ích nếu hoàn thành tốt nhiệm vụ, chẳng hạn:

• Máy tính chuyển đổi.
• Trang tra cứu trạng thái đơn hàng.
• Công cụ báo giá.
• Trang liên hệ.
• Trang sản phẩm có dữ liệu rõ và review thật.

Ngược lại, một bài 3.000 từ có thể vẫn mỏng nếu lặp ý, không có bằng chứng, sao chép nguồn khác hoặc không giải quyết câu hỏi.

Không nên viết bài dài hơn 1.000 từ chỉ để nâng Text/HTML Ratio. Google không có chuẩn “bài SEO phải 1.000–2.000 từ”. Độ dài phù hợp phụ thuộc chủ đề, mức phức tạp và mục đích của trang.

Vì sao các công cụ báo Low Text/HTML Ratio?

Nội dung thật sự quá ít

Trang có vài dòng chung chung, không có thông số, giá, quy trình, bằng chứng hoặc câu trả lời cần thiết. Đây là vấn đề nội dung, không phải vấn đề tỷ lệ.

Template lặp lại quá nhiều markup

Header, mega menu, footer, popup, sidebar và block CTA có thể lặp trên mọi URL. Nếu phần nội dung chính ngắn, tỷ lệ giảm dù template hợp lệ.

Page builder tạo nhiều lớp wrapper

Elementor, WPBakery, Divi, Flatsome UX Builder và các builder khác có thể tạo nhiều <div>, thuộc tính, class và dữ liệu cấu hình. Không phải mọi wrapper đều vô ích; một số cần cho layout, responsive và component.

Vấn đề cần xử lý khi:

• Có nhiều container không tạo giá trị bố cục.
• Một component bị lồng nhiều lần do copy block.
• HTML chứa style hoặc cấu hình lặp lại.
• DOM vượt mức chẩn đoán và ảnh hưởng tương tác.
• Template cũ để lại element ẩn không dùng.

Inline CSS và JavaScript lớn

Style, script, JSON hydration, state của framework hoặc dữ liệu theo dõi được chèn trong HTML làm response lớn. Tuy nhiên, không phải mọi inline code đều xấu. Critical CSS nhỏ hoặc dữ liệu cần cho render đầu tiên có thể giảm request và cải thiện tốc độ.

SVG và biểu tượng inline

SVG dài, sprite icon hoặc logo được nhúng trực tiếp sẽ tăng HTML nhưng có thể tránh request riêng. Cần đo tổng thể, không externalize chỉ để nâng ratio.

Dữ liệu có cấu trúc quá lớn

JSON-LD hợp lệ có thể làm HTML lớn hơn. Chỉ nên xuất dữ liệu phản ánh nội dung thật và cần cho loại trang; không sao chép toàn bộ database sản phẩm vào schema.

Nội dung được render bằng JavaScript

Công cụ chỉ đọc raw HTML có thể thấy rất ít text, trong khi trình duyệt sau render có đầy đủ nội dung. Trường hợp này cần kiểm tra Googlebot render được trang hay không, không nên chỉ thêm text vào HTML vì tỷ lệ.

Navigation và bộ lọc phức tạp

Mega menu, bộ lọc thương mại điện tử và danh mục lớn có thể tạo hàng nghìn liên kết hoặc phần tử. Cần tối ưu cấu trúc, phân trang và khả năng crawl thay vì chỉ xóa text hoặc markup.

Comment, whitespace và code cũ

Comment và khoảng trắng tăng kích thước source, nhưng thường được nén rất tốt bằng Gzip/Brotli. Xóa thủ công từng comment có thể mang lại ít giá trị hơn tối ưu ảnh hoặc JavaScript. Minification nên được tự động hóa trong build hoặc cache layer.

Cách kiểm tra Text/HTML Ratio đúng cách

Cách tự tính tỷ lệ để chẩn đoán

Có thể dùng JavaScript trong Console để xem một tỷ lệ ký tự đơn giản:

const htmlLength = document.documentElement.outerHTML.length;
const textLength = document.body.innerText.trim().length;

console.table({
  htmlCharacters: htmlLength,
  visibleTextCharacters: textLength,
  approximateRatio: `${((textLength / htmlLength) * 100).toFixed(2)}%`
});

Kết quả này chỉ là ước tính vì:

• Đo DOM sau render, không phải raw response.
• Đếm ký tự JavaScript, không phải byte mạng.
• innerText phụ thuộc CSS và trạng thái hiển thị.
• Menu, footer và cookie banner vẫn được tính.
• Không phản ánh Gzip, Brotli hoặc cache.

Để xem dung lượng HTML truyền qua mạng:

curl -s -o /dev/null \
  -w "downloaded_bytes=%{size_download}\n" \
  https://example.com/duong-dan

Muốn đánh giá hiệu suất, cần kết hợp với DevTools và Lighthouse thay vì dùng một phép chia đơn giản.

Quy trình xử lý Low Text/HTML Ratio

Trường hợp 1: Nội dung không đủ giá trị

Nếu trang thực sự thiếu thông tin cần thiết, bổ sung theo nhu cầu người dùng:

• Mô tả rõ sản phẩm hoặc dịch vụ.
• Thông số và phạm vi áp dụng.
• Quy trình.
• Giá hoặc cách tính giá.
• Bằng chứng, chứng nhận hoặc case study.
• Chính sách bảo hành, đổi trả và hỗ trợ.
• Câu hỏi thường gặp thực tế.
• CTA phù hợp.

Không đặt mục tiêu số từ. Một dịch vụ viết bài SEO nên nghiên cứu intent, dữ liệu bán hàng và câu hỏi khách hàng để quyết định phạm vi nội dung, không thêm chữ chỉ để làm chỉ số đẹp hơn.

Trường hợp 2: Template và DOM quá phức tạp

Giảm wrapper và component không cần thiết:

• Xóa section, row và column trống.
• Không lồng container chỉ để tạo khoảng cách.
• Dùng CSS Grid hoặc Flexbox thay cho nhiều lớp markup khi phù hợp.
• Giảm mega menu và block footer lặp lại.
• Không render modal, tab hoặc carousel chưa cần.
• Virtualize danh sách rất dài.
• Chỉ tải component theo route hoặc tương tác.

Không được xóa markup làm mất semantic, accessibility hoặc tính năng responsive.

Trường hợp 3: HTML chứa dữ liệu inline lớn

Kiểm tra:

• CSS inline lặp lại theo component.
• JavaScript state hoặc hydration data quá lớn.
• JSON-LD lặp sản phẩm, review hoặc breadcrumb.
• SVG inline phức tạp.
• Dữ liệu debug hoặc source map.
• Danh sách option được render dù chưa dùng.

Giải pháp có thể là thu gọn dữ liệu, chia component, tải theo nhu cầu hoặc chuyển asset dùng chung sang file cache được. Không externalize tất cả code theo một quy tắc máy móc.

Trường hợp 4: CSS và JavaScript không sử dụng

Dùng Coverage và bundler để:

• Loại thư viện không còn dùng.
• Tree-shake module.
• Code-split theo route.
• Chỉ enqueue asset của plugin ở trang cần thiết.
• Tránh tải nhiều phiên bản thư viện.
• Defer hoặc delay script không quan trọng.

Minification giảm byte bằng cách loại dữ liệu không cần thiết, nhưng không thay thế việc xóa code không sử dụng. MDN khuyến nghị minification như bước tự động trong quy trình build.

Trường hợp 5: Nội dung phụ thuộc JavaScript

Nếu nội dung chính chỉ xuất hiện sau client-side rendering:

• Kiểm tra Googlebot render được nội dung.
• Dùng server-side rendering hoặc static generation khi phù hợp.
• Đảm bảo title, canonical và metadata có trong HTML hợp lệ.
• Không chặn JavaScript cần thiết bằng robots.txt.
• Kiểm tra lỗi API và hydration.
• Cung cấp link crawlable bằng <a href>.

Trường hợp 6: Chỉ số thấp nhưng trang hoạt động tốt

Không cần sửa nếu:

• Trang đáp ứng đúng nhu cầu.
• HTML response có kích thước hợp lý.
• DOM không gây vấn đề.
• Core Web Vitals tốt.
• Google crawl và index bình thường.
• Conversion và trải nghiệm không có lỗi.

Có thể ghi chú cảnh báo trong báo cáo audit là “không cần hành động” để tránh đội kỹ thuật lặp lại việc kiểm tra.

Có nên xóa comment và khoảng trắng trong HTML?

Có thể minify HTML ở môi trường production, nhưng không nên yêu cầu nhân viên mở từng trang rồi xóa comment thủ công.

Minification hợp lý khi:

• Được plugin cache, CDN hoặc build pipeline xử lý tự động.
• Không phá preformatted text, template hoặc script.
• Source production được test sau khi tối ưu.
• Code phát triển vẫn giữ định dạng để dễ bảo trì.

Khoảng trắng và comment thường được Gzip/Brotli nén hiệu quả. Vì vậy, mức tiết kiệm có thể nhỏ hơn đáng kể so với resource size nhìn thấy trong source.

Có nên chuyển toàn bộ CSS và JavaScript ra file ngoài?

Không. External file có lợi vì được cache lại giữa các trang, nhưng inline code nhỏ có thể giảm request và hỗ trợ critical rendering path.

Mục tiêu là giảm byte và công việc không cần thiết trong hành trình tải trang, không phải làm tỷ lệ Text/HTML cao nhất.

Tối ưu hình ảnh có làm Text/HTML Ratio tăng không?

Thông thường là không. Nếu ảnh được tải bằng URL trong thuộc tính src, dung lượng file JPG, PNG, WebP hoặc AVIF không nằm trong tài liệu HTML. Nén ảnh làm tổng page weight và tốc độ tốt hơn nhưng không thay đổi đáng kể dung lượng HTML dùng để tính ratio.

Ảnh có thể ảnh hưởng HTML khi:

• Được nhúng bằng data URI hoặc Base64.
• SVG dài được inline.
• srcset, metadata hoặc placeholder quá lớn.
• Builder tạo nhiều wrapper và thuộc tính cho mỗi ảnh.

Do đó, tối ưu hình ảnh vẫn quan trọng cho LCP và bandwidth, nhưng không nên mô tả là cách trực tiếp nâng Text/HTML Ratio.

Có cần giữ HTML dưới 300 KB không?

Không có chuẩn SEO bắt buộc HTML phải dưới 300 KB. Đây có thể là ngưỡng nội bộ để cảnh báo, nhưng không áp dụng cho mọi website.

Thay vì dùng một con số cứng, hãy:

• So sánh HTML giữa các template tương tự.
• Phát hiện URL có kích thước cao bất thường.
• Kiểm tra xu hướng sau deploy.
• Đặt performance budget theo thiết bị và thị trường.
• Điều tra nếu HTML tăng mạnh mà nội dung không thay đổi.
• Đảm bảo không tiến gần giới hạn Googlebot chỉ đọc phần đầu tệp.

HTML hàng trăm kilobyte không tự động là lỗi, nhưng cần giải thích được byte đó phục vụ mục đích gì.

Text/HTML Ratio trong WordPress và page builder

Kiểm tra theme và builder

WordPress thường tạo markup từ theme, plugin và block. Với Flatsome, Elementor, Divi hoặc WPBakery, cần kiểm tra theo template:

• Trang chủ.
• Bài viết.
• Trang dịch vụ.
• Danh mục.
• Sản phẩm.
• Cart và Checkout.

Không nên thay page builder chỉ vì một công cụ báo ratio thấp. Hãy đo DOM, Core Web Vitals, khả năng bảo trì và conversion trước khi quyết định.

Kiểm tra plugin chèn markup toàn site

Popup, form, chat, review, table of contents, cookie consent và tracking có thể chèn HTML hoặc script vào mọi trang. Tắt plugin không sử dụng và chỉ tải asset ở nơi cần thiết.

Giữ nội dung sạch

Loại bỏ inline style, span và thuộc tính rác do copy từ Google Docs hoặc trình soạn thảo. Dùng semantic HTML và CSS trung tâm giúp source dễ quản lý, nhưng lợi ích chính là chất lượng code và khả năng bảo trì, không phải đạt một tỷ lệ cụ thể.

Cache và minify

LiteSpeed Cache, WP Rocket hoặc hệ thống build có thể minify HTML, CSS và JavaScript. Chỉ dùng một hệ thống chính cho mỗi chức năng và kiểm tra form, menu, tracking, WooCommerce sau khi bật.

Với website có nhiều template và plugin, Audit Website cần phân biệt vấn đề content, HTML response, DOM, JavaScript, asset và server trước khi đề xuất sửa.

Nên theo dõi chỉ số nào thay cho Text/HTML Ratio?

Google khuyến nghị Core Web Vitals tốt ở phân vị thứ 75 với LCP không quá 2,5 giây, INP dưới 200 mili giây và CLS dưới 0,1. Các chỉ số này đo trải nghiệm thực tế và hữu ích hơn một tỷ lệ code/text.

Quy trình audit theo mức độ ưu tiên

“Text/HTML Ratio chỉ hữu ích khi nó dẫn đội ngũ đến đúng câu hỏi. Mục tiêu không phải làm tỷ lệ cao hơn, mà là giữ nội dung đủ giá trị, HTML có lý do tồn tại và trải nghiệm thực tế nhanh, rõ, ổn định.”

Anh Thắng Giấu Tên – CEO Xuyên Việt Media

Những sai lầm thường gặp khi tối ưu Text/HTML Ratio

Checklist xử lý Low Text/HTML Ratio

Câu hỏi thường gặp về Text/HTML Ratio

Kết luận

Text/HTML Ratio là một chỉ số chẩn đoán do công cụ SEO tính, không phải tiêu chuẩn xếp hạng của Google. Không có tỷ lệ vàng áp dụng cho blog, trang bán hàng, landing page, sản phẩm và ứng dụng web.

Cảnh báo Low Text/HTML Ratio chỉ hữu ích khi được dùng để đặt câu hỏi sâu hơn: nội dung có đủ giá trị không, HTML có lớn bất thường không, DOM có phức tạp không, JavaScript có render đúng không và người dùng có nhận được trải nghiệm tốt không.

Không nên thêm chữ, xóa tính năng, externalize toàn bộ CSS/JS hoặc đập lại website chỉ để tăng phần trăm. Hãy ưu tiên các số đo trực tiếp như HTML transfer size, DOM node, unused code, LCP, INP, CLS, khả năng index và conversion.

Với website đang có nhiều cảnh báo kỹ thuật, một chiến lược SEO tổng thể cần ưu tiên lỗi theo tác động đến người dùng và kinh doanh, thay vì cố làm xanh mọi mục trong công cụ audit.