Low Text-to-HTML Ratio Due to Self-Push Tags in Next.js 14 (app router)

[Developer-6698]

Summary

I'm currently working on a blog website that fetches large content on the server side (e.g., blog articles, schema data, etc.). I’ve been running into an SEO issue flagged by tools like Lighthouse and other analyzers — low text-to-HTML ratio.

After some inspection, the main contributors seem to be:

• LD+JSON structured data being injected as inline script tags in .
• Font imports and other critical scripts (e.g., Google Fonts, analytics) being loaded via , <script>, and NEXT_DATA.
• Large data chunks, even if meant only for client hydration, are being included as inline chunks in <script>self.__next_f.push or pushed via Next.js’s self-push headers.

As a result, while my actual visible content is meaningful and text-rich, the overall HTML payload includes a lot of head content and serialized data, throwing off text-to-HTML ratio evaluations.

My questions:

• Is there a recommended way to optimize or defer NEXT_DATA or JSON-LD script contents so that they don’t impact text-to-HTML ratio metrics?
• Can Next.js expose better control for where or how LD+JSON and initial data are injected, especially for content-heavy SSR pages?
• Is there a way to exclude certain data from hydration, or break it into lazy-loaded chunks post-page load?

I'd love suggestions, workarounds, or future roadmap insights for this. Since text-to-HTML ratio is used by some SEO validators (even if not a core Google metric), it would be great to align Next.js output with best practices for content-heavy sites.

Thanks in advance!

Additional information

</script><script>self.__next_f.push([1,"e eligible to join the hernia mesh lawsuit if you meet the following criteria:\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eYou had a hernia repaired with mesh.\u003c/li\u003e\u003cli\u003eYou experienced complications such as ongoing pain, infection, or the need for additional surgery.\u003c/li\u003e\u003cli\u003eYou can provide medical records documenting your complications and the type of mesh used to repair your hernia.\u0026nbsp;\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eYou may also qualify if you have suffered from the following injury(ies):\u0026nbsp;\u003c/p\u003e\u003cul\u003e\u003cli\u003eAbdominal Pain\u003c/li\u003e\u003cli\u003eAdhesions\u003c/li\u003e\u003cli\u003eBowel Perforation\u003c/li\u003e\u003cli\u003eEdge of Mesh Curled Towards Bowel\u003c/li\u003e\u003cli\u003eInfection\u003c/li\u003e\u003cli\u003eHernia Recurrence\u003c/li\u003e\u003cli\u003eIntestinal Blockage\u003c/li\u003e\u003cli\u003eMesh Migration\u003c/li\u003e\u003cli\u003eIntestinal Fistula\u003c/li\u003e\u003cli\u003eSurgery to Remove The Mesh\u003c/li\u003e\u003cli\u003eDeath Due to The Mesh\u003c/li\u003e\u003cli\u003eOpen Draining Would\u003c/li\u003e\u003cli\u003eThe Mesh Plastic Ring is Broken\u003c/li\u003e\u003cli\u003eThe Mesh Balled Up/Wadded Up\u003c/li\u003e\u003c/ul\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eNote\u003c/strong\u003e: The claimant must have had hernia implant surgery between January 2010 and to current date to be eligible.\u0026nbsp;\u003c/p\u003e\u003cp\u003e\u0026nbsp;\u003c/p\u003e\u003cp\u003eIf you meet the above requirements, you may be\",\"headline\":\"hernia mesh lawsuit\",\"image\":[\"https://oca-app-storage.s3.us-west-2.amazonaws.com/Hernia+Mesh.jpg\"],\"datePublished\":\"2024-09-04T00:54:16.647Z\",\"dateModified\":\"2025-06-08T19:24:01.639Z\",\"author\":{\"@type\":\"Person\",\"name\":\"OnlyClassActions\",\"url\":\"https://onlyclassactions.com/\"},\"publisher\":{\"@type\":\"Organization\",\"name\":\"OnlyClassActions\",\"logo\":{\"@type\":\"ImageObject\",\"url\":\"https://onlyclassactions.com/_next/image?url=%2F_next%2Fstatic%2Fmedia%2FOnlyClassActions-Logo.680be48c.png\u0026w=256\u0026q=75\"}},\"mainEntityOfPage\":{\"@type\":\"BlogPosting\",\"@id\":\"https://onlyclassactions.com/lawsuits/hernia-mesh-lawsuit\",\"url\":\"https://onlyclassactions.com/lawsuits/hernia-mesh-lawsuit\"}}28:T498,{\"@context\":\"https://schema.org\",\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"How Do I Know If I’m Eligible To Join A Class Action Lawsuit?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"The specific requirements listed in the class defin"])</script><script>

Example

view-source:https://onlyclassactions.com/lawsuits/hernia-mesh-lawsuit

[SMatvii]

1. Can you optimize or defer NEXT_DATA or LD+JSON scripts to improve text-to-HTML ratio?

Short answer:
Not fully, but you can minimize their impact and structure your output for better results.

Details:

• NEXT_DATA:
  This inline <script id="__NEXT_DATA__" type="application/json"> contains the serialized page props, layout data, and other Next.js internals for hydration.

  • You cannot defer or move it out of the HTML (Next.js requires it before React hydration).
  • You can reduce its size by:
    • Avoiding large, unnecessary data in page props (e.g., don’t pass complete article lists if only a summary is needed for initial render).
    • Using API routes or client-side fetch for data only needed after hydration.

• LD+JSON (JSON-LD structured data):

  • You must have it in the HTML for SEO (Google expects it during crawling).
  • But: You can minimize or split it if you have a large FAQ or product schema, e.g.:
    • Only include essential fields for the initial render.
    • For very large FAQ schemas, consider splitting into multiple script tags for clarity, but don’t load with JS after hydration—search engines may not see it.

---

2. Can Next.js expose better control for where/how LD+JSON and initial data are injected?

Currently:

• NEXT_DATA: No, you cannot change where or how it’s injected.
• LD+JSON:
  • For the App Router, use the metadata API and generateMetadata to add structured data.
  • For more control, you can manually insert <script type="application/ld+json"> in your page or layout file’s <head>, but it will always be in the <head>.
• Feature request:
  There have been discussions about letting users defer or move NEXT_DATA, but for now, it’s fixed.
  If this is critical, consider opening a new feature request or upvoting existing ones on the Next.js repo.

---

3. Can you exclude certain data from hydration, or break it into lazy-loaded chunks?

Yes, to some extent:

• Don’t pass big data in getServerSideProps/getStaticProps or page-level props if it’s not needed for first paint.
  • Fetch additional data on the client after hydration (with SWR, React Query, fetch, etc.).
• Use Dynamic Imports and suspense for client-only heavy components.
• Lazy-load non-critical scripts:
  Use Next.js <Script> with strategy="lazyOnload" for analytics, etc.
• For App Router (App Directory):
  Use server components for heavy data, and only pass what’s needed to client components.

---

4. Other Tips & Workarounds

• Minimize inline critical scripts:

  • Combine font imports and critical CSS as much as possible.
  • Use the font-display: swap; and self-host fonts to reduce HEAD bloat.

• Review what’s going into NEXT_DATA:

  • Only pass minimal serializable data.
  • Avoid serializing large objects, especially if only needed for client API calls.

• Measure with Real-World SEO:

  • Lighthouse’s text-to-HTML ratio is not a Google ranking metric.
  • Focus on meaningful content, speed, and mobile friendliness.
  • Google’s John Mueller has said text-to-HTML ratio is not a ranking factor.

• If you must “cheat” the metric:

  • You could, technically, move some non-critical JSON-LD to load after hydration (client-side), but this risks SEO.
  • You could split FAQ schema into several smaller <script> tags if it helps Lighthouse parse it better, but test in Search Console to ensure Google still sees it.

---

5. Roadmap / Proposals

• Feature requests exist for more control over hydration and script placement in Next.js, but no timeline is public.
• For now, the best course is to optimize what you serialize and keep the critical SEO scripts inline.

---

Summary Table

Data Type	Can Move/Defer?	Notes
NEXT_DATA	No	Minimize data passed; can’t change placement or timing
JSON-LD (LD+JSON)	No (SEO)	Must be inline for SEO; can split, but not defer
Fonts/Analytics	Yes (partly)	Use <Script strategy="lazyOnload">, self-host fonts if possible
Hydration Data	Yes (partly)	Only hydrate what’s needed; lazy-load additional data

---

TL;DR:

• Minimize what you serialize and inline.
• Only hydrate essential data.
• Accept “low” text-to-HTML from Lighthouse if your visible content is strong and SEO scripts are necessary.
• Don’t break Google’s FAQ/schema parsing by moving LD+JSON out of the initial HTML.