هل يجب تخزين Google Fonts على الخادم الخاص بي؟

في الأسابيع القليلة الماضية ، عن طريق الصدفة في العمل وفي مشاريع الطرف الثالث ، تعلمت الكثير عن خطوط الويب ، وكذلك الكثير عن خطوط Google على وجه الخصوص. بفضل هذا ، يمكنني تقديم إجابة أكثر تفصيلاً لسؤال بدا لي بسيطًا في الماضي: هل يجب عليك تخزين خطوط Google على خادمك؟

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

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

الاستضافة الذاتية مقابل الموارد الخارجية


قبل بضع سنوات ، كان من الطبيعي استخدام CDN لتوصيل الموارد المشتركة (على سبيل المثال ، jQuery مع code.jquery.com - ونعم ، لا يزالون يستخدمونها كثيرًا ). للتوضيح ، من خلال CDN هنا أعني تحميل الموارد من مجال شخص آخر ، وليس CDN الخاص بك.

كان السبب هو أن المتصفحات من المفترض أن تحد من عدد الاتصالات لكل مجال (عادة إلى 6 اتصالات) ، لذا فإن استخدام مجال آخر أعطاك 6 اتصالات أخرى. يمكن أن يكون هذا صحيحًا في الماضي (خاصة عندما كان التقييد أقل من 6 نطاقات) وقبل أن يصبح HTTPS هو القاعدة ، مما يؤدي إلى زيادة تكاليف الاتصال بشكل ملحوظ . بالإضافة إلى ذلك ، HTTP / 2يستفيد في الواقع من استخدام اتصال واحد (في الغالب!) ، لذا فإن استخدام المجالات الأخرى غالبًا ما يكون خسارة في الأداء وليس اكتساب.

هناك طريقة أخرى لتحقيق ذلك عن طريق تقسيم النطاق الرئيسي مع واحد أو أكثر من النطاقات الفرعية التقنية (على سبيل المثال ، asset.example.com) ، وفي هذه الحالة لا تظهر الخطوط على المجال الرئيسي الخاص بك ، حيث يتم تحميل صفحة الويب الخاصة بك. ومع ذلك ، فإن هذه الطريقة لها نفس مشاكل الاتصال ، لذلك لا يمكن أن يطلق عليها مكاسب الأداء ، حتى لو كانت ذات مرة.

ميزة أخرى لشبكة CDN العامة هي الاحتمال الكبير بأن يكون لدى الزوار بالفعل هذا الإصدار من jQuery الشرطي في ذاكرة التخزين المؤقت. ولكن ، مرة أخرى ، أنا مقتنع بأن هذا كثير للغاية. هناك الكثير من المكتبات وإصداراتهاذاكرة التخزين المؤقت للمتصفح أصغر مما قد يبدو ، لذلك من غير المحتمل أن تكون هذه المطابقة غير محتملة. بالإضافة إلى ذلك ، يستخدم Safari ذاكرة تخزين مؤقت HTTP فريدة لكل نطاق تمت زيارته ، لأسباب تتعلق بالخصوصية (ذاكرة تخزين مؤقت مزدوجة المفاتيح) ، وسيقدم Chrome هذه الوظيفة قريبًا . وبالتالي ، لا يوجد شيء آخر يمكن الجدل حوله.

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

لفترة طويلة ، كنت مقتنعًا بأن CDNs التابعة لجهات خارجية أو حتى تقسيم نطاقاتك الخاصة بعيدة جدًا عن مكاسب الأداء الموعودة. في كثير من الأحيان يمكنك العثور على مواقع حيث يوزع المجال الرئيسي index.html فقط ، وبعد ذلك يضيع الكثير من الوقت في إهدار إعداد اتصالات جديدة .

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

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

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

خطوط Google وكيفية عملها


خطوط Google هي مورد رائع إذا كنت تحب الخطوط. 977 خطوط مجانية يمكن لأي شخص استخدامها مجانًا. غالبًا ما تكون الخطوط التجارية باهظة الثمن للغاية ومرخصة عادةً بدلاً من بيعها ، أي يتم فرض رسوم بناءً على العدد المتوقع من مشاهدات الصفحة. لذلك ، من المفيد جدًا الحصول على العديد من الخطوط المجانية وسهلة الاستخدام في مجموعة واحدة.

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

<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

يمكنك أيضًا إضافة المزيد من الخصائص والخطوط في سطر واحد لتحميل العديد من الخطوط والأشكال لكل منها:

<link href="https://fonts.googleapis.com/css?family=Lato:400,400i,700,700i,900%7CPoppins:300,400,700,900&display=swap" rel="stylesheet">

العيب هو انخفاض في الأداء (الميزة هي أيضًا في الأداء ، ولكن هذا ليس واضحًا جدًا ، سنصل إلى ذلك). تكمن المشكلة في أن موقعك (على سبيل المثال www.example.com ) يُحمّل ورقة أنماط من fonts.googleapis.com ، والتي تُرجع بعض CSS بقواعد واجهة الخط. هنا مصدر الرابط في المثال أعلاه:

/* latin-ext */
@font-face {
  font-family: 'Lato';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: local('Lato Regular'), local('Lato-Regular'), url(https://fonts.gstatic.com/s/lato/v16/S6uyw4BMUTPHjxAwXiWtFCfQ7A.woff2) format('woff2');
  unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
/* latin */
@font-face {
  font-family: 'Lato';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: local('Lato Regular'), local('Lato-Regular'), url(https://fonts.gstatic.com/s/lato/v16/S6uyw4BMUTPHjx4wXiWtFCc.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

سنتحدث عن ما تعنيه بعض هذه الإعدادات لاحقًا (وأيضًا حول سبب وجود قاعدتين لوجه الخط) ، ولكن هذا يعني الآن أنه يمكنك استخدام هذا الخط في أنماطك مثل هذا:

body {
    font-family: 'Lato', sans-serif;
}

ومع ذلك ، يجب عليك الآن الاتصال بـ fonts.googleapis.com ، وتنزيل CSS ، ثم الاتصال بـ fonts.gstatic.com وتنزيل الخطوط بأنفسهم (لماذا لا تستطيع Google استضافة CSS والخطوط على نفس النطاق - لا أفهم حقًا!).

غالبًا ما يكتشف المتصفح الخطوط مع تأخير عند تحميل الصفحة (بعد كل شيء ، تحتاج إلى تحميل CSS للعثور على روابط لها). ولكن تم اكتشاف خطوط Google في وقت لاحق ، لأن CSS بحاجة إلى التنزيل من نطاق آخر ، ثم الخطوط من النطاق الثالث ، وكما ذكرت ، فإن إنشاء اتصال HTTPS ليس فوريًا أيضًا. يمكن رؤية ذلك في الرسم التخطيطي المتتابع أدناه الذي تم إنشاؤه بواسطة WebPageTest (لاحظ أنه تم تشغيل جميع الاختبارات باستخدام Chrome - 3GSlow):



يوضح السطر 1 أنه تم تحميل HTML أولاً. بعد ذلك ، بمجرد تنزيله وقراءته في أقل من ثانيتين ، يكتشف المتصفح الحاجة إلى تحميل CSS لخطوط Google وتحميله في السطر 4. ويستغرق الأمر ثانية لإنشاء اتصال ثم يتم تنزيل ملف لمدة 3.5 ثانية. أخيرًا ، اكتشف المتصفح وجود خطنا وحمله على السطر 6 ، بعد أن فقد ثانية ونصف ثانية أخرى في طريقه إلى الاتصال مع fonts.gstatic.com.

وبالتالي ، فإن استخدام هذا الخط من خطوط Google يكلفنا ثلاث ثوانٍ كاملة من الإنتاجية منذ لحظة توفر HTML ، مع عدم مراعاة الوقت لتنزيل الخط نفسه!

تسريع خطوط Google عن طريق تحميل الموارد مسبقًا


يمكنك التخفيف من هذا الأداء الفظيع عند تحميل CSS والخطوط من مجالين مختلفين. يجب تحديد موقع المجال الأول (لـ CSS) بالقرب من بداية ملف index.html بحيث يقرأه المستعرض في أقرب وقت ممكن ، ولكن النطاق الثاني لا يزال مخفيًا. ومع ذلك ، فإننا نعلم كيف سيكون هذا المجال (fonts.gstatic.com) ، حتى نتمكن من فتح الاتصال مقدمًا لتوفير بعض الوقت في الاتصال الثاني لاحقًا:


<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

عند إعادة الاختبار ، نرى الصورة التالية:



هنا نرى أن الاتصال على السطر 5 مفتوح مسبقًا ، قبل تحميل CSS. لذا فزنا بأكثر من ثانية واحدة (تنزيل الخطوط في 4 ثوانٍ وليس 5.25) ، لأننا تمكنا من تجنب إضاعة الوقت أثناء الاتصال ويتم تنزيل الخطوط فورًا بعد قراءة CSS Google Fonts.

قد تعتقد أنه يمكنك المضي قدمًا وتحميل الخط بالكامل مسبقًا ، بدلاً من كونك راضيًا بالانضمام إلى المجال فقط ، ولكن Google Fonts تستدعي تجزئات الخطوط الفريدة. في المثال أعلاه ، يسمى الخط الذي تم تنزيله S6uyw4BMUTPHjx4wXg.woff2 ، وليس lato.woff2 ، لذلك لا يمكن التحميل المسبق إلا إذا كنت ترغب في تعطل موقعك يومًا ما عندما يقرر Google فجأة تغيير هذا التجزئة.

على أي حال ، إذا كنت تستخدم خطوط Google ولا تنوي القيام بأي شيء آخر بعد قراءة هذه الملاحظة ، فأضف على الأقل اتصالًا أوليًا بالنطاق ، إذا لم يكن بالفعل. هذا مجرد سطر واحد من الكود ويجب أن يحسن أداء صفحتك بشكل ملحوظ.

في الواقع ، توفر خطوط Google أمرًا مشابهًا في رؤوس HTTP عند عرض CSS:



ولكن في كثير من الحالات ، لن يساعد ذلك كثيرًا ، لأنه في الوقت الذي تتلقى فيه رؤوس استجابة HTTP من الخادم باستخدام CSS ، يعرف المستعرض بالفعل أنك تريد الاتصال بهذا المجال لتنزيل الخطوط. لذا من الأفضل لك تحديد ذلك في شفرة HTML الخاصة بك حتى يعمل التحميل المسبق في وقت سابق (لا يهم أنه يتم تكرارها بهذه الطريقة ، سيتم تجاهل المحاولة الثانية). ومع ذلك ، إذا كانت صفحتك لا تزال قيد المعالجة في الوقت الذي يتم فيه تلقي الرؤوس من خادم CSS لخطوط Google ، ولم يكن DOM جاهزًا (ربما تكون هذه علامة على وجود الكثير من جافا سكريبت على صفحتك؟) ، يمكن أن يساعد ذلك في تحسين الأداء عندما يتضح في النهاية أي خط لتحميل.

عرض الخط: Swap


في رمز وجه الخط أعلاه ، يمكنك رؤية عرض الخط: swap؛ line. هذه تعليمات جديدة نسبيًا. يمكن إضافته إلى إعلان الخط وسيخبر المتصفح أن يستخدم الاحتياط أولاً ، أي خط النظام (sans-serif في هذا المثال) ، ثم استبدله بالخط الحقيقي بعد تنزيله. بهذه الطريقة يمكنك تجنب التأخير في تحميل المحتوى عندما لا يتم تحميل الخط حتى الآن وتحسين الأداء بشكل جيد.

نعم ، هذا يؤدي إلى انتشار النص غير المستقر (FOUT) - نفس "القفزات" في المحتوى أثناء تحميل الصفحة ، لكن بعض الأشخاص لا يحبون ذلك (رأيي موافق ، المحتوى أكثر أهمية من التصميم ، لكن النص الذي يقفز عبر الصفحة مزعج ، على الرغم من يمكن تخفيف ذلك عن طريق تعديل الخط الاحتياطي). البديل هو نص غير مرئي فلاش (FOIT). في هذه الحالة ، يتم إخفاء النص حتى يظهر الخط ، مما يؤخر التنزيل بوضوح ويمكن أن يسبب مشاكل أخرى إذا تم تحميل بعض النص ، ولكن البعض الآخر لا !

على أي حال ، قبل إدخال عرض الخط: التبديل ، تعاملت المتصفحات المختلفة مع هذا بشكل مختلف - البعض ، مثل IE و Edge ، استخدم FOUT ، والبعض الآخر استخدم FOIT ، وكان لديهم أوقات مختلفة حتى ينتظروا الخطوط للانتظار. ولهذا السبب ، إذا لم يتم تحميل الخط ، فقد يظل محتواك غير مرئي لفترة طويلة. إدخال عرض الخط: سمحت المبادلة لمطوري مواقع الويب بأن يقرروا بأنفسهم كيف سيحدث هذا. معظم المتصفحات تدعم عرض الخطوط: مبادلة ، باستثناء IE و Edge ، ولكن كما ذكرنا أعلاه ، فإنها تستخدم هذا بشكل افتراضي على أي حال. تدعم خطوط Google أيضًا خيارات عرض الخط المختلفة وتقدم عرض الخط: التبديل بشكل افتراضي.

لذا ، فإن نصيحة أخرى إذا كنت تستخدم خطوط Google هي التحقق من أن لديك معلمة & display = swap في عنوان URL ، وإذا لم يكن (أصبح مدعومًا مؤخرًا فقط) ، فقم بإضافته:

على سبيل المثال ، استبدل هذا:


<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato" rel="stylesheet">

على هذا:


<link href="https://fonts.gstatic.com" rel="preconnect" crossorigin>
<link href="https://fonts.googleapis.com/css?family=Lato&display=swap" rel="stylesheet">

يمكنك أيضًا تحديد إحدى قيم عرض الخط الأخرى ، على سبيل المثال اختياري ، إذا كنت ترغب في ذلك.

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

Google Fonts


لقد ساعدت في إنشاء Web Almanac (نظرة رائعة على حالة الإنترنت - انظر بنفسك إذا لم تكن قد شاهدتها بعد) وأزعجني التنزيل البطيء لخطوط Google على موقعنا وأردت إصلاحها. FOUT خاصة مع عرض الخط: مبادلة. كنت أتساءل عما إذا كان بإمكاننا تقليل تأثير ذلك ، وبدا أن الحل المحلي هو تخزين الملفات محليًا ، وربما باستخدام التحميل المسبق.

لقد استخدمنا بالفعل التقنيات المذكورة أعلاه (التحميل المسبق وعرض الخطوط: مبادلة ؛) ، ولكن ، بالطبع ، سيكون من الأفضل الابتعاد عن ربط CSS من الخارج. نحن نعلم ماذا سيكون في CSS. لذا ، اختر بثقة اختيار الاستضافة الذاتية؟ هذا هو المكان الذي يصبح فيه مثيرًا للاهتمام ...

لقد وجدت نصًا مناسبًا على GitHub ( Google Font Download) ، مما ساعدني على تنزيل جميع خيارات الخطوط المختلفة (نظرًا لوجود الكثير منها ، حتى 9 اعتمادًا على الصفحة) ، ثم نسخ CSS ، الذي عرضته في ورقة الأنماط الرئيسية لدينا ، وتحميل الخطوط إلى الخادم. هناك أدوات أخرى عبر الإنترنت تفعل الشيء نفسه. يبدو أن كل شيء يعمل ، وتخلصنا من تحميل CSS المزعج والحاجة إلى العمل مع مجالين.

ومع ذلك ، عند الفحص الدقيق ، لاحظت أن الخطوط كانت أكبر:



كما ترى ، كانت هناك زيادة كبيرة في الحجم (حتى 74٪ إضافية لبعضها!) بالمقارنة مع خطوط Google التي تم تنزيلها (يمين) والخطوط الموضوعة محليًا (يسار). في البداية ، اعتقدت أن هذا يرجع إلى خادم الويب المحلي ، على سبيل المثال ، بسبب إيقاف الضغط. ولكن يتم عرض خطوط WOFF2 دون ضغط من قبل خادم الويب - أو على الأقل يجب أن يكون - لأن التنسيق يتضمن ضغط Brotli. أيضًا ، تُظهر لقطة الشاشة أعلاه وحدات البايت التي تم تنزيلها (الأسود في الأعلى) ، بالإضافة إلى وحدات البايت غير المضغوطة (أفتح قليلاً في الأسفل) لكل عمود (وهي متشابهة تمامًا في كلا العمودين ، حيث يتم إرسال الخطوط حقًا دون ضغط من قبل خادم الويب ، ولكن وحدات البايت التي تم تنزيلها تتضمن رؤوس HTTP ، لذا فهي أكبر قليلاً) ، وكانت هناك اختلافات في كل من وحدات البايت المضغوطة وغير المضغوطة ، لذلك ليست هذه هي النقطة.

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

من Google Fonts:

/* latin-ext */
@font-face {
    font-family: 'Lato';
    font-style: normal;
    font-weight: 400;
    font-display: swap;
    src: local('Lato Regular'), local('Lato-Regular'), url(https://fonts.gstatic.com/s/lato/v16/S6uyw4BMUTPHjxAwXiWtFCfQ7A.woff2) format('woff2');
    unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
/* latin */
@font-face {
    font-family: 'Lato';
    font-style: normal;
    font-weight: 400;
    font-display: swap;
    src: local('Lato Regular'), local('Lato-Regular'), url(https://fonts.gstatic.com/s/lato/v16/S6uyw4BMUTPHjx4wXiWtFCc.woff2) format('woff2');
    unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

من أداة التنزيل:

@font-face {
    font-family: 'Lato';
    font-style: normal;
    font-weight: 400;
    src:
        local('Lato Regular'),
        local('Lato-Regular'),
        /* from https://fonts.gstatic.com/s/lato/v16/S6uyw4BMUTPHjx4wXg.woff2 */
        url('Lato_400.woff2') format('woff2'),
        /* from https://fonts.gstatic.com/s/lato/v16/S6uyw4BMUTPHjx4wWA.woff */
        url('Lato_400.woff') format('woff');
}

الاختلاف الأول هو أننا فقدنا عرض الخطوط: خط المبادلة ، ولكن يمكن إصلاح ذلك دون مشاكل. الأمر الأكثر إثارة للاهتمام هو حقيقة أن خطوط Google توزع خطين - وتتضمن نطاقات Unicode مختلفة فيها. ويرجع ذلك إلى تعيين الخط الفرعي وتقليل ملفات الخطوط.

الخط الفرعي


الخط الفرعي للخط هو إزالة الأحرف التي لن تستخدمها لتقليل حجم ملف الخط. عادةً ، يستخدم معظم الغربيين أحرفًا لاتينية فقط ، وتنزيل خط بكل الأحرف التي ربما لن تستخدمها أمر غير منطقي. لقد سمعت عن هذا من قبل ، لكنني لم أفكر أبدًا في مدى أهمية ذلك! تعرض خطوط Google تلقائيًا خطًا للخط مع مجموعة من الأحرف اللاتينية ، وكذلك ، حيثما أمكن ، يربط خطًا ثانيًا للأحرف اللاتينية الموسعة (على سبيل المثال ، Ā) ، والذي سيتم تنزيله فقط إذا لزم الأمر.

في الواقع ، يمكنك أيضًا طلب خط خاص يحتوي فقط على الأحرف التي تحتاج إليها باستخدام معلمة النص:

https://fonts.googleapis.com/css؟family=Lato&text=ABC

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

تقوم خطوط Google بتوزيع الخطوط بذكاء


لا تقدم خطوط Google دائمًا نفس CSS وتعتمد على وكيل المستخدم المستخدم . على سبيل المثال ، بالنسبة لبرنامج Internet Explorer 11 ، يرسل ما يلي:

@font-face {
    font-family: 'Lato';
    font-style: normal;
    font-weight: 400;
    font-display: swap;
    src: local('Lato Regular'), local('Lato-Regular'), url(https://fonts.gstatic.com/s/lato/v16/S6uyw4BMUTPHjx4wWA.woff) format('woff');
}

هنا يمكنك أن ترى أنه يوفر تنسيق WOFF فقط ، لأن IE 11 لا يدعم WOFF2 ، ولنفس السبب لم يتم تحديد نطاق unicode. إنه يعطي عرض الخط: مبادلة (كما أشرت في عنوان URL لـ CSS) ، على الرغم من أن المتصفح لا يدعمه ، ولكنه لا يضر.

إنها ليست فقط الشركة المصنعة وإصدار المتصفح. تلميح الخطيتضمن تعليمات إضافية في ملف الخط ، والتي يتم استخدامها بعد ذلك لتقديم أفضل عرض للخط - خاصةً على الشاشات منخفضة الدقة أو للأحجام الصغيرة حقًا. يتم استخدام تلميحات الخطوط على نظام التشغيل Windows ، ولكن ليس على نظام التشغيل MacOS ، لذلك بناءً على نظام التشغيل الذي تعمل معه عند تلقي خطوط Google ، باستخدام متصفح (حتى إذا كنت تستخدم Chrome على كل نظام أساسي) ، فقد تحصل على ملفات الخطوط مع تلميحات أو بدونه. إذا قمت بتنزيل إصدار Windows واستخدمته بنفسك ، فستجعل مستخدمي MacOS يعانون بالفعل من الحاجة إلى معالجة ملفات الخطوط الكبيرة المليئة بالتلميحات غير المستخدمة ، وإذا فعلت العكس ، فمن المحتمل أن تجعل مستخدمي Windows يعانون من عرض خط أسوأ ، دون تلميح الخط.

عندما استخدمت Google Fonts ، وعندما قمت بتنزيل الخطوط للاستخدام المحلي ، قمت بذلك على جهاز Mac الخاص بي ، لذا حصلت على ملفات أصغر. عندما استخدمت الأداة ، حصلت على خطوط كاملة ، مع تلميح. لذلك كان هذا سببًا آخر لاختلاف الحجم الكبير!

هل لا يزال تلميح الخط ذا صلة، لأن الشاشات عالية الوضوح أصبحت أكثر شيوعًا - هذا سؤال جيد ، ويتم تسليم العديد من الخطوط في البداية دون تلميح ، حيث يستغرق إنشائها الكثير من الوقت. عندما يكون موجودًا - يمكن أن يزيد حجم الخط بشكل ملحوظ. في حالة Lato ، يتم مضاعفة الحجم. هل يستحق عبء العمل الإضافي الذي ستواجهه من خلال التخلي عن خطوط Google وتحديد الخطوط محليًا؟ هذا قرار آخر عليك اتخاذه بنفسك.

لذلك ، يتم دعم CDN لخطوط Google من خلال نص برمجي ذكي يمنح الخطوط الأكثر ملاءمة ، مما يحسنها للحفاظ على أقصى أداء. بالانتقال إلى التخزين المحلي للخطوط ، سيكون عليك تكوين كل هذا بنفسك ، وهناك فرصة لفقد العرض الصحيح للخطوط في بعض المتصفحات إذا لم تقم بذلك.

بالنسبة إلى Web Almanac ، راجعنا الإحصائيات الخاصة بمتصفحات الزائرين وقررنا دعم WOFF2 فقط ، وأيضًا استخدام إصدارات MacOS دون التلميح ، لأنها تزن نصف الوزن. هذا CSS المبسط (خاصة وأن نطاق unicode مدعوم من قبل جميع المتصفحات التي تدعم WOFF2) ، ومستخدمي IE 11 والمتصفحات القديمة الأخرى يرون sans-serif بشكل افتراضي ، وهو ما لا يبدو جيدًا جدًا ، ولكن في رأينا ، فإن الخطوط هي تحسن تدريجي ، وحتى بدونها ، لا يزال الموقع أكثر قابلية للاستخدام. بالإضافة إلى ذلك ، قد تستفيد المتصفحات القديمة من استخدام الخطوط الافتراضية للنظام ، حيث من المحتمل استخدامها على أجهزة قديمة منخفضة الطاقة.

يمكنك أيضًا إجراء تعديلات أخرى على الخطوط الخاصة بك إذا كنت ترغب في ذلك (تحقق من التراخيص أولاً!) ، ولكن نسخ خطوط Google الافتراضية المستخدمة في Chrome على MacOS ربما يكون كافياً لمعظمنا إذا كنت تريد دعم متصفحات WOFF2 فقط دون التلميح .

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

تحسينات الخطوط المستقبلية


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

خطوط متغيرة


تتيح لك الخطوط المتغيرة استخدام أنماط خطوط مختلفة دون الحاجة إلى تنزيل ملفات فردية. ذكرت سابقًا أن Web Almanac يستخدم ما يصل إلى 9 ملفات خطوط مختلفة ، ولكن في الواقع إنه خطان فقط. والسبب بسيط - يستخدم الموقع أيضًا إصدارات جريئة ومائلة وجريئة وحتى أرفع من أحدهما أو كليهما. قد تبدو العديد من الاختلافات من نفس الخط غير مناسبة وقد تعتقد أن المتصفح نفسه سيتعامل مع مهمة تغيير سمك النص أو كتابة خط مائل. نعم هذا ممكن. لكن كل متصفح يفعل ذلك بشكل مختلف قليلاً ، ويمكن أن تكون النتائج مختلفة جذريًا ، لذلك يطلق عليها الكثيرون "الخطوط الاصطناعية".

الطريقة الوحيدة لضمان نفس العرض هي استخدام "خط حقيقي" خصيصًا لكل نمط تحتاجه.

تقوم الخطوط المتغيرة بتوحيد عرض تنويعات الخطوط المختلفة وتختفي الحاجة إلى ملفات إضافية. نظريًا ، يمكننا استبدال هذه الخطوط التسعة بخطوط 2 عندما تصبح إصدارات الخطوط المتغيرة متاحة.

هذا يفتح الكثير من الاحتمالات لاستخدام الخطوط على الإنترنت. على الرغم من أنه قد يبدو لي أن الخيارات التسعة للخطين كثيرة للغاية ، إلا أنها في الواقع ليست كثيرة للغاية ، في حين أن الخطوط المتغيرة تسمح بتغيرات لا نهاية لها. على الأجهزة المحمولة ، يمكنك تعيين سماكة مختلفة قليلاً لـ "جريئة" من أجهزة سطح المكتب والأجهزة اللوحية. خطوط متغيرة مع بعض تعليمات CSS البسيطةالسماح بذلك دون تكلفة الموارد لتنزيل خط إضافي. في الآونة الأخيرة في DotCSS ، تحدث جيسون بورتيكال عن الخطوط المتغيرة وأظهر كيف يمكنك الحصول على صفحة مصممة بشكل جميل مع ما يبدو أنه الكثير من الخطوط المختلفة - كل ذلك باستخدام ملف واحد! يعني

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

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

إثراء الخط التدريجي


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

إثراء الخط التقدمي ، كما أفهمه ، في مرحلة أبكر بكثير من الخطوط المتغيرة ، ولكن هناكعرض على الإنترنت . على أي حال ، هذا تغيير آخر محتمل مثير للاهتمام يتعلق بالخطوط.

هل ستستمر خطوط Google في التحسن؟


بالنظر إلى كيفية عمل Google Fonts ، من السهل أن تتخيل أنه يمكن أن تستمر في النمو مع التحسينات الجديدة ، مثل تلك الموصوفة في هذه المقالة (أو غيرها!) ، فقط عن طريق تغيير CSS التي تقدمها. ويستطيع فعل ذلك بحكمة. على سبيل المثال ، تحديد ما إذا كان متصفحك يدعم تقنية جديدة (كما هو الحال الآن مع تنسيق الخط - WOFF أو WOFF2) ، أو بطرق أخرى. على سبيل المثال ، إذا طلبت أكثر من خطين وأعطت خطًا متغيرًا أقل كثافة في استخدام الموارد ، فبإمكانك أتمتة ملف الخط نفسه والارتباط به في العديد من إعلانات الوجه للخط ، وإذا طلبت خيارًا واحدًا فقط ، فراجع خطًا خفيفًا أكثر الخط التقليدي. تبدو بعيدة المنال؟ لقد فعلوا ذلك بالفعل بخط واحد.(أوزوالد)! بصراحة ، لا أعرف ما إذا كان الشيء نفسه ممكنًا مع إثراء الخط التقدمي ، لأنني لا أفهم تمامًا مبدأ عملها ، ولكن سيكون من المثير للاهتمام رؤيته.

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

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

فوائد تخزين الخط المحلي


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

بالنسبة إلى Web Almanac ، اخترنا مؤخرًا التخزين المحلي لخطوط Google ، وأظهر الاختبار تغييرات جذرية:



تحتوي الصورة السفلية على خطوط محلية على خادم الاختبار الخاص بنا ، ويمكنك أن ترى أن وقت التنزيل قد انخفض إلى النصف - من 6 إلى 3 ثوانٍ! بعد تحليل أعمق ، رأيت أن الإنتاجية زادت أكثر (3 ⅓ ثانية من المدخرات)!

ما هو غير واضح (ولكن ما سنراه لاحقًا) - في هذه المرحلة ، لا يتم تحميل الخطوط بالكامل على أي من الصور - مع التخزين المحلي يستغرق 7.5 ثانية و 10.5 ثانية عند استخدام خطوط Google. ومع ذلك ، فإن الخطوط المستخدمة تشبه إلى حد كبير الخطوط القياسية ، ولا توجد قفزات ملحوظة في التخطيط. يمكن رؤية ذلك في الرسم البياني أدناه:



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

يرجع السبب في أن التحسينات ملموسة حقًا إلى شيء آخر لم أخذه في الاعتبار في البداية: حظر CSS للعرض. لذلك إذا كان هناك رابط إلى Google Fonts CSS ، فإن المتصفح لا يؤخر عرض النص فحسب - بل يؤخر عرض محتوى الصفحة بالكامل! يعد الخط تحسينًا تدريجيًا ، لذا يمكننا عرض بقية الصفحة بأمان ، وحتى النص نفسه (مع الخطوط القياسية / الاحتياطية) ، ولكن المتصفح لا يفعل ذلك - يرى فقط أن هناك بعض CSS ويحاول تحميله ، مما يؤجل التنزيل ما تبقى من الصفحة. لا يوجد تحميل غير متزامن لـ CSS- ولكن ربما يجب أن يكون لمثل هذه الحالات؟ ومع ذلك ، فإننا نخاطر بأنه في حالة حدوث مشكلات في الاتصال بخطوط Google ، لن يمكن الوصول إلى موقعك بالكامل حتى يتوقف المتصفح عن محاولة معالجة الارتباط!



في مخطط المقارنة أعلاه ، يظهر الخط الأخضر العمودي Start Render في وقت مبكر يصل إلى 6 ثوانٍ - حيث يجب عليه الانتظار حتى يتم تحميل Google Fonts CSS على السطر 12 ، حيث يقضي نصف الوقت في الاتصال بالنطاق والنصف الآخر يتم تحميله بالفعل.

قارن هذا بالإصدار المحلي:



هنا يمكننا البدء في العرض بمجرد تحميل CSS للموقع ومعالجته في 2.5 ثانية. هذا لأنه لا يوجد تأخير في الاتصال بنطاق خطوط Google.

في كلتا الحالتين ، نرى أن بداية العرض تحدث قبل تحميل الخطوط ، وبفضل سحر عرض الخطوط: تبديل ، لا يزال النص مرئيًا. لذلك ، على الأقل عند استخدام font-display: swap ، سيكون من الأفضل إذا لم يتم تحميل خطوط Google باستخدام عرض حظر CSS ، ولكن ، على سبيل المثال ، تم تحميلها عبر JavaScript غير متزامن ، والذي يُدرج خطوط CSS في الصفحة فقط بعد كيف يتم تنزيلها. إذا تم تنفيذ العملية بهذه الطريقة ، فلن يحدث تأخيرات في العرض ، ومع ذلك ، لا يزال هناك تأخيرات عند الاتصال وانتظار طويل حتى يتم عرض النص بشكل صحيح.

UPD: لقد أنشأت مشكلة على GitHub Google Fonts مع اقتراح لإضافة طريقة لتنزيل Google Fonts دون حظر العرض - قم بالتصويت إذا كنت تريد ذلك أيضًا!

يدعم Zach Leatherman هذا النهج لتقليل عدد عمليات إعادة السحب ، ويوضح أن هذا ممكن أيضًا مع JavaScript وحده ، دون الحاجة إلى ملف CSS. ثم يعرض مزايا أخرى لإدارة خطوطك باستخدام جافا سكريبت ، على سبيل المثال ، يمكنك رفض تنزيل الخطوط على الإطلاق إذا كان الموقع مفتوحًا من شبكة بطيئة (باستخدام واجهة برمجة تطبيقات معلومات الشبكة ) ، أو إذا تم تمكين إعدادات حفظ البيانات أو تفضيلات الحركة المخفضة . ميزات مثيرة للاهتمام!

التحميل المسبق للخطوط


بمجرد أن تبتعد عن عناوين URL المجزأة من Google ، ستتمكن من تحميل الخط مسبقًا لتحسين الأداء. ومع ذلك ، فإن هذا الخيار يحتوي على بعض العيوب المحتملة ، كما ناقش آندي ديفيز في مقال التحميل المسبق للخطوط ولغز الأولويات . بشكل أساسي ، من خلال التحميل المسبق للخطوط وتحريكها لأعلى في ترتيب الأولوية ، فإنك تنخفض ضمنًا أولوية أولوية التنزيلات المهمة الأخرى (على سبيل المثال ، CSS) ، وبسبب خطأ في Chrome ، يمكن أن تقفز الخطوط فوق بعضها.

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

عند استخدام عرض الخط: وظيفة التبديل ، قد لا تكون الحاجة إلى التحميل المسبق قوية. على الرغم من أنه في هذه الحالة ، لا يزال بإمكانك كسب الوقت عن طريق تنزيل الحد الأدنى المطلوب من الخطوط وبالتالي تجنب FOUT وإعادة الرسم. في الوقت الحالي ، لا نستخدم التحميل المسبق في Web Almanac وقبل أن نبدأ ، نحتاج إلى بعض الاختبارات الإضافية ، لكني الآن راضٍ عما هو.

استنتاج


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

ومع ذلك ، فإن Google Fonts ليست مجرد مستودع لمئات الخطوط المجانية - بل هي أيضًا آلية تسليم ذكية تستخدم العديد من أحدث تقنيات التحسين لتقديم الخطوط الأكثر ملاءمة بأقل جهد من جانب مالك الموقع. بالانتقال إلى الاستضافة الذاتية ، من الناحية المثالية ، تحتاج إلى إعادة تنفيذ العديد من التحسينات المفيدة ، مثل عرض الخط: التبديل ، وإزالة تلميحات الخط (على الأقل لبعض المتصفحات) ، أو خلاف ذلك ، يمكنك فقط الإضرار بأداء الثقيل ملفات الخط.

هذه ليست مهمة سهلة (و Google Fonts تقوم بذلك نيابةً عنك). ولكن نظرًا لأن استخدام تنسيق WOFF2 فقط هو الخيار الواقعي الوحيد الآن ، والمتصفحات تدعم معظم تقنيات التحسين ، فقد أصبح كل شيء أسهل بكثير من ذي قبل. ومع ذلك ، يجدر الحصول على بعض المعرفة حول خطوط الويب قبل إعداد كل شيء (آمل أن يساعد هذا المنشور!) ، وفي الوقت نفسه راقب التغييرات الجديدة في عالم الخطوط ، حيث سيكون هناك بلا شك تحسينات إضافية.

حسنًا ، ربما كنا حريصين للغاية على التحسين ومع التخزين المحلي يمكننا تحمل استخدام الخط الكامل ، دون الحاجة إلى الإضافة الفرعية والتلميح؟ على موقع Google Fonts ، يمكنك تنزيل أي خط وهو بسيط نسبيًا ، على الرغم من أنه من الغريب أن الأرشيف لا يتضمن تنسيقات WOFF و WOFF2عند استخدام طريقة التحميل هذه ، وهي غير مفهومة تمامًا بالنسبة لي! ومع ذلك ، إذا كنت مهتمًا حقًا بتحسين الأداء (ويجب أن تكون مهتمًا!) ، فعليك أن تحاول فعل الشيء الصحيح. توضح هذه المقالة فقط أنها أكثر تعقيدًا من مجرد تنزيل الخطوط ووضعها على موقعك ، كما توقعت دائمًا.

رائع ، لقد تبين أن نصًا ما كان أطول مما كنت أتوقع! ولكن آمل أن تكون مهتمًا تمامًا بفهم الموضوع كما أنت ولديك الآن بعض الأفكار الجديدة لتسريع تنزيل الخطوط على موقعك. أوصي بشدة بمتابعة Jason و Zach على Twitter لمعرفة المزيد عن الخطوط ، و Andy لمعرفة المزيد عن السرعة الإجمالية لتطبيق الويب.


All Articles