Hi there!
I’m really excited about this new feature. I’ve been waiting for a solution like this for a long time, and the initial feedback from our readers at Tecnoblog has been great – they love having the community integrated.
However, after some real-world testing, I’ve spotted a few technical hurdles we need to clear to make this feel like a truly native commenting system and, more importantly, to make it sustainable for high-traffic sites.
Here’s what I’ve found so far:
1. Performance & Server Load
Our server load spiked significantly after we embedded the full app. Looking at Cloudflare, our request volume multiplied by 10. A few ideas on how to optimize this:
- Lazy Loading: Implementing lazy load for the JS helps a lot (I’m already using a workaround for this).
<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>
Here you can see the number of requests dropping after the Lazy Load was implemented (and some parts of the website were still cached, so it’s not the final result):
-
Stripping the payload: Can we reduce the resources loaded within the embed? Ex: i noticed queries for Chat URLs and AI credit checks—are these necessary for the embed view?
-
Request Frequency: The real-time POST requests are a bit aggressive. Maybe we can dial back the polling frequency for the embed version?
-
Cache: Improved cache management for embedded topics to handle traffic spikes.
2. Analytics Mess
Right now, the embed is firing Google Analytics/GTM scripts. This is doubling our pageviews (one hit for the post, another for the iframe), which messes up our data. It would be ideal if the system could detect it’s in an iframe and kill any tracking scripts automatically (the Discourse analytics too).
3. The iFrame Height Issue
This is probably the biggest hurdle for UX. If a post has no comments, there’s a weird empty gap. If it has a long thread, the iframe gets cut off within the first 2 or 3 comments, forcing a “scroll-within-a-scroll” which is pretty bad, especially on mobile.
To really compete with something like Disqus, we need the height to be dynamic (according to the number of comments) and also have a “Read More” button that expands the thread after a certain number of replies.
4. Plugin Conflicts
Since the embed loads all active plugins, we’re seeing some weird behavior. For example, “Google One Tap” pops up inside the blog post. When a user logs in, the iframe refreshes and drops them on the community homepage instead of the comment thread. Being able to manually disable specific plugins for the embed view would be a lifesaver.
5. Login Friction
The current flow is a bit of a conversion killer: User clicks login → New tab opens → Login happens → User is left on the community homepage. Back on the blog post, the iframe still looks logged out until the user manually refreshes the whole page. It’s a confusing loop that makes people give up and leave before commenting.
Since we activated the new embed, our daily registrations have more than doubled, which is great. However, our engagement metrics haven’t moved at all. In fact, our DAU/MAU dropped – we have more logged-in users, but they aren’t interacting. Metrics like “Daily Engaged Users,” “New Contributors,” and “Postings” haven’t seen any increase.
This proves that people want to join the conversation, but they’re getting lost in the login loop and abandoning the post before they can actually comment.
6. Mobile UI
On mobile, the reply window takes up the entire screen, so you lose all context of the conversation you’re replying to. It feels a bit claustrophobic—anything we can do to keep it more compact would be a huge win.
I really want to make this the default system for Tecnoblog (and also in another site we own). Let me know if you want to dive deeper into any of these points!
