تطبيق: قم بقياس وقت استجابة موقع الويب الخاص بك باستخدام أداة القياس البسيطة هذه
عندما يتم تحميل موقع ويب ببطء، لا يتضح دائمًا سبب ذلك. هل هو DNS هل هو مزود الخدمة؟ الخادم نفسه؟ أم شيء بينهما؟ لمساعدة محترفي الويب على تحديد أماكن حدوث التأخير، نشرتُ هذه الأداة على هذا الموقع لقياس دورة حياة الموقع بالكامل. HTTP الطلب، من حل المجال إلى تسليم المحتوى.
تستخدم هذه الأداة المستندة إلى المتصفح تشخيصات من جانب الخادم لمحاكاة طلب HTTP حقيقي وتحليل مكونات توقيته. قد تكون مفيدة سواء كنت تدقق نطاقك، أو تستكشف مشاكل شريك تحميل بطيء، أو تعالجها. API، أو مجرد معيار CDN الأداء عبر عناوين URL.
استخدم الأداة أدناه لتحليل أداء أي جهة تواجه الجمهور URL:
كيفية قراءة النتائج
عند تشغيل اختبار، تقوم الأداة بتنفيذ اختبار مباشر cURL طلب معلومات التوقيت المفصلة بالثواني وإرسالها. إليك ما يعنيه كل مقياس من المقاييس المبلغ عنها:
- وقت البحث في DNS:يشير هذا إلى الوقت الذي يستغرقه حل اسم المجال إلى الاسم المقابل له عنوان IPإذا كان هذا الرقم مرتفعًا، فقد يشير إلى بطء خوادم الأسماء، أو مشاكل في انتشار DNS، أو ضعف أداء مزود DNS. توصي جوجل بالحفاظ على هذا الرقم أقل من 50 مللي ثانية، مع اعتبار أي رقم يتجاوز 100 مللي ثانية اختناقًا محتملًا.
- وقت اتصال TCPيقيس هذا المؤشر المدة التي يستغرقها إنشاء اتصال TCP مع الخادم. قد يشير التأخير هنا إلى زمن وصول الشبكة، أو جدران الحماية، أو المسافة إلى الخادم الأصلي. يُفضل استخدام قيم أقل من 100 مللي ثانية؛ بينما قد تشير الأوقات الثابتة التي تزيد عن 150 مللي ثانية إلى عدم كفاءة الشبكة أو التوجيه.
- وقت مصافحة TLS (HTTPS فقط): إذا تم تقديم الطلب عبر HTTPS، فإن هذا الرقم يعكس الوقت المستغرق في التفاوض على الاتصال الآمن. قد تتسبب مجموعات التشفير القديمة، أو الشهادات منتهية الصلاحية، أو خوادم الحافة المثقلة في حدوث تأخير طويل. TLS تعتبر Google أي وقت أقل من 100 مللي ثانية هو الوقت الأمثل، في حين أن الوقت الذي يتجاوز 200 مللي ثانية قد يكون مؤشرًا على وجود أخطاء في تكوين الأمان أو الأداء.
- وقت ما قبل النقل:يتضمن ذلك DNS، TCPوTLS - كل ما يحدث قبل إرسال الطلب الفعلي. يعكس هذا الوقت التراكمي لبدء التشغيل قبل أن يبدأ الخادم بمعالجة الطلب. تتراوح أوقات ما قبل النقل المثالية بين ١٠٠ و٣٠٠ مللي ثانية؛ ويجب دراسة أي وقت يتجاوز ٤٠٠ مللي ثانية على مراحل.
- الوقت المستغرق للوصول إلى البايت الأول (TTFB)يقيس هذا المقياس الوقت الذي يستغرقه الخادم لبدء إرسال استجابة بعد استلام الطلب. قد يشير ارتفاع TTFB إلى تأخيرات من جانب الخادم، مثل بطء استعلامات قاعدة البيانات، أو عدم تخزين المحتوى الديناميكي مؤقتًا، أو ضعف أداء الخادم. توصي جوجل بالحفاظ على TTFB أقل من 200 مللي ثانية؛ وتشير القيم المستمرة التي تزيد عن 500 مللي ثانية إلى مشاكل في الواجهة الخلفية أو البنية التحتية.
- إجمالي وقت النقلهذه هي المدة الكاملة من بداية الطلب حتى استلام البايت الأخير. إذا كان وقت الاستجابة (TTFB) سريعًا ولكن الوقت الإجمالي بطيء، فقد يكون ذلك بسبب حجم الاستجابة، أو اختناق الخادم، أو تأخير تسليم المحتوى. استهدف أقل من 500 مللي ثانية لحمولات HTML على النطاق العريض؛ قد يشير تجاوز الثانية الواحدة إلى عدم ضغط الموارد أو ضعف كفاءة التسليم.
- قانون الأحوال HTTP: هذا ال رمز الاستجابة تم إرجاعها من قِبل الخادم (على سبيل المثال، 200 للنجاح، 301/302 لإعادة التوجيه، 404 لعدم العثور). يوضح هذا السياق كيفية تعامل الخادم مع الطلب.
لا تقوم هذه الأداة بمحاكاة الطلب فحسب، بل تقوم بتنفيذه مباشرة على الخادم الخاص بي باستخدام PHP's cURL هذا يعني أنك ترى ما يراه الخادم، وليس فقط ما يلتقطه متصفحك. هذا مفيد لتصحيح أخطاء الأداء التي قد لا تكون مرئية من شبكتك المحلية.
جرّب الأداة ولا تتردد في اختبار مجموعة متنوعة من عناوين URL - صفحتك الرئيسية، أو نقطة نهاية واجهة برمجة تطبيقات محددة، أو مورد بعيد تعتمد عليه. كلما تعمقت في فهم مقاييس التوقيت هذه، زادت سرعة تشخيص أداء موقعك الإلكتروني وتحسينه.
