SSR: non-ASCII characters in static template text make the whole rendered page a two-byte string

クローズ
  • 何か問題がありますか？
#4,328 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
42/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
babel, javascript, rust, typescript
領域
backend, performance

調査の方向性

Start by reading the Rust SSR template compiler pass described in the spike, then trace the Babel plugin’s template handling and the ssrElement path for spread attributes. Update both compiler paths to emit character references only in static text and quoted attribute values, preserving tag internals, comments, and script/style bodies. Run the compiler fixture tests and check that rendered HTML decodes correctly; the issue reports 54 expected-output fixture failures and an uncovered spread-attribute path.

索引モデルが issue の本文から書いたものです。

説明

What happens

A single non-ASCII character in static JSX text, such as the → in <a>View →</a>, makes the whole server-rendered page a two-byte string in V8. V8 stores a string at one byte per character only while every character is Latin-1, so once the → is concatenated in, the flattened page becomes UTF-16. That roughly doubles the cost of flattening the rendered rope and makes the TextEncoder.encode call in the response stream several times slower.

I found this while comparing Solid 2.0 (rc.19, @solidjs/vite-plugin next.51, router next.42) with SolidStart on the e18e framework-tracker benchmark app. Its /server-side-rendered page is a 1000-row table where each row ends in <a href={...}>View →</a>. The rendered page is about 300 KB.

On that page, TextEncoder.encode on the response takes about 1.3 ms of the roughly 3.4 ms of CPU per request: about 0.5 ms for V8 to flatten the rope and about 0.7 ms for the UTF-16 to UTF-8 conversion. The same encode on an ASCII-only version of the page is much cheaper. On a flat 170 KB string, TextEncoder.encode takes 0.06 ms when it is all ASCII and 0.35 ms when it contains one →.

How to reproduce

The effect is visible without Solid:

const te = new TextEncoder()
const page = (arrow) =>
  Array.from({ length: 1000 }, () =>
    `<tr><td>${crypto.randomUUID()}</td><td><a href="/x/${crypto.randomUUID()}">View ${arrow ? '→' : '-&gt;'}</a></td></tr>`
  ).join('')

for (const arrow of [false, true]) {
  const strings = Array.from({ length: 200 }, () => page(arrow))
  const start = performance.now()
  for (const s of strings) te.encode(s)
  console.log({ arrow, msPerEncode: (performance.now() - start) / 200 })
}

In a Solid app, render any component whose static template text contains a non-ASCII character next to a large amount of other markup, then profile renderToStream. Most of the encode time lands in encodeUtf8String.

Proposal

When the compiler builds SSR template strings, it can emit non-ASCII characters in static text and quoted attribute values as numeric character references (→ becomes &#8594;). Browsers decode these to the same characters, so the DOM, hydration and the client templates are unchanged. The work happens once, at build time. Tag internals, comments and <script>/<style> bodies have to keep their characters, because browsers do not decode references there.

This only helps when the non-ASCII characters come from templates. Non-ASCII in rendered data, such as a user's name, still makes the page two-byte.

Spike results

I tried this in the Rust compiler as a pass applied to each registered SSR template, with a small state machine for text, tags, quoted attributes, comments and raw-text elements. I then rebuilt the framework-tracker app with it:

/server-side-rendered, 1000 rows Current compiler With character references
CPU per request, median of 6 runs 3.40 ms 3.00 ms
HTTP req/s, autocannon, 10 connections 393 512
p99 latency 33 ms 27 ms

The page without the arrow (/ssr-throughput) was unchanged at 2.13 ms. The rendered HTML was identical apart from the character references, the client bundle was byte-identical, and the page hydrated and navigated client-side in Chrome with no console output.

Two things are still open in the spike. The Babel plugin needs the same change: 54 compiler fixture tests currently fail, every diff being only a character reference, because their expected output comes from Babel. Attribute strings built for spread elements (ssrElement) take a different path and are not covered yet.

I can open a PR with the compiler change if this direction is wanted.

主要言語
TypeScript
スター
36.2k
フォーク
1.1k
平均マージ
11時間 48分
マージ済み PR（30日）
441

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

solidjs/solid のほかの issue

solidjs/solid の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。