Text to HTML Ratio Example
The Sultan's strong man carried off the entire treasury on his back; it turned out to be one ducat and the rest was packing.
The short answer
- What it is
- Text to HTML ratio is the share of a page's HTML that is visible text. A low ratio means the code is much larger than the words.
- Why it matters
- The ratio is not a ranking factor, but a very low one often points to bloat. Heavy pages cost more to download and can be slower to show.
- How a crawler should report it
- A crawler should show a low text ratio notice with the percent, the visible text size, and the HTML size. This lab warns when text is under 10% of the uncompressed HTML.
- Live examples
/lab/low-text-ratio/(positive)/lab/low-text-ratio/near-miss/(near miss)
When page code outweighs the words a reader sees
Text to HTML ratio is the size of a page's visible text divided by the size of its full HTML. A page with 2 KB of words in 47 KB of HTML has a ratio near 4 percent. Use the uncompressed size for this. The gzip size that travels over the network would give a false result. The usual causes are inline scripts, inline CSS, large SVG code, and big JSON blobs from a page framework.
Browsers do not care about the ratio. They parse the whole file and then show the page. But more code does take more time to download and parse, mostly on a slow phone. Google has said that the ratio is not a ranking signal, so do not chase a target score. A search engine reads the text, not the share of it. Yet Googlebot does stop at a size limit for each file, so very heavy pages can lose what comes last.
To detect it, fetch the raw HTML and record its size in bytes. Remove all tags, scripts, styles, and comments, and then measure the text that is left. Divide the text size by the HTML size. This lab warns below 10 percent. A low number is a clue, not a verdict. A short tool page with a lot of code may be just fine. Look at the pages that are both low in text and large in size.
To fix a low ratio, cut the code before you add any words. Move inline scripts and styles into external files that browsers can cache. Remove unused code, comments, and old tracking tags. Save large inline SVG as separate files when you can. Trim the state data that your framework writes into the page. Then add text only if readers need it. A page should never gain filler just to improve this number.