لماذا يبدو تطبيقك المبني بالذكاء الاصطناعي بطيئاً (وماذا تفعل حياله)

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

إن كنت مؤسّساً غير تقني يُطلق بـمنصّة لبناء التطبيقات بالذكاء الاصطناعي، فهذه من أكثر لحظات “لا أعرف ما الخطأ” شيوعاً. والخبر الجيّد أن 80% من التطبيقات البطيئة المبنية بالذكاء الاصطناعي بطيئة للأسباب القليلة نفسها. لا أحد منها يتطلّب أن تتعلّم كيف تعمل قواعد البيانات. وكلّها لها حلول تستطيع أن تطلب من منصّة البناء تنفيذها بالإنجليزية البسيطة.

هذا المقال هو ورقة الغشّ.

لماذا تكون “البطء” عادةً أربعة أشياء

حين يقول المستخدمون إن تطبيقاً يبدو بطيئاً، فهم لا يعنون أبداً تقريباً “الخادم ضعيف”. بل يعنون واحداً من أربعة أشياء:

1. الرسم الأول بطيء — ينقرون على رابط ويحدّقون في شاشة فارغة لثانيتين قبل أن يظهر أي شيء.
2. قائمة طويلة متثاقلة — التمرير أو التصفية أو تحميل “كل مشاريعي” يستغرق أطول من التمرير في Instagram.
3. إجراء يستغرق وقتاً طويلاً دون أن يخبرهم بما يحدث — ينقرون على “حفظ” أو “إرسال” ولا يستجيب شيء بشكل مرئي.
4. قاعدة البيانات يُطرح عليها أسئلة كثيرة جداً — الصفحات التي تعرض بيانات من أماكن متعدّدة تجلب كل جزء على حدة وتكدّس أوقات الانتظار.

هذا كل شيء. كل تطبيق بطيء مبني بالذكاء الاصطناعي نظرت إليه تقريباً بطيء لأحد تلك الأسباب الأربعة. إليك كيف ترصد كل واحد وماذا تطلب من منصّة البناء أن تفعل حياله.

سبب البطء رقم 1: الرسم الأول

كيف يبدو: تنقر على رابط إلى تطبيقك، وينتهي شريط الرابط من التحميل، لكن الصفحة بيضاء لثانية أو ثانيتين قبل أن يظهر أي شيء.

ما يسبّبه عادةً: التطبيق يُحمِّل كل قطعة من JavaScript قد يحتاجها قبل أن يعرض لك أي شيء. منصّات بناء التطبيقات بالذكاء الاصطناعي تميل إلى التجميع بسخاء — أن تُدرج شيئاً أفضل من أن تفوّته — وتلك الحزمة تكبر كلّما أضفت ميزات أكثر.

ماذا تطلب من منصّة البناء: “تحميل الصفحة الأول يبدو بطيئاً. هل يمكنك تقسيم حزم JavaScript حسب المسار حتى لا تضطرّ الصفحة الرئيسية إلى تنزيل قسم المسؤول بأكمله؟” أو، بشكل أبسط: “أضِف التحميل الكسول للمسارات التي ليست الصفحة الرئيسية.” معظم الأطر الحديثة تدعم هذا بسطر أو سطرين من الإعدادات. الذكاء الاصطناعي يعرف كيف — كل ما عليك هو أن تطلب.

وبينما أنت بهذا الصدد: “هل توجد أي صور كبيرة على صفحة الهبوط يمكننا تحسينها؟” صورة بطل بحجم 4 ميغابايت ستُسقط السرعة المُدرَكة أكثر من أي مشكلة برمجية.

سبب البطء رقم 2: القائمة الطويلة

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

ما يسبّبه عادةً: التطبيق يعرض كل عنصر على الصفحة دفعة واحدة، حتى العناصر التي لا تستطيع رؤيتها. مع عشرة عناصر هذا جيّد. ومع خمسمئة، يختنق المتصفّح.

ماذا تطلب من منصّة البناء: “قائمة المشاريع بطيئة حين توجد عناصر كثيرة. هل يمكننا إضافة ترقيم صفحات، أو افتراض القائمة بحيث لا تُعرَض إلّا الصفوف المرئية؟” ترقيم الصفحات (“اعرض 20 لكل صفحة، مع أزرار للتالي/السابق”) هو الحلّ الأسهل. أما الافتراض (“اعرض فقط ما هو على الشاشة بينما يمرّر المستخدم”) فيبدو أكثر سلاسة لكنه أكثر عملاً قليلاً. كلاهما جيّد.

إن كانت القائمة فيها أيضاً بحث أو تصفية: “هل يمكن أن تحدث تصفية البحث على الخادم بدلاً من المتصفّح؟” التصفية من جانب الخادم تعني أن المتصفّح لا يحمل سوى الصفوف المطابقة، لا مجموعة البيانات كلّها.

سبب البطء رقم 3: الانتظار الصامت

كيف يبدو: تنقر على “حفظ” أو “إرسال” أو “توليد”. لا يحدث شيء بشكل مرئي. وبعد ثانيتين، تتحدّث الشاشة وتدرك أنه كان يعمل طوال الوقت.

ما يسبّبه عادةً: التطبيق يقوم بعمل حقيقي — حفظ في قاعدة بيانات، أو استدعاء واجهة برمجية — لكن منصّة البناء لم تضِف حالة تحميل. فمن وجهة نظرك، لم تفعل النقرة شيئاً.

هذه ليست مشكلة أداء فعلية. إنها مشكلة أداء مُدرَكة، وهذه غالباً ما تكون أكثر إيلاماً من الحقيقية. إجراء بـ 200 جزء من الثانية بلا تغذية راجعة يبدو أبطأ من إجراء بثانيتين مع مؤشّر دوران، لأن دماغ المستخدم في الظلام.

ماذا تطلب من منصّة البناء: “أضِف حالة تحميل لكل زرّ يُطلِق إجراءً. اعرض مؤشّر دوران أو نصّ ‘جارٍ الحفظ…’ أثناء عمله، وعطّل الزرّ حتى لا ينقر المستخدمون نقراً مزدوجاً.” هذا أعلى حلّ أداء عائداً في أي تطبيق ويكاد لا يكلّف شيئاً.

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

سبب البطء رقم 4: قاعدة البيانات الثرثارة

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

ما يسبّبه عادةً: الصفحة تُحمِّل المشاريع باستعلام واحد، ثم تُحمِّل عدد المهام لكل مشروع باستعلام منفصل. عشرة مشاريع؟ أحد عشر استعلاماً. مئة مشروع؟ مئة وواحد. يُسمّى هذا “استعلام N+1”، وهو أكثر أخطاء أداء قواعد البيانات شيوعاً في التطبيقات المبنية بالذكاء الاصطناعي لأن الذكاء الاصطناعي يحسّن لأجل شيفرة تُقرَأ بوضوح، لا شيفرة تعمل بكفاءة.

ماذا تطلب من منصّة البناء: “هذه الصفحة تُجري استعلاماً لكل عنصر. هل يمكننا جلب كل البيانات المرتبطة في استعلام واحد — ربط أو تجميع؟” لست بحاجة إلى معرفة معنى أي من الكلمتين. الذكاء الاصطناعي يعرف. إظهار الصفحة البطيئة له وقول “أظنّ أن لديها مشكلة N+1” يكفي عادةً.

تستطيع رصد مشاكل N+1 دون أي أدوات: افتح الصفحة، احسب كم تستغرق، ثم أضِف عشرة أضعاف العناصر إلى القائمة الكامنة. إن صارت الصفحة الآن أبطأ بعشرة أضعاف، فلديك مشكلة N+1. وإن كانت أبطأ بقدر ضئيل فقط، فلا.

كلمة عن التحسين المبكّر

فخّ يقع فيه الصنّاع الجدد: محاولة جعل كل صفحة سريعة قبل أن يستخدم أحدٌ التطبيق. لا تفعل.

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

فابنِه بشكل طبيعي أولاً. أطلِقه. راقب كيف يُستخدم. وحين يبدو شيء ما بطيئاً لشخص حقيقي — بما في ذلك أنت — طابِق العَرَض مع واحدة من الفئات الأربع أعلاه واطلب ذلك الحلّ المحدّد. ستحصل على تطبيق أسرع دون أن تقضي أسبوعاً على بنية تحتية لن يلاحظها مستخدموك أبداً.

كيف تتحدّث مع منصّة البناء عن السرعة

نمط ينجح: صِف العَرَض، لا الحلّ. الذكاء الاصطناعي أفضل بكثير مما تتوقّع في اختيار الحلّ الصحيح، طالما يعرف ما الخطأ فعلاً.

طلبات جيّدة لنسخها:

• “حين أفتح صفحة الإعدادات، توجد فترة تأخير ثانية واحدة قبل أن يظهر أي شيء. هل يمكننا اكتشاف ما الذي يحجب الرسم الأول؟”
• “لوحة التحكّم تستغرق وقتاً أطول للتحميل من الصفحة الرئيسية رغم أنها تعرض بيانات أقلّ. هل يمكننا النظر في كيفية جلبها لبياناتها؟”
• “حين أنقر على ‘حفظ التغييرات’ في صفحة الملف الشخصي، لا يحدث شيء لثانيتين. أضِف حالة تحميل وتأكّد من عدم إمكانية النقر المزدوج على الزرّ.”
• “اختبر هذه القائمة بـ 500 عنصر وهمي وأخبرني أين أماكن التباطؤ.”

الأخير مُقلَّل من قدره. أن تطلب من الذكاء الاصطناعي توليد بيانات اختبار وتجربة الصفحة بنفسه هو من أنفع ما يمكنك فعله. غالباً ما سيجد الأماكن البطيئة قبل مستخدميك — ويقترح الحلّ في الردّ نفسه.

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