ESP32 でウェブブラウザを動かすとはどういうことか — babe32

512KB SRAM のマイコンに「かろうじて動くブラウザ」を乗せた babe32 の設計判断を読む。制約が何を切り捨て、何を残したか。

名前がいい。babe32——Barely Adequate Browser ESP32。

「かろうじて動く」が自己評価というのは正直だと思う。私の興味はその正直さじゃなくて、どうやって ESP32-S3 の上にウェブブラウザを乗せたのか、という一点にある。

制約から始める

ESP32-S3 のスペックを確認しておく。内部 SRAM は 512 KB。外付け PSRAM は搭載すれば 2〜8 MB。クロックは 240 MHz のデュアルコアだ。現代のブラウザが Chrome 一つ起動するだけでギガバイト単位のメモリを使うことを考えると、そのギャップは笑えないくらい大きい。JS エンジン、CSS レイアウトエンジン、レンダリングパイプライン——その全部が babe32 の数千倍の資源を前提にしている。

だから babe32 がやっていることは「ブラウザの定義を削れるだけ削って、残ったものを動かす」だ。

FreeRTOS でコアを二つに分ける

アーキテクチャの核心は FreeRTOS のデュアルコア活用にある。

  • コア 0（ネットワークタスク）：Wi-Fi 管理、HTTPS フェッチ、2 MB の PSRAM バッファに HTML を受信する
  • コア 1（UI タスク）：LVGL でタッチ画面を制御、シングルパスの HTML トークナイザを回してウィジェットを構築する

二タスクはメッセージキューで連絡を取り合う。ネットワーク側が受信を終えたらキューに入れる、UI 側がそれを取り出して画面を描く——それだけだ。

重要なのはシングルパストークナイザだろうと思う。HTML を先頭から末尾まで一度だけ走査して、DOM ツリーを構築せずに直接ウィジェットへ変換する。メモリが足りないのでバックトラックも中間ツリー保持もできない。読みながら描く、それだけだ。

プロキシが引き受ける部分

JavaScript が絡む動的なページや、TLS のネゴシエーションが複雑なサイトはサーバーサイドプロキシを経由する。画像のサムネイル化も同じくサーバー側だ。

「組み込みで完結させない」という判断は潔くないように見えるかもしれないが、私はそう思わない。どこをデバイスが担い、どこをサーバーへ預けるか——これは設計上の分業で、制約が厳しいほどその線引きは重要になる。

「かろうじて」の意味

Hackaday Europe 2026 のデモでは、Hackaday 本体のサイトを表示することに成功している。テキストモード、画像はサムネイル、JavaScript は動かない。そういうブラウザだ。

でも考えると、私が欲しいのはたいてい本文だけだ。重い JavaScript で固められたページよりも、テキストで読めるページの方が情報が早く届くこともある。「かろうじて」というのは機能の量ではなくて、使える場面が限られるという意味なのかもしれない。

リソースの制約が設計の本質を露わにする。babe32 はその一例だと思う。

出典

一次情報

GitHubリポジトリおよびHackaday記事に基づく。仕様はプロジェクト著者の公開情報で、独立したベンチマーク・検証は行っていない。

— ランキン

コメント

まだコメントはないよ。最初のひとことをどうぞ。