안녕하세요!
이 새로운 기능에 정말 기대가 큽니다. 이렇게 좋은 솔루션을 오랫동안 기다려 왔는데, Tecnoblog의 독자분들로부터 받은 초기 피드백도 매우 좋습니다. 커뮤니티가 통합된 것을 매우 좋아하고 있습니다.
그러나 실제 환경에서 테스트를 해본 결과, 이 기능이 진정한 네이티브 댓글 시스템처럼 느껴지려면, 그리고 무엇보다 높은 트래픽을 처리하는 사이트에서 지속 가능하려면 몇 가지 기술적 장벽을 해결해야 할 것 같습니다.
현재까지 발견한 내용은 다음과 같습니다:
1. 성능 및 서버 부하
전체 앱을 임베드한 후 서버 부하가 크게 증가했습니다. Cloudflare를 확인해 보니 요청량이 10배로 증가했습니다. 이를 최적화하기 위한 몇 가지 아이디어를 제안합니다:
- 레이지 로딩(Lazy Loading): JS에 대해 레이지 로딩을 구현하면 도움이 많이 됩니다(이미 이를 위한 임시 대안을 사용하고 있습니다).
<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>
레이지 로딩 구현 후 요청 수가 감소하는 것을 확인할 수 있습니다(웹사이트의 일부가 여전히 캐시되어 있어 최종 결과는 아닙니다):
-
페이로드 제거: 임베드 내에서 로드되는 리소스를 줄일 수 있을까요? 예: 채팅 URL 쿼리와 AI 크레딧 확인 요청을 발견했는데, 임베드 뷰에서 이것이 필요한가요?
-
요청 빈도: 실시간 POST 요청이 다소 공격적입니다. 임베드 버전의 경우 폴링 빈도를 낮출 수 있을까요?
-
캐시: 트래픽 급증을 처리하기 위해 임베드된 토픽의 캐시 관리를 개선해야 합니다.
2. 분석 데이터 혼란
현재 임베드는 Google Analytics/GTM 스크립트를 실행하고 있습니다. 이로 인해 페이지뷰가 두 배로 집계됩니다(게시물 1회, iframe 1회)하여 데이터가 왜곡됩니다. 시스템이 iframe 내부에 있음을 감지하고 추적 스크립트(또는 Discourse 분석 기능 포함)를 자동으로 비활성화할 수 있다면 이상적입니다.
3. iFrame 높이 문제
이것은 UX 측면에서 가장 큰 장벽일 수 있습니다. 댓글이 없는 게시물의 경우 이상한 빈 공간이 생깁니다. 긴 스레드가 있는 경우, iframe은 처음 2~3개의 댓글에서 잘려나가고, 이는 특히 모바일에서 매우 불편한 “스크롤 안의 스크롤” 상황을 초래합니다.
Disqus와 같은 서비스와 경쟁하려면 높이가 동적이어야 합니다(댓글 수에 따라 조절). 또한 특정 답변 수 이후에 스레드를 확장하는 “더 보기” 버튼이 있어야 합니다.
4. 플러그인 충돌
임베드가 모든 활성 플러그인을 로드하기 때문에 일부 이상한 동작이 관찰됩니다. 예를 들어, "Google One Tap"이 블로그 게시물 내부에 팝업으로 나타납니다. 사용자가 로그인하면 iframe이 새로고침되어 커뮤니티 홈페이지만 아니라 댓글 스레드로 이동하지 않습니다. 임베드 뷰에서 특정 플러그인을 수동으로 비활성화할 수 있다면 큰 도움이 될 것입니다.
5. 로그인 마찰
현재 플로우가 전환율을 크게 떨어뜨리는 요인입니다: 사용자가 로그인을 클릭 → 새 탭이 열림 → 로그인 완료 → 사용자가 커뮤니티 홈페이에 머무름. 블로그 게시물로 돌아와도 사용자가 전체 페이지를 수동으로 새로고침할 때까지 iframe은 여전히 로그아웃 상태로 보입니다. 이는 사용자가 댓글을 달기 전에 포기를 하고 이탈하게 만드는 혼란스러운 루프입니다.
새로운 임베드를 활성화한 후, 일일 신규 가입자가 두 배 이상 증가하여 좋습니다. 그러나 참여 지표는 전혀 변하지 않았습니다. 실제로 DAU/MAU 비율이 하락했습니다. 로그인한 사용자는 더 많지만, 그들이 상호작용하지 않고 있기 때문입니다. “일일 참여 사용자”, “신규 기여자”, "게시물 작성 수"와 같은 지표는 어떤 증가도 보이지 않았습니다.
이것은 사람들이 대화에 참여하고 싶어 하지만, 로그인 루프에서 길을 잃어 실제로 댓글을 달기 전에 게시물을 이탈한다는 것을 증명합니다.
6. 모바일 UI
모바일에서 답변 창이 화면 전체를 차지하여 답변하려는 대화의 맥락을 모두 잃게 됩니다. 다소 답답한 느낌이 드는데, 더 컴팩트하게 유지할 수 있는 방법이 있다면 큰 성과가 될 것입니다.
Tecnoblog(그리고 우리가 소유하는 다른 사이트)에서 이것이 기본 시스템이 되기를 정말 바랍니다. 이 중 어떤 항목에 대해 더 깊이 논의하고 싶으신지 알려주세요!
