لوحة Kanban تعتمد على الخادم تتفوق في مقارنة لوحة PLANKA على الشبكات البطيئة

أظهر اختبار أداء يقارن بين لوحة Kanban مخصصة تعتمد على الخادم وتطبيق الصفحة الواحدة الشهير PLANKA Community 2.2.1 تفوقاً كبيراً في السرعة لصالح تقنية HTML المعتمدة على الخادم عند استخدام اتصالات الشبكة البطيئة. وقيست اللوحة المخصصة، المبنية باستخدام ملف تنفيذي واحد بلغة Go وملف قاعدة بيانات SQLite ومكتبة Datastar في المتصفح، مقابل حزمة PLANKA التي تعتمد على React و Node.js و PostgreSQL. وفي مقارنة لوحة PLANKA هذه، استضاف كلا التطبيقين لوحات متطابقة، وقاس الاختبار تجربة مستخدم يعتمد على هاتف أُبطئ أداؤه مع تأخير في الشبكة يبلغ 150 مللي ثانية ذهاباً وإياباً.

يدعم كلا التطبيقين ميزات Kanban الأساسية: تسجيل الدخول، وإدارة القوائم، وسحب البطاقات وإفلاتها، والتنقل باستخدام لوحة المفاتيح، وكتابة الوصف بتنسيق Markdown، والملصقات، ومواعيد الاستحقاق، والتعليقات، والتعاون المباشر. ويتضمن تطبيق PLANKA ميزات إضافية تفتقر إليها اللوحة المخصصة، مثل إضافة أعضاء للبطاقات، والبحث، والفلاتر، والمرفقات، وقوائم المهام، والحقول المخصصة، والإشعارات، وخطافات الويب (Webhooks)، وواجهة برمجة التطبيقات (REST API)، وتسجيل الدخول بالمصادقة الثنائية (2FA). وركزت الاختبارات فقط على القدرات المشتركة، رغم أن حجم حزمة PLANKA واستهلاكها للذاكرة يشملان مجموعة ميزاتها الكاملة.

يُعد كل إجراء على اللوحة المخصصة طلب POST يُعدّل قاعدة البيانات ويُرجع استجابة 204 فارغة. وتدير عملية Goroutine واحدة اتصال الكتابة الوحيد، وتنفذ الأوامر المصطفة في معاملة واحدة. وتُعرض اللوحة كل 50 مللي ثانية كحد أقصى، ويُرسل الخادم كود HTML المُحدّث عبر تدفق مفتوح من الأحداث المرسلة من الخادم إلى كل صفحة متصلة. ثم تدمج مكتبة Datastar كود HTML الجديد في المستند.

وللتعامل مع الحالات المعلقة، تبقى البطاقة المُفلتة في المكان الذي وضعها فيه الخادم آخر مرة، وتظهر باهتة مع مؤشر تحميل حتى يصل الإطار الجديد. وتعرض اللوحة أيضاً نسخة متقطعة الخطوط من البطاقة في الموقع الجديد للإشارة إلى إجراء المستخدم. وإذا رفض الخادم النقل، تبقى البطاقة في موضعها الأصلي، وتعرض الصفحة رسالة توضح السبب، مثل «نقلت Anna بطاقة 'Fix login' إلى 'Done' في هذه الأثناء».

عمل كلا التطبيقين وقاعدة البيانات والمتصفح على جهاز واحد بمعالج Intel i5-13500. واحتوت لوحة الاختبار على 8 قوائم و 200 بطاقة و 268 تعليقاً. وأضاف خادم وكيل TCP تأخيراً قدره 150 مللي ثانية ذهاباً وإياباً، وحدد النطاق الترددي عند 1.6 ميجابت/ثانية للتنزيل و 750 كيلوبت/ثانية للرفع. وخفّض متصفح Chrome أداء وحدة المعالجة المركزية للمستخدم الخاضع للقياس بأربع مرات لمحاكاة هاتف بطيء، بينما عرض مستخدم ثانٍ اللوحة على وحدة معالجة مركزية عادية. وخضع كل تطبيق لثلاث جولات تضمنت 20 عملية نقل بالسحب باستخدام الماوس.

أثناء التحميل البارد على الهاتف البطيء، نقلت اللوحة المخصصة 58 كيلوبايت من البيانات وعرضت اللوحة على الشاشة خلال 0.6 ثانية. ونقل تطبيق PLANKA نحو 2.6 ميجابايت واستغرق 15.4 ثانية لعرض لوحته. ويُنزّل PLANKA تطبيقه بالكامل قبل طلب بيانات اللوحة، بينما يُرسل الخادم المخصص اللوحة بتنسيق HTML في الاستجابة الأولية.

وفي اختبارات Lighthouse التي تحاكي شبكة هاتف محمول بطيئة، حققت اللوحة المخصصة درجة أداء بلغت 98، مع ظهور أول رسم للمحتوى خلال 1.4 ثانية و 160 مللي ثانية من إجمالي وقت الحظر. وسجل PLANKA نحو 33 درجة على الهاتف المحمول، مع ظهور أول رسم للمحتوى خلال 14.0 ثانية و 990 مللي ثانية من إجمالي وقت الحظر. وعلى أجهزة سطح المكتب، سجلت اللوحة المخصصة 100 درجة، بينما سجل PLANKA نحو 69 درجة.

عند سحب بطاقة قائمة واحدة إلى اليمين، أظهرت اللوحة المخصصة البطاقة في قائمتها الجديدة بعد 252 مللي ثانية، مع وصول تأكيد الخادم عند 253 مللي ثانية. وعرض PLANKA البطاقة في القائمة الجديدة بعد 481 مللي ثانية، في نهاية حركة الإفلات، وتلقى تأكيد الخادم بعد 712 مللي ثانية. ورأى مستخدم ثانٍ عملية النقل بعد 199 مللي ثانية على اللوحة المخصصة، مقارنة بنحو 656 مللي ثانية على PLANKA.

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

بعد الجلسة، سجلت اللوحة المخصصة وقت استجابة للتفاعل التالي (INP) بلغ 64 مللي ثانية، واستهلكت 4.4 ميجابايت من ذاكرة JavaScript، وتضمنت 1,843 عنصراً في نموذج كائن المستند (DOM). وسجل PLANKA وقت استجابة بلغ 256 مللي ثانية، واستهلك 45.0 ميجابايت من ذاكرة JavaScript، وتضمن 3,295 عنصراً. واستغرق فتح البطاقة 258 مللي ثانية على اللوحة المخصصة و 318 مللي ثانية على PLANKA.

حاكى اختبار التحميل 200 شخص ينقلون أربع بطاقات في الثانية لكل منهم، مما ولّد 790 عملية نقل في الثانية. واستخدم الخادم المخصص 4.9 نواة من وحدة المعالجة المركزية و 1.2 جيجابايت من الذاكرة، مع بلوغ الشريحة المئوية الخامسة والتسعين للطلبات المُجاب عليها 12 مللي ثانية. وذهب معظم وقت وحدة المعالجة المركزية لضغط إطارات HTML باستخدام Brotli لكل تدفق من التدفقات المئتين.

وبدون استخدام HTTP أو التدفقات، يعالج كاتب اللوحة المخصصة حوالي 13,800 عملية نقل في الثانية عندما ينقل 200 شخص البطاقات في وقت واحد. وتعمل قاعدة SQLite مع إعداد synchronous=FULL، مما يعني أن كل عملية حفظ تنتظر من 3 إلى 5 مللي ثانية للقرص على جهاز اختبار Linux.

في وضع السكون، تعمل اللوحة المخصصة كملف تنفيذي واحد بحجم 13.5 ميجابايت يستهلك 28 ميجابايت من الذاكرة، ويشغل ملف SQLite نحو 143 كيلوبايت. ويُشغّل PLANKA نحو 18 عملية عبر حاويتين يبلغ إجمالي حجمهما 673 ميجابايت، ويستهلك 200 ميجابايت من الذاكرة، وتشغل قاعدة بيانات PostgreSQL الخاصة به 10.3 ميجابايت.

لجعل اللوحة المكونة من 200 بطاقة سريعة على الهاتف، تطبق اللوحة المخصصة ثلاثة تحسينات رئيسية. إذ تحمل الإطارات القوائم التي تغيرت فقط، بينما تُرسل القوائم غير المتغيرة كعناصر نائبة فارغة تتخطاها Datastar باستخدام data-ignore-morph. وتُعدّل الإطارات القوائم داخل مكون اللوحة بدلاً من عنصر المكون نفسه، مما يقلل وقت الإطار من 100 مللي ثانية إلى 55 مللي ثانية. بالإضافة إلى ذلك، تستخدم القوائم غير الظاهرة على الشاشة خاصية content-visibility: auto لمنع المتصفح من رسمها.

شغّل الاختبار كلا التطبيقين على نفس الجهاز مع المتصفح، مما يعني أن أياً منهما لم يواجه زمن انتقال حقيقي لمركز البيانات. وركزت المقارنة فقط على الميزات المشتركة، وتساهم قدرات PLANKA الإضافية في زيادة حجمه. واستخدم الاختبار إصدار PLANKA Community 2.2.1، بينما يتضمن الإصدار المدفوع PLANKA Pro 2.5.0 تحسينات غير مختبرة للوحات الكبيرة. وقِيست جميع عمليات النقل باستخدام الماوس، وقيّم اختبار التحميل اللوحة المخصصة فقط.

تتوفر اللوحة المخصصة للاختبار على موقع kanban.zweiundeins.gmbh، مع إعادة تعيين اللوحات كل ليلة. وتتوفر الشيفرة البرمجية المصدرية ونصوص اختبار الأداء والبيانات الأولية على GitHub، حيث يمكن للمطورين تشغيل اللوحة محلياً باستخدام أمر go tool task dev.

بالنسبة للفرق التي تحتاج إلى وصول فوري إلى المرفقات وقوائم المهام والحقول المخصصة والإشعارات، يوفر PLANKA هذه الميزات جاهزة للاستخدام. ومع ذلك، تُظهر النتائج أن البرامج التفاعلية التي تدعم السحب والإفلات والتعاون المباشر وحل النزاعات يمكن بناؤها بفعالية باستخدام HTML المعتمد على الخادم. ويقدم هذا النهج حالات معلقة دقيقة، ويُحمّل في أقل من ثانية على هاتف بطيء، ويحافظ على استجابته، ويعمل كملف تنفيذي واحد مع ملف بيانات واحد.