Inline JavaScript Kilobytes

Inline JavaScript Kilobytes (RG-SIZ-012) reports the combined size, in kilobytes, of the code held inside a page’s inline <script> elements. It counts inline script contents only — not external .js files, not compressed transfer size, and not execution cost — so read it as an observation to weigh against evidence, never a number to minimize blindly.

What it measures

This factor reports the measured size of the contents of a page’s inline <script> elements, expressed in kilobytes. Inline scripts are the JavaScript written directly between the opening and closing <script> tags in the HTML, as distinct from code loaded from a separate file through a src attribute. The value reflects how much script the page carries inside its own markup.

How RankGear measures it

RankGear extracts the content capture from every parsed <script> element in the rendered HTML, sums their UTF-16 string lengths, and divides by 1,024 to produce a kilobyte figure. This measures inline script contents only — it does not count external JavaScript files, compressed (gzip or brotli) transfer size, execution cost, or scripts injected after the capture.

What RankGear looks for

<!-- counted: inline content is summed -->
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){ dataLayer.push(arguments); }
</script>

<!-- not counted: external file, no inline content -->
<script src="/assets/app.bundle.js"></script>

kilobytes = Σ( UTF-16 length of each inline <script> content ) ÷ 1024

How to optimize it

Keep inline JavaScript minimal and purposeful: remove unused code, defer noncritical behavior, and move reusable logic into cacheable external bundles where appropriate. Treat the number as an observation rather than a hard target — the aim is efficient, purposeful script, not the smallest possible figure. Preserve useful content and functionality while improving efficiency.

Important considerations

• RankGear divides UTF-16 length by 1,024, so this is a character-based size, not a network-transfer byte measurement.
• Minification, compression, external resources, and runtime behavior may not be reflected in this figure.
• Preserve useful content and functionality while improving efficiency — do not strip scripts the page genuinely needs.
• Compare this factor with ranking and user-performance evidence rather than assuming larger or smaller is always better. It relates to position within a measured result set and acts as a prioritization signal — not a guarantee that any page will rank.

Related factors

• Inline CSS Kilobytes
• Number of Bytes to First Match

Part of the Factors reference · how RankGear measures · glossary.