أداء Gsap

# أداء GSAP

## متى تستخدم هذه المهارة

طبق هذه المهارة عند تحسين رسوم GSAP المتحركة للحصول على 60 إطارا في الثانية بسلاسة، أو تقليل تكلفة التخطيط/الرسم، أو عندما يسأل المستخدم عن الأداء، أو التقطيع (jank)، أو أفضل الممارسات للرسوم المتحركة السريعة.

**المهارات ذات الصلة:** بناء رسوم متحركة باستخدام **gsap-core** (transforms, autoAlpha) و **gsap-timeline**؛ لأداء ScrollTrigger، انظر **gsap-scrolltrigger**.

## تفضيل Transform و Opacity

تحريك **transform** (`x`, `y`, `scaleX`, `scaleY`, `rotation`, `rotationX`, `rotationY`, `skewX`, `skewY`) و **opacity** يحافظ على العمل على المركب (compositor) ويتجنب التخطيط ومعظم عمليات الرسم. تجنب تحريك الخصائص التي تتطلب تخطيطا مكثفا عندما يمكن ل transform تحقيق نفس التأثير.

- ✅ يفضل: **x**, **y**, **scale**, **rotation**, **opacity**. - ❌ تجنب قدر الإمكان: **width**, **height**, **top**, **left**, **margin**, **padding** (فهي تشغل التخطيط ويمكن أن تسبب التقطيع).

تستخدم خاصيتا **x** و **y** في GSAP التحويلات (translate) افتراضيا؛ استخدمهما بدلا من **left**/**top** للحركة.

## will-change

استخدم **will-change** في CSS على العناصر التي ستتحرك. فهو يوجه المتصفح لترقية الطبقة.

```css will-change: transform; ```

## تجميع عمليات القراءة والكتابة

يقوم GSAP بتجميع التحديثات داخليا. عند خلط GSAP مع عمليات قراءة/كتابة DOM المباشرة أو التعليمات البرمجية التي تعتمد على التخطيط، تجنب تداخل عمليات القراءة والكتابة بطريقة تسبب تكرار إجهاد التخطيط (layout thrashing). يفضل إجراء جميع عمليات القراءة أولا، ثم جميع عمليات الكتابة (أو دع GSAP يتعامل مع عمليات الكتابة دفعة واحدة).

## العديد من العناصر (Stagger, Lists)

- استخدم **stagger** بدلا من العديد من ال tweens المنفصلة ذات التأخيرات اليدوية عندما تكون الرسوم المتحركة متماثلة؛ فهي أكثر كفاءة. - للقوائم الطويلة، فكر في **virtualization** أو تحريك العناصر المرئية فقط؛ تجنب إنشاء المئات من ال tweens المتزامنة إذا كانت تسبب التقطيع. - أعد استخدام ال timelines حيثما أمكن؛ تجنب إنشاء timelines جديدة في كل إطار.

## الخصائص التي يتم تحديثها بشكل متكرر (مثل متتبعي الماوس)

فضل **gsap.quickTo()** للخصائص التي يتم تحديثها غالبا (مثل x/y لمتتبع الماوس). فهو يعيد استخدام tween واحد بدلا من إنشاء tweens جديدة في كل تحديث.

```javascript let xTo = gsap.quickTo("#id", "x", { duration: 0.4, ease: "power3" }), yTo = gsap.quickTo("#id", "y", { duration: 0.4, ease: "power3" });

document.querySelector("#container").addEventListener("mousemove", (e) => { xTo(e.pageX); yTo(e.pageY); }); ```

## ScrollTrigger والأداء

- **pin: true** يرفع العنصر المثبت؛ قم بتثبيت ما هو ضروري فقط. - **scrub** بقيمة صغيرة (مثل `scrub: 1`) يمكن أن يقلل العمل أثناء التمرير؛ اختبر على الأجهزة منخفضة المواصفات. - استدع **ScrollTrigger.refresh()** فقط عندما يتغير التخطيط فعليا (مثل بعد تحميل المحتوى)، وليس في كل تغيير حجم؛ استخدم debounce عندما يكون ذلك ممكنا.

## تقليل العمل المتزامن

- أوقف مؤقتا أو اقتل الرسوم المتحركة خارج الشاشة أو غير النشطة عندما لا تكون مرئية (مثل عندما ينتقل المستخدم بعيدا). - تجنب تحريك أعداد هائلة من الخصائص على العديد من العناصر في وقت واحد؛ قم بالتبسيط أو التسلسل إذا لزم الأمر.

## أفضل الممارسات

- ✅ حرك **transform** و **opacity**؛ استخدم **will-change** في CSS فقط على العناصر التي تتحرك. - ✅ استخدم **stagger** بدلا من العديد من ال tweens المنفصلة ذات التأخيرات اليدوية عندما تكون الرسوم المتحركة متماثلة. - ✅ استخدم **gsap.quickTo()** للخصائص التي يتم تحديثها بشكل متكرر (مثل متتبعي الماوس). - ✅ قم بتنظيف أو قتل الرسوم المتحركة خارج الشاشة؛ استدع **ScrollTrigger.refresh()** عندما يتغير التخطيط، مع استخدام debounce عندما يكون ذلك ممكنا.

## لا تفعل

- ❌ تحريك **width**/ **height**/ **top**/ **left** للحركة عندما يمكن ل **x**/ **y**/ **scale** تحقيق نفس المظهر. - ❌ تعيين **will-change** أو **force3D** على كل عنصر "فقط في حالة"؛ استخدمها للعناصر التي تتحرك بالفعل. - ❌ إنشاء المئات من ال tweens أو ScrollTriggers المتداخلة دون اختبارها على الأجهزة منخفضة المواصفات. - ❌ تجاهل التنظيف؛ ال tweens و ScrollTriggers الضالة تستمر في العمل ويمكن أن تضر بالأداء والصحة.