تحسين FCP/LCP عن طريق تخزين عمليات البحث عن وحدات raw-view مؤقتًا

مطور
1

أحاول تحسين First Contentful Paint (FCP) و Largest Contentful Paint (LCP) بهذين الطلبين لسحب الميزات (PRs):

أنا مهتم حقًا بالتأثير الفعلي لهذه التغييرات - لذا يرجى المحاولة وتقديم بعض الملاحظات.

وبالطبع، أي مساعدة في الاختبار وإعادة الهيكلة وتغطية الاختبارات هي موضع ترحيب كبير.

11 إعجابًا
2

الأول يبدو تحسينًا سهلاً أعتقد أنه منطقي، لقد أمضى @david و @eviltrout وقتًا في تحسين هذه المنطقة لذا سأكون فضوليًا جدًا لمعرفة ما يفكرون فيه.

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

5 إعجابات
4

مرحباً @rrit - شكراً على طلبات السحب (PRs). يبدو أن الطلب الأول تحسين جيد. هل تمكنت من قياس تأثير الأداء؟ كم من الوقت تم توفيره؟

كما قال @sam ، فإن قابلية الصيانة للطلب الثاني تثير القلق بعض الشيء. يبدو أنه تم نسخه ولصقه من كود Ember المصدري؟ هل قمت بتغيير شيء ما لتحسين الأداء؟

4 إعجابات
5

lookupView-patch

تم التنفيذ الآن عبر Map بدلاً من Array.

الوقت المستغرق في بدء تشغيل التطبيق في lookupView - لمثيل التطوير:

  • بدون تصحيح: 124 مللي ثانية
    Firefox Profiler (مكدس الاستدعاءات مصفى إلى lookupView)

  • مع التصحيح: 9 مللي ثانية
    Firefox Profiler (مكدس الاستدعاءات مصفى إلى lookupView)

الوقت الموفر: ~115 مللي ثانية

هذا يقلل الوقت المستغرق داخل appendOutletView من 1.083 مللي ثانية إلى 946 مللي ثانية - لمثيل التطوير.

تصحيح على مساعدي handlebars الخام

نعم، إنها في الواقع نسخة ولصق مع تغيير واحد: استخدم فحصًا غير مكلف لـ isPath.

      // يستبدل @ember/-internals/utils isPath
      // @see: https://github.com/emberjs/ember.js/blob/3537670c14883346e11e841fcb71333384fcbc87/packages/%40ember/-internals/metal/lib/path_cache.ts#L5-L7
      // @see: https://github.com/emberjs/ember.js/blob/255a0dd3c7de1187f4a2f61a97cf78bfff8f66a8/packages/%40ember/-internals/glimmer/lib/utils/bindings.ts#L70
      let isPath = context.indexOf('.') > -1;

على سبيل المثال، يؤدي renderTopicListItem في النهاية إلى العديد من استدعاءات _getPath (لتوفير 50-100 مللي ثانية أخرى):
Firefox Profiler (مكدس الاستدعاءات مصفى إلى _getPath داخل renderTopicListItem)

ربما تكون الاستدعاءات المكلفة لـ _getPath شيئًا يجب تحسينه في Ember.js وليس في Discourse.

وتفقد Firefox Profiler للحصول على رؤى حول تنفيذ JavaScript:

4 إعجابات
6

شكراً على التصحيحات. يبدو أن التصحيح الثاني هش بعض الشيء.

هل تعمل اختبارات الأداء الخاصة بك في وضع التطوير أم وضع الإنتاج؟ لدى Ember ملف تعريف مختلف تمامًا في كليهما.

إعجابَين (2)
7

@david وجد طريقة ممتازة لحل هذه المشكلة - انظر تعليقه على github.

الوقت المستغرق لاستدعاءات renderTopicListItem في صفحة الويب ‘latest’ ينخفض من 348 مللي ثانية إلى 201 مللي ثانية في بناء Ember ‘production’.

المقاييس السابقة كانت لا تزال تعمل في وضع التطوير.

كيف يمكنني تشغيل المقاييس في وضع إنتاج Ember.js؟

# بدء تشغيل ember في وضع الإنتاج
d/ember-cli server --environment="production"
إعجابَين (2)
8

للأسف، لم أتمكن من تكرار هذه الزيادة الكبيرة في السرعة. على Firefox و Chrome (macOS) لا أرى أي تحسن قابل للقياس. يقضي Chrome حوالي 23 مللي ثانية في renderTopicListItem. Firefox 30 مللي ثانية. على جهاز Android قديم (Pixel 3)، أرى حوالي 108 مللي ثانية. الأرقام لا تتغير قبل/بعد التغيير.

بالمناسبة، قمت بقياس هذه الأرقام باستخدام واجهة برمجة تطبيقات الأداء. أضفت performance.mark("rtli-start") في بداية renderTopicListItem، ثم performance.measure("rtli", "rtli-start") في النهاية.

ثم أقوم بإعادة تحميل المتصفح مع إغلاق أدوات المطور وتعطيل إضافات المتصفح (يمكن لأدوات المطور وإضافات المتصفح أن تؤثر بشكل كبير على أداء العرض). ثم بعد اكتمال التحميل، أفتح أدوات المطور وأقوم بتشغيل هذا لجمع القياسات:

performance.getEntriesByName("rtli").reduce((v, m) => v + m.duration, 0);

سنقوم بالتأكيد بدمج هذا التغيير - إنه بالتأكيد تطبيق أفضل. لكنني لست متأكدًا مما إذا كان سيعطينا فرقًا مرئيًا في أداء العرض :thinking:

7 إعجابات
9

لا يزال بإمكاني استنساخ فوائد الأداء باستخدام واجهة برمجة تطبيقات الأداء في وضع التصفح الخاص في Firefox (Linux).

اختبار http://localhost:4200/latest
الوقت المستغرق في renderTopicListItem انخفض إلى حوالي 190 مللي ثانية من حوالي 290 مللي ثانية.

تحتوي نسخة Discourse التجريبية الخاصة بي على العديد من المواضيع مع العديد من الإجابات والعديد من المؤلفين المختلفين - تم سحب البيانات من نسخة إنتاجية. ينتج عن هذا الكثير من العناصر التي يجب عرضها.
ربما هذا هو الاختلاف في معايير الأداء لدينا؟

العرض المسبق للمحتوى أسفل الطية

يقوم Discourse بعرض مسبق لـ 30 موضوعًا في صفحة “latest”. ثم يتم عرض المحتوى لأول مرة (FCP). يوجد أسفل الطية حوالي 12 موضوعًا مرئيًا فقط.

نفس الشيء بالنسبة لصفحة الموضوع: تم عرض 20 مشاركة مسبقًا، ولكن بحد أقصى 6 مشاركات من سطر واحد مرئية أسفل الطية.

قد تكون هذه نقطة أخرى للتحسين لـ FCP.

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

هل تمانع في مشاركة إصدار فايرفوكس ونظام التشغيل؟ الرقم 290 مللي ثانية أبطأ بحوالي 3 مرات من جهاز أندرويد من عام 2018، وهو أمر مفاجئ بعض الشيء.

قد يفسر هذا بعض الاختلاف، نعم. في حالتي، قمت بتشغيلها باستخدام بيانات مباشرة من Meta:

bin/ember-cli --environment production --proxy https://meta.discourse.org

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

3 إعجابات
11

بروكسي إلى meta.discourse.org

للأسف، تشغيل ember مع بروكسي يفشل بالنسبة لي:

d/ember-cli --environment production --proxy https://meta.discourse.org

http://localhost:4200/

خطأ في بناء Discourse

خطأ [ERR_TLS_CERT_ALTNAME_INVALID]: اسم المضيف/IP لا يتطابق مع الأسماء البديلة للشهادة:
المضيف: localhost. ليس في الأسماء البديلة للشهادة: DNS:*.cdck-prod-meta.discourse.cloud

http://127.0.0.1:4200/

خطأ في بناء Discourse

خطأ [ERR_TLS_CERT_ALTNAME_INVALID]: اسم المضيف/IP لا يتطابق مع الأسماء البديلة للشهادة:
المضيف: meta.discourse.org. ليس في الأسماء البديلة للشهادة: DNS:*.cdck-prod-meta.discourse.cloud

النظام المستخدم في المقاييس

مستخرج من Firefox about:support

الاسم Firefox
الإصدار 95.0.2
معرف البناء 20211219102529
معرف التوزيع canonical-002
وكيل المستخدم Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0
نظام التشغيل Linux 5.10.0-0.bpo.9-amd64 #1 SMP Debian 5.10.70-1~bpo10+1 (2021-10-10)
سمة نظام التشغيل Adwaita-dark / Adwaita
ملف برنامج التطبيق /snap/firefox/777/usr/lib/firefox/firefox
الاسم Firefox Developer Edition
الإصدار 96.0b10
معرف البناء 20211228195952
دليل التحديث /opt/firefox-dev-autoinstall
قناة التحديث aurora
وكيل المستخدم Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0
نظام التشغيل Linux 5.10.0-0.bpo.9-amd64 #1 SMP Debian 5.10.70-1~bpo10+1 (2021-10-10)
سمة نظام التشغيل Adwaita-dark / Adwaita
ملف برنامج التطبيق /opt/firefox-dev-autoinstall/firefox-bin

مستخرج من Chromium chrome://system/

إصدار كروم 90.0.4430.212 مبني على Debian 10.9، يعمل على Debian 10.11
إصدار نظام التشغيل Linux: 5.10.0-0.bpo.9-amd64

إصدار نظام التشغيل:

# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
إعجابَين (2)
12

تم دمج طلب السحب (PR) الخاص بإعادة الهيكلة الآن:

شكرًا لطرح هذا الأمر @rrit - إنه تحسين رائع!

5 إعجابات
13

تم إغلاق هذا الموضوع تلقائيًا بعد 9 ساعات. لم يعد يُسمح بالردود الجديدة.