Experiência do Tecnoblog com comentários no Discourse

Olá!

Estou realmente animado com esse novo recurso. Tenho esperado por uma solução como essa há muito tempo, e o feedback inicial dos nossos leitores no Tecnoblog foi ótimo — eles adoram ter a comunidade integrada.

No entanto, após alguns testes em cenários reais, identifiquei algumas barreiras técnicas que precisamos superar para fazer com que isso pareça um sistema de comentários verdadeiramente nativo e, mais importante, para torná-lo sustentável para sites de alto tráfego.

Aqui está o que descobri até agora:

1. Desempenho e Carga no Servidor

Nossa carga no servidor aumentou significativamente após incorporarmos o aplicativo completo. Analisando o Cloudflare, nosso volume de requisições multiplicou por 10. Algumas ideias sobre como otimizar isso:

  • Carregamento Diferido (Lazy Loading): Implementar o lazy load para o JS ajuda muito (já estou usando uma solução alternativa para isso).
            <script type="text/javascript">
                DiscourseEmbed = {
                    discourseUrl: '<?php echo esc_url($discourse_url); ?>',
                    
                    <?php if ($use_topic_id): ?>
                        // Modo ID: Tópico salvo no banco, imune a mudanças de URL
                        topicId: <?php echo intval($topic_id); ?>,
                    <?php else: ?>
                        // Modo URL: Fallback quando a criação via API falha
                        discourseEmbedUrl: '<?php echo esc_url($permalink); ?>',
                    <?php endif; ?>
                    fullApp: true,
                    embedHeight: '800px',
                };

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

                    // Verifica se o navegador suporta IntersectionObserver
                    if ('IntersectionObserver' in window) {
                        var observer = new IntersectionObserver(function(entries, observer) {
                            entries.forEach(function(entry) {
                                if (entry.isIntersecting) {
                                    // Quando o div entra na tela, carrega o script
                                    loadDiscourse();
                                    observer.unobserve(entry.target);
                                }
                            });
                        }, { rootMargin: "1500px" }); // Carrega 1500px antes de chegar no div

                        observer.observe(container);
                    } else {
                        // Fallback para navegadores antigos
                        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>

Aqui você pode ver a redução no número de requisições após a implementação do Lazy Load (e algumas partes do site ainda estavam em cache, então não é o resultado final):

  • Redução do Payload: Podemos reduzir os recursos carregados dentro da incorporação? Por exemplo: notei consultas para URLs de Chat e verificações de crédito de IA — são necessárias para a visualização incorporada?

  • Frequência de Requisições: As requisições POST em tempo real são um pouco agressivas. Talvez possamos reduzir a frequência de polling para a versão incorporada?

  • Cache: Gerenciamento de cache aprimorado para tópicos incorporados para lidar com picos de tráfego.

2. Bagunça na Análise de Dados (Analytics)

Atualmente, a incorporação está disparando scripts do Google Analytics/GTM. Isso está dobrando nossas visualizações de página (um hit para o post, outro para o iframe), o que distorce nossos dados. Seria ideal se o sistema pudesse detectar que está em um iframe e desativar automaticamente qualquer script de rastreamento (incluindo as análises do Discourse).

3. O Problema da Altura do Iframe

Este é provavelmente o maior obstáculo para a UX. Se um post não tem comentários, há uma estranha lacuna vazia. Se tiver um thread longo, o iframe é cortado nos primeiros 2 ou 3 comentários, forçando uma “rolagem dentro de uma rolagem”, o que é bastante ruim, especialmente no mobile.

Para realmente competir com algo como o Disqus, precisamos que a altura seja dinâmica (de acordo com o número de comentários) e também ter um botão “Ler Mais” que expanda o thread após um certo número de respostas.

4. Conflitos de Plugin

Como a incorporação carrega todos os plugins ativos, estamos vendo alguns comportamentos estranhos. Por exemplo, o “Google One Tap” aparece dentro do post do blog. Quando um usuário faz login, o iframe é atualizado e o leva para a página inicial da comunidade em vez do thread de comentários. Poder desabilitar manualmente plugins específicos para a visualização incorporada seria uma salvação.

5. Atrito no Login

O fluxo atual é um pouco um assassino de conversão: Usuário clica em login → Abre nova aba → Login acontece → Usuário fica na página inicial da comunidade. De volta ao post do blog, o iframe ainda parece deslogado até que o usuário atualize manualmente toda a página. É um ciclo confuso que faz as pessoas desistirem e saírem antes de comentar.

Desde que ativamos a nova incorporação, nossos cadastros diários mais que dobraram, o que é ótimo. No entanto, nossas métricas de engajamento não se moveram. Na verdade, nosso DAU/MAU caiu — temos mais usuários logados, mas eles não estão interagindo. Métricas como “Usuários Engajados Diariamente”, “Novos Contribuidores” e “Publicações” não apresentaram nenhum aumento.

Isso prova que as pessoas querem participar da conversa, mas estão se perdendo no ciclo de login e abandonando o post antes de poderem realmente comentar.

6. UI Mobile

No mobile, a janela de resposta ocupa toda a tela, então você perde todo o contexto da conversa à qual está respondendo. Parece um pouco claustrofóbico — qualquer coisa que possamos fazer para mantê-la mais compacta seria uma grande vitória.


Quero muito tornar isso o sistema padrão do Tecnoblog (e também em outro site que possuímos). Me avise se quiser se aprofundar em algum desses pontos!

8 curtidas

Isso será corrigido por

6 curtidas

Obrigado pelo feedback detalhado, @Thiago_Mobilon!

Vou trabalhar na lista e tentar cobrir tudo eventualmente.

Acabei de fazer uma verificação aqui e parece que o CSS está mal configurado no seu site Discourse. Você tem cabeçalhos cache-control duplicados, e um deles é 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
4 curtidas

Você está usando a integração nativa do Google Analytics do Discourse?

3 curtidas

Tratando isso em

4 curtidas

Resolvido em

7 curtidas

Acredito que o Cloudflare deve ter adicionado esse cabeçalho porque eu contornei o cache para o diretório /comunidade/. Se eu não o remover, ele aplicará suas regras de cache ao CSS e JS do Discourse, o que poderia potencialmente criar conflitos mais tarde.

De qualquer forma, quando abordei a questão do cache, foi mais com o objetivo de reduzir a carga no servidor. Os arquivos CSS são estáticos, correto? Se sim, o fato de não estarem em cache, embora indesejável, não impactaria diretamente a carga do servidor.

2 curtidas

Estou utilizando a integração do Discourse com o Google Tag Manager.

1 curtida

Eles impactam o desempenho do usuário final, pois são 59 requisições baixando 1,43 MB de CSS (comprimido para 340 KB) em cada artigo.

Além disso, eles também são servidos pelo servidor Ruby, já que esperamos que os sites não quebrem o cache, o que significa que, em condições normais, essa rota é muito raramente utilizada.

Se não estou enganado, servir esses arquivos com o cache quebrado significa que eles até acessam o banco de dados.

1 curtida

Essa é uma ótima ideia, estou adicionando suporte nativo para isso

6 curtidas

Isso é um problema mais geral ao escrever em movimento e se beneficiará das melhorias em Creating/Editing a post on mobile: let's discuss the 2026 Discourse experience.

4 curtidas

Temos um cache incrível para usuários anônimos acessando páginas de tópicos, e ele também cobre esse novo modo, então você deve conseguir escalar bem para lidar com picos, desde que haja trabalhadores suficientes do Pitchfork e trabalhadores de I/O do Redis.

2 curtidas

O pooling reduz automaticamente a frequência em abas em segundo plano ou durante eventos de alta carga, e o mesmo deve se aplicar aqui.

2 curtidas

Optei por marcar aqueles em

5 curtidas