Tecnoblog の Discourse コメントに関する体験

こんにちは!

この新機能には本当に興奮しています。このようなソリューションを待ち望んで久しいですが、Tecnoblog の読者からの初期フィードバックも素晴らしく、コミュニティ統合を大変気に入ってくれています。

しかし、実際の運用テストを経て、これを真にネイティブなコメントシステムとして感じさせるとともに、トラフィックの多いサイトでも持続可能にするためにクリアすべきいくつかの技術的課題が見えてきました。

現時点で見つかった点は以下の通りです:

1. パフォーマンスとサーバー負荷

フルアプリを埋め込んだ後、サーバー負荷が大幅に急増しました。Cloudflare のデータを見ると、リクエスト数が10 倍に増加していました。これを最適化するためのいくつかのアイデアがあります:

  • 遅延読み込み(Lazy Loading): JS の遅延読み込みを実装することで劇的に改善されます(私はすでにこのための回避策を適用しています)。
            <script type="text/javascript">
                DiscourseEmbed = {
                    discourseUrl: '<?php echo esc_url($discourse_url); ?>',
                    
                    <?php if ($use_topic_id): ?>
                        // ID モード:データベースに保存されたトピック、URL 変更の影響を受けない
                        topicId: <?php echo intval($topic_id); ?>,
                    <?php else: ?>
                        // URL モード:API 経由での作成失敗時のフォールバック
                        discourseEmbedUrl: '<?php echo esc_url($permalink); ?>',
                    <?php endif; ?>
                    fullApp: true,
                    embedHeight: '800px',
                };

                (function() {
                    var container = document.getElementById('discourse-comments');

                    // ブラウザが IntersectionObserver をサポートしているか確認
                    if ('IntersectionObserver' in window) {
                        var observer = new IntersectionObserver(function(entries, observer) {
                            entries.forEach(function(entry) {
                                if (entry.isIntersecting) {
                                    // div が画面内に入った時点でスクリプトをロード
                                    loadDiscourse();
                                    observer.unobserve(entry.target);
                                }
                            });
                        }, { rootMargin: "1500px" }); // div に到達する 1500px 手前でロード開始

                        observer.observe(container);
                    } else {
                        // 古いブラウザ向けのフォールバック
                        loadDiscourse();
                    }

                    function loadDiscourse() {
                        var d = document.createElement('script'); 
                        d.type = 'text/javascript'; 
                        d.async = true;
                        d.src = window.DiscourseEmbed.discourseUrl + 'javascripts/embed.js';
                        (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(d);
                    }
                })();
            </script>

以下は、遅延読み込みを実装した後のリクエスト数の減少を示すものです(ウェブサイトの一部はまだキャッシュされているため、最終結果ではありません):

  • ペイロードの削減: 埋め込み内で読み込まれるリソースを削減することは可能でしょうか?例:チャット URL や AI クレジットチェックのクエリが確認されましたが、これらは埋め込み表示に必要でしょうか?

  • リクエスト頻度: リアルタイムの POST リクエストがやや過剰です。埋め込み版ではポーリング頻度を下げることはできないでしょうか?

  • キャッシュ: トラフィックの急増に対応できるよう、埋め込みトピックのキャッシュ管理を改善する。

2. 分析データの混乱

現在、埋め込み部分で Google Analytics や GTM のスクリプトが発火しています。これによりページビューが倍増しています(投稿自体のヒットと、iframe のヒットの 2 回)。理想的には、システムが iframe 内であることを検知し、すべての追跡スクリプト(Discourse の分析スクリプトも含む)を自動的に無効化してくれると良いでしょう。

3. iframe の高さの問題

これはおそらく UX にとって最大の課題です。コメントがない投稿の場合、奇妙な空白の隙間が生まれます。長いスレッドがある場合、iframe は最初の 2〜3 件のコメントで切り捨てられ、「スクロール内のスクロール」を強制されます。これは特にモバイル環境では非常に問題があります。

Disqus のようなサービスと真に競合するには、高さ(コメント数に応じて)を動的に変更できるようにし、一定数の返信を超えた後にスレッドを展開する「もっと見る」ボタンが必要です。

4. プラグインの競合

埋め込みがすべてのアクティブなプラグインをロードするため、奇妙な動作が見られます。例えば、「Google One Tap」がブログ記事内に表示されてしまいます。ユーザーがログインすると、iframe がリフレッシュされ、コメントスレッドではなくコミュニティのホームページにリダイレクトされてしまいます。埋め込み表示に対して特定のプラグインを手動で無効化できる機能があれば、非常に助かります。

5. ログインの摩擦

現在のフローはコンバージョンを阻害しています:ユーザーがログインをクリック → 新しいタブが開く → ログイン完了 → ユーザーはコミュニティのホームページに留まる。ブログ記事に戻ると、ユーザーが手動でページ全体をリフレッシュするまで、iframe はまだログアウト状態のまま表示されます。これは混乱を招くループであり、人々はコメントする前に諦めて離脱してしまいます。

新しい埋め込み機能を有効にしてから、一日あたりの登録数が 2 倍以上に増加しましたが、これは素晴らしいことです。しかし、エンゲージメント指標は全く変化していません。むしろ、DAU/MAU が低下しました。ログインユーザー数は増えたものの、彼らは交流していません。「日次のアクティブユーザー」「新規投稿者」「投稿数」といった指標は増加していません。

これは、人々が会話に参加したいと望んでいる一方で、ログインのループに迷い込み、実際にコメントする前に投稿を離脱していることを証明しています。

6. モバイル UI

モバイルでは、返信ウィンドウが画面全体を占有するため、返信している会話の文脈をすべて失ってしまいます。少し閉鎖的な感じがします。これをよりコンパクトに保てるような改善があれば、大きな成果となるでしょう。


私はこれを Tecnoblog(および所有する他のサイト)のデフォルトシステムにしたいと本気で思っています。これらの点についてさらに詳しく議論したい場合は、お気軽にお知らせください!

「いいね!」 9

これは以下のプルリクエストで修正されます。

「いいね!」 7

詳細なフィードバックをありがとうございます、@Thiago_Mobilon さん!

リストを整理し、最終的にはすべてに対応できるよう努めます。

ここで確認したところ、あなたの Discourse サイトの CSS が誤って設定されているようです。cache-control ヘッダーが二重に設定されており、そのうちの一つが no-cache になっています。

curl -v https://tecnoblog.net/comunidade/stylesheets/common_cd45efa28175431b0b8ff143783178d55206920b.css?__ws=tecnoblog.net -s 2>&1 | grep cache-control
< cache-control: max-age=31556952, public, immutable
< cache-control: no-store, no-cache, must-revalidate, private
「いいね!」 6

Discourse 標準の Google アナリティクス統合機能を使用していますか?

「いいね!」 5

以下のプルリクエストでこれらを処理しています。

「いいね!」 6

対応済み

「いいね!」 8

おそらく Cloudflare が、/comunidade/ ディレクトリに対するキャッシュをバイパスした際にそのヘッダーを追加したのでしょう。これを削除しないと、Discourse の CSS や JS にも Cloudflare のキャッシュルールが適用され、将来的に競合を引き起こす可能性があります。

いずれにせよ、キャッシュの問題を取り上げた主な目的は、サーバー負荷を軽減することでした。CSS ファイルは静的ファイルですよね?もしそうなら、キャッシュされていないという事実は望ましくありませんが、サーバー負荷に直接影響するわけではありません。

「いいね!」 2

私は Google タグマネージャーとの Discourse 統合を利用しています。

「いいね!」 1

ただし、これらはエンドユーザーのパフォーマンスに影響します。なぜなら、すべての記事で 59 のリクエストが発生し、1.43MB の CSS(圧縮して 340KB)がダウンロードされるからです。

また、これらは Ruby サーバーによって提供されています。サイトがキャッシュを破損させないことを前提としているため、通常条件下ではこのルートは非常にまれにしか使用されません。

私の認識が間違っていなければ、キャッシュが破損した状態でこれらを提供すると、データベースにまでアクセスしてしまいます。

「いいね!」 1

素晴らしいアイデアですね。ネイティブサポートを追加します。

「いいね!」 7

これは外出先での投稿作成に共通する課題であり、以下の改善によって解決が期待されます:Creating/Editing a post on mobile: let's discuss the 2026 Discourse experience

「いいね!」 5

匿名ユーザーがトピックページにアクセスする際、素晴らしいキャッシュ機能が備わっており、この新しいモードもカバーしています。そのため、十分な数のPitchforkワーカーとRedis I/Oワーカーが用意されていれば、トラフィックの急増にもスムーズに対応できるはずです。

「いいね!」 2

プーリングは、バックグラウンドタブや高負荷イベント時に自動的に頻度を下げる仕組みになっています。このケースでも同様に適用されるはずです。

「いいね!」 2

それらのタグ付けに同意しました

「いいね!」 5

動的な高さが正しく機能しないという問題に直面しています。Discourse を更新し、スニペットを最新の構成で更新しても、問題は解決しません。

        <h4 class="comments-main-title component-title">コメント</h4>
        <div id='discourse-comments'></div>

        <meta name='discourse-username' content='<?php echo esc_attr($discourse_author); ?>'>

        <script type="text/javascript">
            DiscourseEmbed = {
                discourseUrl: '<?php echo esc_url($discourse_url); ?>',
                
                <?php if ($use_topic_id): ?>
                    // ID モード:データベースに保存されたトピック、URL の変更の影響を受けない
                    topicId: <?php echo intval($topic_id); ?>,
                <?php else: ?>
                    // URL モード:API 経由での作成が失敗した場合のフォールバック
                    discourseEmbedUrl: '<?php echo esc_url($permalink); ?>',
                <?php endif; ?>
                fullApp: true,
                lazyLoad: true, // iframe の遅延読み込みを無効化
                lazyLoadMargin: '1500', // ビューポートから何ピクセル手前で読み込みを開始するか
                dynamicHeight: true,
                embedMinHeight: '400',
                embedMaxHeight: '3000',
					  embedHeight: '800px',
                // className: 'CLASS_NAME',
            };

            (function() {
            var d = document.createElement('script'); d.type = 'text/javascript'; d.async = true;
            d.src = DiscourseEmbed.discourseUrl + 'javascripts/embed.js';
            (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(d);
            })();
        </script>

https://tecnoblog.net/noticias/samsung-wallet-agora-suporta-pix-por-aproximacao/

「いいね!」 1

ここで <iframe loading="lazy"> を使用することはできますか?そうすれば、カスタム JS や Intersection Observer が不要になりますよね?

「いいね!」 1

それは今やブラウザで広くサポートされているんですね!初めて知りました。できるだけ早く変更します。

「いいね!」 5

テストいただきありがとうございます。問題が見つかりました

「いいね!」 3

素晴らしい!動的な高さが期待通りに機能しています。ただし、これにより小さな問題が発生しました。返信をクリックすると、返信の入力フィールドが iframe の高さに調整しようとするのですが、この場合、誤って高さが 7385px になってしまいました。

投稿には 31 件のコメントが含まれており、埋め込まれた iframe の高さは 9757px でした(embedMaxHeight は 15000px に設定していました)。

https://tecnoblog.net/noticias/samsung-wallet-agora-suporta-pix-por-aproximacao/

追記:実際、コメントフォームが iframe の高さを最大値まで拡張していることに気づきました。そのため、「破棄」をクリックすると、コメントの下に巨大な空白スペースが残ってしまう状態になります。

Screenshot 2026-04-16 at 16.03.37

「いいね!」 2

より妥当な値、例えば 1000〜1500px 程度に max-height を設定する必要があると思います。

これにより、以下の初期の問題が解決されます。

ある程度までは拡大しますが、Discourse のネイティブな無限スクロールの挙動を考慮すると、高さを大幅に増やすことは望ましくありません。

この機能によって直ちに「スクロール内のスクロール」が解消されることはありません。

モバイル版のコンポーザーについては、対応可能な策を検討しています。

「いいね!」 3