結論:Partytownは「重いサードパーティスクリプト」をメインスレッドから逃がす仕組みです

はじめに結論からお伝えします。Partytown(パーティータウン)とは、GA4やGoogleタグマネージャー(GTM)のような「自社サイトに埋め込むけれど自分では中身を制御できない外部スクリプト」を、ブラウザの裏側にあるWeb Worker(ウェブワーカー)へ退避させ、表示や操作を担うメインスレッドの負荷を減らすためのライブラリです。サードパーティスクリプトとは、計測タグ・広告・チャット・A/Bテストなど、外部サービスから読み込むコードの総称を指します。これらはビジネス上は欠かせない一方で、増えるほどページの動作が重くなりがちです。Partytownは、その重さの原因をメインスレッドから切り離すことで、PageSpeed Insightsで指摘されやすい「メインスレッドの処理時間が長い」「サードパーティコードの影響が大きい」といった課題に対処します。

ただし、Partytownは万能の高速化ボタンではありません。向いているスクリプトと向いていないスクリプトがはっきり分かれ、導入後は計測数値のズレが起きることもあります。この記事では、京都でWeb制作を手がける株式会社ドラマが実際に小規模で実装・検証してきた視点を交えながら、仕組み・メリット・デメリット・実装手順・PageSpeed改善の勘所・よくある誤解までを、後から読み返せる「まとめ」として網羅的に整理します。読み終えたとき、あなたは「自社サイトのどのスクリプトをPartytownに任せ、どれは任せないか」を自分で判断できる状態になっているはずです。

前提知識:Web Workerとメインスレッドの関係を先に押さえる

Partytownの価値を理解するには、まずブラウザの処理の仕組みを知っておくと近道です。ここは難しく感じる方もいるため、前提から丁寧に説明します。

メインスレッドとは「1人で全部こなす窓口」

JavaScriptは基本的にシングルスレッド、つまり一度に1つの処理しか進められません。ページの描画、クリックやスクロールへの反応、計測タグの実行まで、すべてを「メインスレッド」という1本の処理ラインがさばいています。窓口がひとつしかない受付に、来客対応も電話も書類仕事も集中している状態を思い浮かべると分かりやすいでしょう。来客(ユーザーの操作)に素早く応じたいのに、裏方の書類仕事(計測タグの処理)が詰まっていると、応対が遅れます。これが「操作してもすぐ反応しない」「スクロールがカクつく」といった体感の悪化につながります。

Web Workerとは「別室で動く2人目のスタッフ」

この詰まりを解消するために用意されたのがWeb Workerです。Web Workerは、メインスレッドとは別の裏方スレッドでJavaScriptを実行できる仕組みで、主要ブラウザでは長く前から使えます。重い計算などを別室のスタッフに任せれば、窓口は来客対応に専念できる、というイメージです。

ところが、Web Workerには大きな制約があります。Web Workerからは、ページの中身(DOM)やwindow・documentといったブラウザの機能へ直接アクセスできません。GA4やGTMのような外部スクリプトは、まさにこのDOMやwindowを前提に書かれているため、そのままWeb Workerに移すと動かなくなってしまいます。だからこそ、これまでWeb Workerは便利でも使いどころが限られていました。

Partytownの仕組み:なぜスクリプトを「そのまま」動かせるのか

Partytownの巧みなところは、外部スクリプトを書き換えずに、そのままWeb Worker内で動かせる点にあります。仕組みを噛み砕くと、次のような流れです。

1. type=’text/partytown’ でメインスレッドの実行を止める

通常のscriptタグは読み込まれた瞬間にメインスレッドで実行されます。Partytownでは、退避させたいスクリプトのtype属性をtype=’text/partytown’に変えます。ブラウザは未知のtypeを「実行対象のスクリプトではない」とみなすため、メインスレッドでは動かなくなります。Partytownはこのタグを見つけて中身を取得し、Web Worker内で実行します。タグの書き方そのものは、従来のサードパーティスクリプトと同じ感覚で扱えるのが利点です。

2. Proxyで「DOMにアクセスしているフリ」を実現する

Web WorkerはDOMに触れないため、Partytownはワーカー内にProxy(代理オブジェクト)を用意します。スクリプトがdocumentやwindowを操作しようとすると、その操作はProxyが受け取り、メインスレッド側へ転送して実際の処理を代行させます。スクリプトから見れば、いつも通りDOMを触っているように見えるため、コードを書き換える必要がありません。

3. 同期通信で「待たせずに結果を返す」

外部スクリプトの多くは、結果がすぐ返ってくる前提(同期処理)で書かれています。一方、スレッド間のやり取りは本来は非同期です。Partytownはこのギャップを埋めるために、Service Worker(サービスワーカー)経由の同期XHR、またはAtomics(アトミクス)という2つの通信方式を使い、ワーカーからメインスレッドへの問い合わせを「同期しているように」見せかけます。新しい環境ではより効率的なAtomicsを使い、対応していない場合はService Workerにフォールバックする、という二段構えです。なお、いずれの通信方式も使えない古い環境では、Partytownは無理に動かさず、従来どおりメインスレッドで実行する安全側の挙動になります。

結果として、サイト訪問者がページを開くと、開発者ツールのスレッド一覧に「Partytown」という名前のWeb Workerが現れ、計測タグなどの裏方仕事はそちらが引き受けます。メインスレッドは描画と操作対応に集中でき、体感速度が上がるという流れです。

Partytownが効くケース・効きにくいケースを見極める

導入判断でいちばん大切なのが、この「向き・不向き」です。ここを誤ると効果が出ないどころか、計測が壊れることもあります。

向いているスクリプト

• GA4(Googleアナリティクス4)やGTM(Googleタグマネージャー)などの計測・タグ管理系。ページの描画には直接関与せず、後追いで動けば十分なため、退避に向いています。
• 広告・リターゲティング・各種ピクセル系のタグ。重くなりがちで、かつ即時の描画には不要なものが多い領域です。
• ヒートマップ・アクセス解析・A/Bテストなどの計測補助ツール。ユーザー操作の邪魔をせず裏で動けばよい性質のものが多くあります。

向いていないスクリプト

• ページの初期描画に必要なもの。最初の表示に関わるコードを裏に回すと、かえって表示が崩れたり遅れたりします。
• クリック直後に即座にDOMを操作したい処理。Web Worker内のDOM操作は意図的に少し遅く調整されているため、即応性が命の機能には不利です。
• event.preventDefault() で標準動作を止めたい処理。Partytown経由ではpreventDefault()が効かないため、フォーム送信の抑止などには使えません。
• 同一オリジンから配信できない自作ライブラリ。後述のとおり、Partytown本体は自サイトと同じドメインから配信する必要があります。

ウェブフォントやGSCはどうなる?(誤解の整理)

ここはご相談でも特に誤解が多い部分なので、はっきりさせておきます。Partytownが扱うのは「JavaScript」であって、ウェブフォントのフォントファイルそのものではありません。フォントが重い問題は、原則としてfont-displayの指定、サブセット化(必要な文字だけに絞る)、preloadや自己ホスティングといったフォント側の最適化で対処します。スクリプトでフォントを差し込むタイプのサービスなら間接的に関係する場合もありますが、「Partytownを入れればフォントが軽くなる」という理解は正確ではありません。

同じくGSC(Googleサーチコンソール)の所有権確認は、多くの場合メタタグやDNS設定であってスクリプトではないため、Partytownの退避対象にはなりません。GA4・GTM・GSCをひとくくりに「重い外部要素」と捉えがちですが、Partytownで軽くできるのは主にGA4とGTM(が読み込む各種スクリプト)であると整理しておくと、判断を誤りません。

メリットを読者目線で整理する

あなたのサイト運営にとっての具体的な利点を挙げます。

• メインスレッドの作業時間が減る:計測タグの実行を裏に回すことで、PageSpeed Insightsで指摘されやすい「メインスレッドの処理が長い」状態の改善が見込めます。
• Core Web Vitalsの改善が期待できる:特にTBT(Total Blocking Time:操作をブロックする時間)が下がりやすく、結果としてINP(操作への反応性)やユーザー体験の向上につながります。
• 操作・スクロールがなめらかになる:窓口が空くため、クリックやスクロールへの反応が軽くなります。
• スクリプトをサンドボックス化できる:外部スクリプトがアクセスできるブラウザ機能を制御でき、Cookieやストレージへの権限を管理しやすくなります。セキュリティ・プライバシー観点でも利点があります。
• コードの書き換えが基本不要:type属性の変更と簡単な設定が中心で、既存のタグ運用を大きく崩さずに試せます。

公開されている検証事例では、GTMをPartytownで退避させた結果、Lighthouseのスコアが70点台から90点台後半まで改善したという報告もあります。これはあくまで条件の整った一例であり、すべてのサイトで同じ結果になるとは限りませんが、「サードパーティスクリプトが主なボトルネックだったサイト」では効果が出やすい傾向があります。

デメリット・トレードオフを正直に押さえる

メリットだけを並べるのはフェアではありません。導入前に知っておくべき注意点をまとめます。

• 現時点でベータ段階のプロジェクト:Partytownは便利ですが、すべての環境・すべてのスクリプトで動く保証はありません。本番投入の前に、自社環境での検証が前提になります。
• 本体は同一オリジンから配信する必要がある:Partytownのライブラリ群はCDNではなく、HTMLと同じドメインから配信しなければ正しく動きません。配信先の設計を最初に決めておきましょう。
• スレッドが3本になる:メインスレッド・Web Worker・Service Workerの3つを使う構成です(Atomics利用時は実質2本に近づきます)。仕組みが増える分、トラブル時の切り分けはやや複雑になります。
• ワーカー内のDOM操作は意図的に遅い:安定動作のために調整されており、メインスレッドで動かす場合より処理は遅くなります。これは「速くするため」のトレードオフです。
• ネットワークタブにproxytown宛の大量リクエストが見える:これらはService Workerがローカルで処理する内部通信で、外部への実際の通信ではありません。スコアや実速度には影響しませんが、見た目に驚かないようにしておきましょう。
• 計測数値がズレる・減ることがある:設定が不十分だと、セッション時間や直帰率などのGA4の数値が実態とずれてしまうケースが報告されています。導入後は必ず数値を見比べる工程が必要です。

GA4・GTMをPartytownで動かす実装の流れ

ここからは実装の勘所です。フレームワークごとに細部は異なりますが、考え方は共通しています。

基本のスニペットとtype属性

退避させたいGTM/GA4のscriptタグにtype=’text/partytown’を付けます。あわせて、ページ側にPartytown本体を読み込み、設定オブジェクト(window.partytown)を用意するのが基本構成です。タグの記述自体は、従来のGA4/GTM設置と大きく変わりません。

forward設定でdataLayer.push と gtag を転送する

ここがいちばんつまずきやすいポイントです。GTMやGA4はメインスレッド上のwindow.dataLayerやgtagを通じてイベントを送ります。ところがPartytownでは、これらの実体はWeb Worker内に存在します。そのため設定のforwardにdataLayer.pushやgtagを登録し、「メインスレッドで呼ばれた計測イベントを、ワーカー側へ転送する」よう指示する必要があります。たとえば forward: [‘dataLayer.push’] のように指定します。これを忘れると、ボタンクリックなどの独自イベントが送られず、計測データが静かに欠落します。

GA4はCORS対応済みでプロキシ不要

現行のGA4は、計測リクエストの応答が適切なCORSヘッダを返すため、www.google-analytics.com宛のリクエストをわざわざプロキシする必要はありません。プロキシ設定が要るのは旧来のサービスなどに限られ、GA4・GTM中心の構成ならこの点はシンプルです。

WordPressでの導入

WordPressサイトの場合、自前でスニペットを組み込む方法のほかに、スクリプトをWeb Workerへ退避させるための公式系プラグイン(Web Worker Offloadingなど)を使う方法もあります。これらは内部的にPartytownの仕組みを利用し、管理画面側からの設定や、wp_enqueue_scriptの依存関係としてpartytownを指定する形で対象スクリプトを退避できる作りになっています。Googleの「サードパーティスクリプト最適化ガイド」でもこの手法は紹介されており、考え方としては一定の市民権を得つつあります。ただしプラグインを入れれば全自動で安全、というわけではなく、対象スクリプトの取捨選択と計測確認は人の判断が必要です。

PageSpeed Insightsのスコアはどう変わるのか

「スコアを上げたい」という動機でPartytownにたどり着く方は多いはずです。ここは期待値を正しく持つことが大切です。

改善が見込める指標

Partytownが直接効きやすいのは、TBT(操作をブロックする時間)とメインスレッドの作業時間です。サードパーティスクリプトの実行をメインスレッドから外すことで、これらの数値が下がり、総合スコアの押し上げにつながります。Lighthouseの「メインスレッドの作業を最小限に抑える」「第三者コードの影響を抑える」といった指摘の解消も期待できます。

「レンダリングを妨げるリソース」とは別問題

ここは混同しやすいので強調します。PageSpeed Insightsの「レンダリングを妨げるリソースの除外」(render-blocking)は、主にCSSや同期読み込みのJavaScriptが初期表示をせき止めている問題で、async/deferの付与やCSSの最適化で対処する領域です。一方、Partytownが解くのは「実行が重くてメインスレッドを占有する」問題です。両者は近いようで別物であり、Partytownを入れても「レンダリングを妨げるリソース」の指摘がそのまま消えるとは限りません。表示速度改善は、async/defer・遅延読み込み・自己ホスティング・そして最後の手段としてのWeb Worker退避、という段階的な積み重ねで考えるのが正攻法です。

ラボデータとフィールドデータの両方を見る

スコアはあくまで計測条件に左右される「ラボデータ」です。導入の判断は、実ユーザーの体感を反映する「フィールドデータ」もあわせて確認しましょう。スコアが上がっても計測が壊れていては本末転倒なので、速度とデータ精度の両面で評価することをおすすめします。

株式会社ドラマでの検証から見えた、実装の現実的なコツ

当社ドラマでは、自社や検証用の環境でPartytownをこまめに実装し、挙動を確かめてきました。その経験から、机上の手順だけでは見えにくい「現場の勘所」を共有します。

まずは計測タグから小さく始める

いきなり多くのスクリプトを退避させると、どれが原因で不具合が出たのか切り分けられなくなります。GA4やGTMといった「描画に関わらず、後追いで動けば十分なタグ」から1つずつ試すのが安全です。1つ入れては数値と表示を確認し、問題なければ次へ進む。この地道さが、結局いちばんの近道になります。

導入後は必ず数値のズレを確認する

Partytown導入で最も怖いのは、「速くなったのに、計測データが静かに減っていた」という事態です。forward設定の漏れや、イベントの転送不足で起こります。導入前後でセッション数・直帰率・コンバージョン計測・主要イベントの発火を必ず見比べ、リアルタイムレポートでイベントが届いているかを確認しましょう。速度は数字で見えても、計測の欠落は見えにくいからこそ、意識的なチェックが要ります。

フォールバックと撤退ラインを決めておく

ベータ段階のライブラリである以上、「うまくいかなければ元に戻す」判断もセットで持っておくべきです。対象スクリプトのtype属性を戻すだけで従来挙動に戻せるよう、変更箇所を最小限・可逆的にしておくと安心できます。検証→本番反映の前に、撤退条件(例:計測の欠落が一定以上なら戻す)を決めておくと、迷いがなくなります。

導入前のチェックリスト

判断に迷ったら、次の項目を上から確認してみてください。

• 重さの主因は本当に「サードパーティスクリプトの実行」か(まず計測で特定する)
• async/defer・遅延読み込み・自己ホスティングなど、より手軽な施策を先に試したか
• 退避対象は描画に関与しないタグ(GA4・GTM・計測系)に限定できているか
• Partytown本体を同一オリジンから配信できる構成か
• GTM/GA4のイベント転送(forward設定)を用意したか
• 導入前後で計測数値を比較する手順を決めてあるか
• うまくいかない場合に元へ戻す手順(撤退ライン)を用意したか

よくある誤解とご質問

Partytownを入れればサイトは必ず速くなる?

いいえ、必ずではありません。効果が大きいのは「サードパーティスクリプトが主なボトルネックのサイト」です。スクリプトが軽い、あるいは別の要因(画像・CSS・サーバー応答)が重いサイトでは、体感が変わらないこともあります。まずは原因の特定が先です。

ウェブフォントの読み込みも速くなる?

基本的にはなりません。Partytownの対象はJavaScriptであり、フォントファイルの最適化はfont-displayやサブセット化など別の手段で行います。両者は守備範囲が違うと理解しておきましょう。

計測が止まる・数値が減るのはなぜ?

多くはイベント転送の設定不足が原因です。dataLayer.pushやgtagをforwardに登録し、独自イベントが正しくワーカーへ届いているかを確認してください。設定を整えれば、計測を維持したまま高速化を狙えます。

まとめ:速度とデータ精度を両立させたいときはご相談ください

Partytownは、GA4やGTMといった重いサードパーティスクリプトをWeb Workerへ退避させ、メインスレッドの負荷を下げてPageSpeed Insightsの改善を狙える、有力な選択肢です。一方で、向き・不向きの見極め、同一オリジン配信などの前提条件、そして計測数値のズレ対策まで含めて、丁寧に検証してこそ効果が活きます。「入れて終わり」ではなく「測って整える」運用が成否を分けます。

株式会社ドラマは京都を拠点に、ホームページ制作・ECサイト構築・WordPress開発・LP制作・SEO/MEO/AIO対策まで一貫して手がけるWeb制作会社です。今回ご紹介したPartytownのように、表示速度とアクセス計測の両面を踏まえた改善提案を、実際の検証にもとづいてご支援しています。「PageSpeed Insightsのスコアが上がらない」「計測を壊さずに高速化したい」といったお悩みがあれば、現状のサイトを拝見したうえで、現実的な改善ステップをご提案します。

ご相談は、お問い合わせフォーム・LINE・お電話(075-585-5352)・お見積もり依頼のいずれからでも承っています。京都・大阪はもちろん全国対応が可能です。サイトの「重さ」が気になり始めた今が、見直しの好機です。どうぞお気軽にお声がけください。