Опыт 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" }); // Загружаем за 1500px до появления div

                        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), что искажает наши данные. Было бы идеально, если бы система могла определять, что она находится внутри iframe, и автоматически отключать любые скрипты отслеживания (включая аналитику Discourse).

3. Проблема высоты iframe

Это, пожалуй, самое большое препятствие для UX. Если у поста нет комментариев, появляется странная пустая дыра. Если есть длинная ветка, iframe обрезается уже после первых 2–3 комментариев, вынуждая прокручивать «скролл внутри скролла», что очень плохо, особенно на мобильных устройствах.

Чтобы реально конкурировать с такими решениями, как Disqus, нам нужна динамическая высота (в зависимости от количества комментариев), а также кнопка «Читать далее», которая разворачивает ветку после определенного количества ответов.

4. Конфликты плагинов

Поскольку встраивание загружает все активные плагины, мы наблюдаем странное поведение. Например, «Google One Tap» появляется внутри поста блога. Когда пользователь входит в систему, iframe обновляется и перекидывает его на главную страницу сообщества вместо ветки комментариев. Возможность вручную отключать определенные плагины для режима встраивания была бы спасением.

5. Трение при входе в систему

Текущий процесс немного убивает конверсию: Пользователь нажимает «Войти» → Открывается новая вкладка → Происходит вход → Пользователь остается на главной странице сообщества. Вернувшись к посту блога, iframe все еще выглядит как неавторизованный, пока пользователь вручную не обновит всю страницу. Это запутанный цикл, который заставляет людей сдаваться и уходить, прежде чем они смогут прокомментировать.

Поскольку мы активировали новое встраивание, наши ежедневные регистрации выросли более чем в два раза, что отлично. Однако метрики вовлеченности не изменились. Более того, показатель DAU/MAU упал — у нас больше авторизованных пользователей, но они не взаимодействуют. Метрики, такие как «Ежедневные активные пользователи», «Новые участники» и «Публикации», не показали никакого роста.

Это доказывает, что люди хотят присоединиться к разговору, но они теряются в цикле входа в систему и бросают пост, так и не успев прокомментировать.

6. Мобильный интерфейс

На мобильных устройствах окно ответа занимает весь экран, поэтому вы теряете весь контекст разговора, на который отвечаете. Это кажется немного клаустрофобичным — если мы сможем сделать его более компактным, это будет огромным успехом.


Я очень хочу сделать эту систему системой по умолчанию для Tecnoblog (а также для другого сайта, которым мы владеем). Дайте знать, если хотите углубиться в любой из этих пунктов!

7 лайков

Это будет исправлено в

5 лайков

Спасибо за подробный отзыв, @Thiago_Mobilon!

Я проработаю список и постараюсь в итоге охватить всё.

Я только что проверил здесь, и, похоже, ваш CSS на сайте Discourse настроен неверно. У вас дублируются заголовки 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
3 лайка

Вы используете встроенную интеграцию Google Analytics в Discourse?

2 лайка

Обработка этого в

3 лайка

Реализовано в

6 лайков

Думаю, Cloudflare добавил этот заголовок, потому что я обошел кэширование для директории /comunidade/. Если я не удалю его, он применит свои правила кэширования к CSS и JS файлам Discourse, что в будущем может создать конфликты.

В любом случае, когда я поднимал вопрос о кэшировании, моя цель заключалась скорее в снижении нагрузки на сервер. Файлы CSS статичны, верно? Если да, то тот факт, что они не кэшируются, хоть и нежелателен, не должен напрямую влиять на нагрузку сервера.

2 лайка

Я использую интеграцию Discourse с Google Tag Manager.

1 лайк

Они влияют на производительность конечного пользователя, так как при каждой загрузке статьи выполняется 59 запросов на скачивание 1,43 МБ CSS (сжатого до 340 КБ).

Кроме того, они также обслуживаются Ruby-сервером, так как мы ожидаем, что сайты не будут нарушать работу кэша, что означает, что в нормальных условиях этот маршрут используется крайне редко.

Если я не ошибаюсь, при обслуживании этих файлов с нарушенным кэшем происходит даже обращение к базе данных.

1 лайк

Отличная идея, я добавляю нативную поддержку этого

5 лайков

Это более общая проблема написания сообщений «на ходу», и её решение выиграет от улучшений, обсуждаемых здесь: Creating/Editing a post on mobile: let's discuss the 2026 Discourse experience.

4 лайка

У нас есть отличный кэш для анонимных пользователей, обращающихся к страницам тем, и он также охватывает этот новый режим, поэтому вы сможете эффективно масштабироваться для обработки всплесков, при условии наличия достаточного количества воркеров Pitchfork и воркеров ввода-вывода Redis.

2 лайка

Оптимизация автоматически снижает частоту опроса во вкладках, находящихся в фоновом режиме, или во время событий с высокой нагрузкой, и то же самое должно применяться здесь.

2 лайка

Решено добавить теги для этого

4 лайка