تجربة تكنوبلوج مع تعليقات ديسكورش

مرحباً!

أنا متحمس جداً لهذه الميزة الجديدة. لقد كنت أنتظر حلاً مثل هذا منذ فترة طويلة، وكانت التغذية الراجعة الأولية من قرائنا في موقع تيكينوبلوج رائعة — فهم يحبون دمج المجتمع.

ومع ذلك، بعد بعض الاختبارات في بيئة حقيقية، لاحظت عددًا من العقبات التقنية التي يجب تجاوزها لجعل هذا النظام يبدو كنظام تعليقات أصلي حقًا، والأهم من ذلك، لجعله مستدامًا للمواقع ذات الزيارات العالية.

إليك ما اكتشفته حتى الآن:

1. الأداء وعبء الخادم

ارتفع عبء الخادم لدينا بشكل ملحوظ بعد دمج التطبيق بالكامل. وعند النظر إلى بيانات Cloudflare، نجد أن حجم الطلبات تضاعف بعشر مرات. إليك بعض الأفكار حول كيفية تحسين ذلك:

  • التحميل الكسول (Lazy Loading): يساعد تطبيق التحميل الكسول لملفات JavaScript بشكل كبير (أنا أستخدم بالفعل حلاً بديلاً لهذا الغرض).
            <script type="text/javascript">
                DiscourseEmbed = {
                    discourseUrl: '<?php echo esc_url($discourse_url); ?>',
                    
                    <?php if ($use_topic_id): ?>
                        // وضع المعرف: الموضوع محفوظ في قاعدة البيانات، محصن ضد تغييرات الرابط
                        topicId: <?php echo intval($topic_id); ?>,
                    <?php else: ?>
                        // وضع الرابط: حل بديل عند فشل الإنشاء عبر واجهة برمجة التطبيقات
                        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) {
                                    // عند دخول العنصر إلى الشاشة، قم بتحميل السكربت
                                    loadDiscourse();
                                    observer.unobserve(entry.target);
                                }
                            });
                        }, { rootMargin: "1500px" }); // التحميل قبل 1500 بكسل من الوصول إلى العنصر

                        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>

هنا يمكنك رؤية انخفاض عدد الطلبات بعد تطبيق التحميل الكسول (وبعض أجزاء الموقع كانت لا تزال مخزنة مؤقتًا، لذا فهذا ليس النتيجة النهائية):

  • تقليل حجم البيانات المرسلة: هل يمكننا تقليل الموارد المحملة داخل التضمين؟ على سبيل المثال: لاحظت استعلامات لروابط الدردشة وفحوصات رصيد الذكاء الاصطناعي — هل هذه ضرورية لعرض التضمين؟

  • تكرار الطلبات: طلبات POST في الوقت الفعلي تبدو عدوانية بعض الشيء. ربما يمكننا تقليل تردد الاستجواب في إصدار التضمين؟

  • التخزين المؤقت (Cache): تحسين إدارة التخزين المؤقت للمواضيع المضمنة للتعامل مع ذروات الزيارات.

2. فوضى التحليلات

حاليًا، يقوم التضمين بتشغيل سكريبتات Google Analytics/GTM. هذا يؤدي إلى مضاعفة عدد مرات مشاهدة الصفحة (ضربة واحدة للمقال وأخرى للإطار المضمن)، مما يشوه بياناتنا. سيكون من المثالي إذا كان النظام قادرًا على اكتشاف أنه داخل إطار مضمن وإيقاف أي سكريبتات تتبع تلقائيًا (بما في ذلك تحليلات Discourse).

3. مشكلة ارتفاع الإطار المضمن (iFrame Height)

هذه ربما تكون أكبر عائق أمام تجربة المستخدم. إذا كان للمقال تعليقات، فهناك فجوة فارغة غريبة. وإذا كان هناك موضوع طويل، يتم قص الإطار المضمن بعد أول تعليقين أو ثلاثة، مما يجبر المستخدم على “التنقل داخل تنقل”، وهو أمر سيء للغاية، خاصة على الهواتف المحمولة.

للمنافسة حقًا مع أنظمة مثل Disqus، نحتاج إلى أن يكون الارتفاع ديناميكيًا (وفقًا لعدد التعليقات) وأن يكون هناك زر “اقرأ المزيد” يقوم بتوسيع الموضوع بعد عدد معين من الردود.

4. تضارب الإضافات

بما أن التضمين يحمل جميع الإضافات النشطة، نلاحظ بعض السلوكيات الغريبة. على سبيل المثال، يظهر “Google One Tap” داخل مدونة المدونة. عندما يسجل المستخدم الدخول، يتم تحديث الإطار المضمن ويقوم بإسقاط المستخدم على الصفحة الرئيسية للمجتمع بدلاً من موضوع التعليقات. القدرة على تعطيل إضافات معينة يدويًا لعرض التضمين ستكون منقذة للحياة.

5. احتكاك تسجيل الدخول

تدفق العمل الحالي يقتل التحويلات بعض الشيء: يضغط المستخدم على تسجيل الدخول → يفتح تبويب جديد → يتم تسجيل الدخول → يترك المستخدم على الصفحة الرئيسية للمجتمع. عند العودة إلى مدونة المدونة، لا يزال الإطار المضمن يبدو وكأنه غير مسجل الدخول حتى يقوم المستخدم بتحديث الصفحة بالكامل يدويًا. إنها حلقة مربكة تجعل الناس يستسلمون ويغادرون قبل التعليق.

منذ تفعيلنا للتضمين الجديد، ازدادت التسجيلات اليومية بأكثر من الضعف، وهو أمر رائع. ومع ذلك، لم تتحرك مقاييس المشاركة على الإطلاق. في الواقع، انخفضت نسبة المستخدمين النشطين يوميًا إلى الشهرية (DAU/MAU) — لدينا مستخدمون مسجلون دخول أكثر، لكنهم لا يتفاعلون. لم تزد مقاييس مثل “المستخدمون النشطون يوميًا” و"المساهمون الجدد" و"النشر" بأي زيادة.

هذا يثبت أن الناس يريدون الانضمام إلى المحادثة، لكنهم يضيعون في حلقة تسجيل الدخول ويتخلون عن المقال قبل أن يتمكنوا فعليًا من التعليق.

6. واجهة المستخدم على الجوال

على الجوال، نافذة الرد تشغل الشاشة بأكملها، مما يفقدك سياق المحادثة التي ترد عليها. الشعور قليلاً بالاختناق — أي شيء يمكننا فعله للحفاظ على إبقائها أكثر إحكامًا سيكون فوزًا كبيرًا.


أنا أريد حقًا أن أجعل هذا النظام الافتراضي لـ Tecnoblog (وأيضًا في موقع آخر نملكه). أخبرني إذا كنت ترغب في الغوص بعمق في أي من هذه النقاط!

8 إعجابات

سيتم إصلاح هذا عبر

6 إعجابات

شكرًا لك على الملاحظات التفصيلية @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
4 إعجابات

هل تستخدم تكامل Google Analytics المدمج في Discourse؟

3 إعجابات

معالجة هذه الأمور في

4 إعجابات

تم التعامل معه في

7 إعجابات

أعتقد أن Cloudflare يجب أن تكون قد أضافت هذا الرأس لأنني تجاوزت التخزين المؤقت لمجلد /comunidade/. إذا لم أقوم بإزالته، فسيطبق قواعد التخزين المؤقت الخاصة به على ملفات CSS و JS الخاصة بـ Discourse، مما قد يؤدي إلى نشوء تعارضات لاحقًا.

على أي حال، عندما أثيرت مسألة التخزين المؤقت، كان الهدف الرئيسي منها هو تقليل الحمل على الخادم. ملفات CSS ثابتة، أليس كذلك؟ إذا كان الأمر كذلك، فإن حقيقة عدم تخزينها مؤقتًا، رغم أنها غير مرغوب فيها، لن تؤثر بشكل مباشر على حمل الخادم.

إعجابَين (2)

أنا أستخدم تكامل Discourse مع Google Tag Manager.

إعجاب واحد (1)

تؤثر على أداء المستخدم النهائي، حيث أنها تتطلب 59 طلبًا لتحميل 1.43 ميجابايت من ملفات CSS (مضغوطة إلى 340 كيلوبايت) في كل مقال.

كما يتم تقديمها بواسطة خادم Ruby، حيث نتوقع أن المواقع لا تكسر التخزين المؤقت، مما يعني أنه في الظروف العادية يُستخدم هذا المسار نادرًا جدًا.

إذا لم أكن مخطئًا، فإن تقديم هذه الملفات مع تخزين مؤقت مكسور يعني أنها تصل حتى إلى قاعدة البيانات.

إعجاب واحد (1)

هذه فكرة رائعة، سأضيف دعمًا أصليًا لها

6 إعجابات

هذه مشكلة أكثر عمومية تتعلق بالتأليف أثناء التنقل، وستستفيد من التحسينات في Creating/Editing a post on mobile: let's discuss the 2026 Discourse experience.

4 إعجابات

لدينا ذاكرة مؤقتة مذهلة للمستخدمين المجهولين الذين يصلون إلى صفحات المواضيع، وهي تغطي أيضًا هذا الوضع الجديد، لذا يجب أن تتمكن من التوسع بشكل جيد للتعامل مع الزيادات المفاجئة طالما أن هناك عددًا كافيًا من عمال Pitchfork وعمال I/O لـ Redis.

إعجابَين (2)

يقلل التجميع تلقائيًا من التكرار في علامات التبويب الخلفية أو أثناء أحداث الحمل المرتفع، وينبغي أن ينطبق نفس الشيء هنا.

إعجابَين (2)

تم تفعيل وضع العلامات لتلك

5 إعجابات