في 2025، تغيرت قواعد اللعبة لأداء الويب: مقاييس جديدة، خوارزميات بحث متطورة، وتوقعات المستخدمين التي لا ترحم. لكن هل مازالت Core Web Vitals هي الملك؟ وكيف تتعامل مع الفجوة بين الأرقام الحقيقية وتجربة المستخدم الفعلية؟ تحليل عميق من مهندس عاش الحرب على الأداء.
في صباح يوم عادي من عام 2024، تلقيت رسالة من فريق التسويق في شركة ناشئة سعودية: "الصفحة الرئيسية حصلت على 95 في Lighthouse، لكن المستخدمين يشتكون من البطء!" المشكلة لم تكن في الأرقام نفسها، بل في الفهم الخاطئ لها. Core Web Vitals لم تكن يوماً مجرد أرقام في لوحة تحكم، بل هي مؤشرات على تجربة حقيقية يعيشها المستخدمون في اللحظة التي يضغطون فيها على رابط موقعك. في 2025، أصبحت هذه المؤشرات أكثر تعقيداً، حيث أضافت جوجل معايير جديدة مثل Interaction to Next Paint (INP) لتحل محل First Input Delay (FID)، بينما مازالت الشركات تكافح لفهم لماذا لا تتطابق أرقام الأداء مع تجربة المستخدم الفعلية.
الحقيقة التي لا يريد الكثيرون الاعتراف بها هي أن Core Web Vitals في 2025 ليست مجرد ثلاثة مقاييس، بل هي نظام متكامل من القياسات التي تتفاعل مع بعضها البعض بطرق غير متوقعة. Largest Contentful Paint (LCP) مازال ملك السرعة البصرية، لكن تحليله أصبح أكثر دقة مع الأخذ في الاعتبار عوامل مثل الـ Cumulative Layout Shift (CLS) الذي يحدث أثناء تحميل الصفحة. المشكلة الأكبر هي أن العديد من المطورين مازالوا يعالجون هذه المقاييس بشكل منفصل، وكأن تحسين LCP لا يؤثر على CLS، أو كأن تقليل حجم الصور لا يؤثر على INP. هذا التفكير المنفصل هو ما يؤدي إلى تجارب مستخدم متذبذبة، حتى لو كانت الأرقام في Lighthouse تبدو مثالية.
Largest Contentful Paint مازال المقياس الأكثر أهمية في Core Web Vitals لأنه يمثل اللحظة التي يشعر فيها المستخدم بأن الصفحة "جاهزة" للاستخدام. في 2025، تغير تعريف LCP ليشمل عناصر ديناميكية مثل الصور التي تُضاف بعد التحميل الأولي، لكن جوهر المقياس مازال كما هو: الوقت الذي يستغرقه أكبر عنصر مرئي ليظهر على الشاشة. المشكلة التي أراها في معظم المشاريع هي أن المطورين يركزون على تحسين وقت الاستجابة من السيرفر (TTFB) وينسون أن 70% من وقت LCP غالباً ما يكون مرتبطاً بتحميل الموارد مثل الصور والخطوط. مثلاً، في مشروع عملت عليه لشركة تجارة إلكترونية، كان LCP يصل إلى 4.2 ثانية رغم أن TTFB كان أقل من 200 مللي ثانية. بعد تحليل عميق، اكتشفنا أن المشكلة كانت في الصور التي تُحمّل بحجم 3000x2000 بكسل وتُعرض بحجم 300x200 بكسل. مجرد إضافة سمة srcset مع أحجام مختلفة خفضت LCP إلى 1.8 ثانية دون أي تغيير في البنية الخلفية.
لكن التحدي الحقيقي مع LCP في 2025 ليس فقط في تحميل الموارد، بل في كيفية تعامل المتصفحات الحديثة مع الأولوية. جوجل كروم مثلاً يستخدم الآن خوارزمية تسمى "Priority Hints" لتحديد أي الموارد يجب تحميلها أولاً. المشكلة هي أن العديد من المطورين لا يستخدمون هذه الميزة بشكل صحيح، مما يؤدي إلى تحميل الموارد غير الضرورية في البداية. مثلاً، في تطبيق ويب تقدمي (PWA) عملت عليه، كان لدينا صورة خلفية كبيرة تُحمّل في بداية الصفحة رغم أنها غير مرئية إلا بعد التمرير. باستخدام <link rel="preload" as="image" importance="low">، تمكنا من تأجيل تحميل هذه الصورة دون التأثير على تجربة المستخدم، مما خفض LCP بمقدار 1.3 ثانية. هذا النوع من التحسينات الدقيقة هو ما يميز المواقع السريعة عن تلك التي تعتمد فقط على ضغط الصور وتقليل حجم الجافاسكريبت.
<!DOCTYPE html>
<html>
<head>
<!-- Preload critical resources with priority -->
<link rel="preload" href="hero-image.avif" as="image" importance="high" fetchpriority="high">
<link rel="preload" href="main-font.woff2" as="font" type="font/woff2" crossorigin>
<!-- Defer non-critical resources -->
<link rel="preload" href="background-image.jpg" as="image" importance="low">
</head>
<body>
<img src="hero-image.avif" alt="Hero Image" width="1200" height="600"
loading="eager" fetchpriority="high">
<!-- Lazy load offscreen images -->
<img src="placeholder.jpg" data-src="product-image.jpg"
alt="Product" width="300" height="300" loading="lazy"
class="lazyload">
>
// Modern lazy loading with Intersection Observer
document.addEventListener('DOMContentLoaded', () => {
const lazyImages = document.querySelectorAll('.lazyload');
const imageObserver = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const img = entry.target;
img.src = img.dataset.src;
img.classList.remove('lazyload');
imageObserver.unobserve(img);
}
});
});
lazyImages.forEach(img => imageObserver.observe(img));
});
</script>
</body>
</html>في مارس 2024، أعلنت جوجل أن Interaction to Next Paint (INP) سيحل محل First Input Delay (FID) كمقياس رسمي في Core Web Vitals. هذا التغيير لم يكن مجرد استبدال مقياس بمقياس آخر، بل كان اعترافاً بأن FID كان مقياساً غير كافٍ لقياس تجربة المستخدم الحقيقية. FID كان يقيس فقط التأخير في الاستجابة لأول تفاعل، لكن في الواقع، المستخدمون يتفاعلون مع الصفحات عشرات المرات خلال جلسة واحدة. مثلاً، في تطبيق ويب للتعليم عن بعد، وجدنا أن FID كان أقل من 100 مللي ثانية، لكن المستخدمين كانوا يشتكون من "تجمد" الصفحة عند التمرير أو النقر على الأزرار. بعد تحليل عميق باستخدام أداة Chrome DevTools، اكتشفنا أن المشكلة كانت في الـ Event Loop الذي كان يُحجب بواسطة عمليات جافاسكريبت طويلة الأمد (Long Tasks). INP يقيس الوقت من بداية التفاعل إلى اللحظة التي يتم فيها تحديث الشاشة، مما يعطي صورة أكثر دقة عن تجربة المستخدم الحقيقية.
التحدي الأكبر مع INP هو أنه مقياس يعتمد على سلوك المستخدم الفعلي، مما يجعله صعب التحسين مقارنة بمقاييس مثل LCP. في مشروع لشركة سعودية تعمل في مجال الخدمات المالية، كان INP يصل إلى 450 مللي ثانية رغم أن FID كان أقل من 50 مللي ثانية. بعد تحليل باستخدام أداة WebPageTest، اكتشفنا أن المشكلة كانت في مكتبة جافاسكريبت خارجية تُستخدم لإدارة النماذج. هذه المكتبة كانت تُنشئ Event Listeners لكل حقل إدخال، مما يؤدي إلى تراكم العمليات في الـ Event Loop. الحل كان في استخدام تقنية تسمى "Event Delegation" بدلاً من إضافة مستمعين لكل عنصر على حدة. ببساطة، بدلاً من إضافة مستمع لكل زر أو حقل إدخال، أضفنا مستمعاً واحداً للعنصر الأب، مما قلل عدد العمليات في الـ Event Loop وخفض INP إلى 180 مللي ثانية. هذا النوع من التحسينات الدقيقة هو ما يتطلبه INP، وهو ما يجعله مقياساً أكثر تحدياً من FID.
// Bad: Adding event listeners to each element individually
const butt document.querySelectorAll('.action-button');
buttons.forEach(button => {
button.addEventListener('click', handleClick);
});
// Good: Using Event Delegation
const container = document.querySelector('.button-container');
container.addEventListener('click', (event) => {
if (event.target.classList.contains('action-button')) {
handleClick(event);
}
});
// Optimizing long tasks with setTimeout
function processLargeDataset(data) {
// Split the task into smaller chunks
const chunkSize = 100;
for (let i = 0; i < data.length; i += chunkSize) {
const chunk = data.slice(i, i + chunkSize);
setTimeout(() => {
// Process the chunk
chunk.forEach(item => processItem(item));
}, 0);
}
}
// Using requestIdleCallback for non-critical tasks
function updateNonCriticalUI() {
if ('requestIdleCallback' in window) {
requestIdleCallback(() => {
// Update UI elements that are not immediately visible
updateDashboard();
}, { timeout: 1000 });
} else {
// Fallback for browsers that don't support requestIdleCallback
setTimeout(updateDashboard, 100);
}
}Cumulative Layout Shift (CLS) هو المقياس الذي يُظهر مدى استقرار الصفحة أثناء تحميلها. في 2025، مازال هذا المقياس يمثل تحدياً كبيراً للمطورين لأنه يعتمد على عوامل كثيرة خارج نطاق التحكم المباشر. مثلاً، في موقع إخباري عملت عليه، كان CLS يصل إلى 0.35 رغم أننا استخدمنا أبعاد ثابتة لكل الصور والعناصر. بعد تحليل باستخدام أداة Layout Shift Debugger في كروم، اكتشفنا أن المشكلة كانت في الإعلانات التي تُضاف ديناميكياً بعد تحميل الصفحة. هذه الإعلانات كانت تُدفع العناصر الموجودة للأسفل، مما يسبب انزياحاً في التخطيط. الحل كان في تخصيص مساحة ثابتة لكل إعلان باستخدام CSS، مما يمنع حدوث انزياح حتى لو تم تحميل الإعلان بعد الصفحة الرئيسية.
المشكلة الأكبر مع CLS هي أنه مقياس تراكمي، مما يعني أن أي انزياح صغير في أي جزء من الصفحة يمكن أن يؤثر على النتيجة النهائية. في تطبيق ويب للتجارة الإلكترونية، كان لدينا مشكلة مع CLS بسبب تحميل الخطوط المخصصة. الخط الأساسي كان يُحمّل بعد بقية الصفحة، مما يسبب انزياحاً في النص بمقدار بضعة بكسلات. هذا الانزياح الصغير كان يكفي لرفع CLS إلى 0.25، وهو ما يعتبر "سيئاً" حسب معايير جوجل. الحل كان في استخدام خاصية font-display: optional في CSS، مما يسمح للمتصفح باستخدام الخط الاحتياطي إذا لم يتم تحميل الخط المخصص في الوقت المناسب. هذه التقنية لم تمنع الانزياح تماماً، لكنها قللت تأثيره بشكل كبير، مما خفض CLS إلى 0.08. الحقيقة هي أن CLS في 2025 مازال يعتمد كثيراً على تفاصيل صغيرة قد لا يلاحظها المطورون، لكن لها تأثير كبير على تجربة المستخدم.
/* Prevent layout shifts with explicit dimensions */
img, video, iframe {
width: 100%;
height: auto;
aspect-ratio: 16 / 9; /* Maintain aspect ratio */
object-fit: cover;
}
/* Reserve space for dynamic content */
.ad-container {
min-height: 250px; /* Reserve space for ads */
background-color: #f5f5f5;
}
/* Font loading strategy to prevent FOIT/FOUT */
@font-face {
font-family: 'CustomFont';
src: url('custom-font.woff2') format('woff2');
font-display: optional; /* Use fallback if font doesn't load quickly */
}
/* Prevent layout shifts from dynamically injected content */
.dynamic-content {
contain: layout; /* Isolate layout changes */
}في 2025، تغيرت أشياء كثيرة في عالم أداء الويب، لكن جوهر المشكلة مازال كما هو: كيف نجعل المستخدم يشعر بأن الصفحة سريعة، حتى لو كانت الأرقام تقول عكس ذلك؟ جوجل أضافت مقاييس جديدة مثل Time to First Byte (TTFB) كجزء من تقارير Chrome User Experience Report (CrUX)، لكنها مازالت تعتمد على Core Web Vitals كأساس لتصنيف الصفحات. التغيير الأكبر كان في كيفية تعامل المتصفحات مع الموارد. مثلاً، كروم الآن يستخدم تقنية تسمى "Back-Forward Cache" بشكل أكثر فعالية، مما يسمح للمستخدمين بالعودة إلى الصفحات السابقة دون إعادة تحميلها. هذا التغيير قلل الحاجة إلى تحسينات معقدة مثل Service Workers في بعض الحالات، لكنه زاد من أهمية إدارة حالة الصفحة بشكل صحيح.
التغيير الآخر الكبير كان في كيفية تعامل جوجل مع البيانات الحقيقية مقابل البيانات المختبرية. في الماضي، كان الكثير من المطورين يعتمدون على أدوات مثل Lighthouse التي تعطي نتائج في بيئة خاضعة للرقابة. في 2025، أصبحت بيانات CrUX هي المعيار الذهبي، مما يعني أن تحسين الأداء يجب أن يكون بناءً على بيانات حقيقية من المستخدمين، وليس فقط على سيناريوهات مثالية. مثلاً، في مشروع لشركة سعودية تعمل في مجال السياحة، وجدنا أن Lighthouse كان يعطي نتائج ممتازة، لكن بيانات CrUX أظهرت أن 30% من المستخدمين يواجهون مشاكل في الأداء بسبب شبكات بطيئة في بعض المناطق. هذا النوع من البيانات الحقيقية هو ما يجعل تحسين الأداء في 2025 أكثر تحدياً، لكنه أيضاً أكثر فعالية في تحسين تجربة المستخدم الفعلية.
رغم كل التحديثات والتغييرات، هناك أشياء أساسية مازالت كما هي في عالم أداء الويب. أولاً، جافاسكريبت مازال هو العدو الأول للأداء. في كل مشروع عملت عليه، سواء كان موقعاً بسيطاً أو تطبيقاً معقداً، كانت المشكلة الأساسية دائماً هي الجافاسكريبت الزائد. في 2025، مازال المطورون يضيفون مكتبات كاملة لمهام بسيطة، أو يستخدمون أطر عمل ثقيلة دون الحاجة إليها. مثلاً، في تطبيق ويب تقدمي عملت عليه، كان لدينا مكتبة React كاملة تُحمّل لمجرد عرض قائمة منسدلة بسيطة. استبدال هذه المكتبة بكود فانيلا جافاسكريبت قلل حجم الصفحة بمقدار 300 كيلوبايت، مما خفض LCP بمقدار 1.2 ثانية. الحقيقة هي أن الجافاسكريبت مازال هو العامل الأكبر في بطء الصفحات، وسيظل كذلك لفترة طويلة.
ثانياً، الصور مازالت تمثل تحدياً كبيراً. في 2025، لدينا صيغ جديدة مثل AVIF وWebP2، لكن المشكلة الأساسية مازالت كما هي: المطورون لا يستخدمون هذه الصيغ بشكل صحيح. مثلاً، في موقع إخباري عملت عليه، كان لدينا صور تُحمّل بحجم 2 ميغابايت وتُعرض بحجم 300x200 بكسل. مجرد تحويل هذه الصور إلى AVIF مع ضغط مناسب قلل حجمها إلى 50 كيلوبايت دون فقدان الجودة الملحوظ. المشكلة هي أن العديد من المطورين مازالوا يعتمدون على أدوات مثل Photoshop لحفظ الصور، بدلاً من استخدام أدوات متخصصة مثل Squoosh أو ImageOptim. في 2025، مازال تحسين الصور هو أسهل وأسرع طريقة لتحسين أداء الصفحة، لكنه أيضاً أكثر الطرق إهمالاً.
إذا كنت تريد تحسين أداء موقعك في 2025، لا تبدأ بالأدوات أو المكتبات. ابدأ ببيانات حقيقية من المستخدمين باستخدام CrUX أو أدوات مثل New Relic. اكتشف أين تكمن المشكلة الحقيقية: هل هي في تحميل الموارد؟ أم في استجابة الصفحة؟ أم في استقرار التخطيط؟ بعد ذلك، ركز على الحلول البسيطة قبل المعقدة. مثلاً، إذا كانت المشكلة في LCP، ابدأ بضغط الصور وتحسين تحميلها قبل أن تفكر في استخدام Service Workers أو تقنيات متقدمة أخرى. وإذا كانت المشكلة في INP، ابدأ بتحليل الـ Event Loop باستخدام Chrome DevTools قبل أن تفكر في إعادة كتابة الكود بالكامل. الحقيقة هي أن 80% من مشاكل الأداء يمكن حلها بحلول بسيطة، لكن المطورين غالباً ما يقفزون إلى الحلول المعقدة دون الحاجة إليها. في النهاية، أداء الويب ليس عن الأرقام في Lighthouse، بل عن تجربة المستخدم الحقيقية. إذا كان المستخدم يشعر بأن الصفحة سريعة، فأنت على الطريق الصحيح، حتى لو كانت الأرقام تقول عكس ذلك.
الأداء ليس ميزة، بل هو حق أساسي للمستخدم. في عالم مليء بالخيارات، المستخدمون لن ينتظروا صفحتك لتحميل إذا كان هناك بديل أسرع.
— مطور مجهول في مؤتمر Google I/O 2023