آموزش گام‌به‌گام فونت فارسی و سرعت

در صفحات فارسی، فونت فقط یک انتخاب زیبایی‌شناختی نیست؛ بخشی از مسیر رندر است. متن، محتوای اصلی صفحه است و در سایت‌های فارسی تقریباً همهٔ آن به یک یا دو وب‌فونت وابسته است — فایل‌هایی که باید دانلود، تحلیل و رندر شوند تا کاربر چیزی بخواند. به تجربهٔ ما در ممیزی‌های سرعت، فونت‌های تازه‌نصب‌شدهٔ فارسی گاهی با چند وزن و چند فایلِ تکراری دیده می‌شوند که مجموعشان از هر تصویر صفحه سنگین‌تر است؛ و چون هیچ هشداری صادر نمی‌شود، سال‌ها همان‌جا می‌مانند.

این مقاله قدم‌به‌قدم اجرا است و دو مقالهٔ خواهر، دو لایهٔ دیگر را می‌بندند: روش کامل اندازه‌گیری و خواندن نتایج در آموزش گام‌به‌گام تست سرعت سایت و لایهٔ زیرین — پاسخ‌دهی سرور و کش — در آموزش TTFB و سرعت سرور. اگر سرور کند است، فونت را اول اصلاح نکنید؛ ترتیب لایه‌ها را همان مقاله می‌گوید و این‌جا فرض ما این است که زیرساخت، سرعت پایهٔ قابل‌اتکایی دارد.

فونت فارسی و سرعت سایت؛ گره‌ای که اول باید باز شود

چرا فونت فارسی از لاتین سنگین‌تر تمام می‌شود؟ سه دلیل ساختاری دارد. نخست، تعداد گلیف: الفبای فارسی و اشکال متصل حروف، مجموعهٔ کاراکتری بزرگ‌تری از لاتین می‌خواهد و اعداد فارسی و عربی هم به همان فایل اضافه می‌شوند. دوم، چندوزن‌بودن: قالب‌ها معمولاً وزن معمولی متن و یک وزن سنگین‌تر برای عنوان می‌خواهند و هر وزن یعنی یک فایل کامل. سوم، چندفونت‌بودن: هدر، متن و گاهی فونت سومی برای برند — ضرب این سه، چند درخواست و چند صد کیلوبایت می‌سازد که به تجربهٔ ما در ممیزی‌ها زیاد دیده شده است.

اثرش هم دو لایه دارد: لایهٔ اول، زمان بارگذاری — فایل بزرگ‌تر، دیرتر می‌رسد و هر چه دیرتر برسد، متن دیرتر به شکل نهایی خودش می‌نشیند. لایهٔ دوم، پایداری رندر — رفتاری که مرورگر تا رسیدن فونت دارد (متن نامرئی یا فال‌بک) به انتخاب شما بستگی دارد، نه به فونت. چهار قدم بعدی دقیقاً همین دو لایه را می‌بندند: مسیر رساندن فایل، حجم فایل، رفتار رندر و پشتهٔ جایگزین. هر قدم مستقل است و می‌تواند جداگانه اعمال و جداگانه سنجیده شود.

قدم اول؛ میزبانی محلی در برابر CDN خارجی

قدم اول، تصمیم میزبانی است و برای مخاطب داخل ایران، تصمیم حساسی. واقعیت دسترس‌پذیری این است که فایل‌های میزبانی‌شده روی CDNهای خارجی از برخی شبکه‌های اینترنتی کشور، کند یا ناپایدار می‌رسند؛ فونتی که نرسد، صفحه با فال‌بک می‌ماند یا بدتر، بدون متن. به تجربهٔ ما، میزبانی فونت روی زیرساخت خود سایت — همان هاست یا همان شبکهٔ توزیع داخلی که صفحه از آن می‌آید — قابل‌اتکاتر است، چون دسترس‌پذیری صفحه و فونتش به یک لایه گره می‌خورد و دیگر دو مسیر جداگانه برای شکست ندارید.

اجرایش سه کار کوتاه است: فایل‌های فونت را به پوشه‌ای در هاست خودتان منتقل کنید؛ اتصال‌های از پیش تعریف‌شده به دامنه‌های بیرونی را که برای فونت باز کرده بودید حذف یا به دامنهٔ خودتان تغییر دهید تا مرورگر زودتر دانلود را شروع کند؛ و در قالب، آدرس فونت‌ها را به مسیر داخلی اصلاح کنید. چارچوب کلی تصمیم CDN برای سایت‌های ایرانی — چه نگه دارید چه نبرید — در CDN برای سایت‌های ایرانی جداگانه باز شده است؛ این‌جا فقط فونت را می‌بندیم.

قدم دوم؛ قالب woff2 و زیرمجموعه‌سازی

قدم دوم، کوچک‌کردن خود فایل است و دو اهرم دارد. اهرم اول، قالب: همان فونتی که امروز ttf یا woff است، در قالب woff2 با همان حروف، فشرده‌تر ذخیره می‌شود؛ مرورگرهای امروزی همگی از آن پشتیبانی می‌کنند و نسخه‌های قدیمی‌تر را به‌عنوان جایگزین در پشته می‌گذارید. تبدیل یک‌بار انجام می‌شود و خروجی‌اش جایگزین فایل‌های فعلی می‌شود — بدون هیچ تغییری در ظاهر. اهرم دوم، زیرمجموعه‌سازی است: فایل فونت شما گلیف‌های زیادی دارد که هرگز استفاده نمی‌شود — سایر زبان‌ها، نمادها و کاراکترهای تزئینی. با ابزارهای زیرمجموعه‌سازی، فقط مجموعهٔ لازم را نگه دارید: حروف فارسی، لاتین پایه و اعداد.

دو احتیاط در زیرمجموعه‌سازی فارسی لازم است. اول، نیم‌فاصله و اتصال حروف را با متن واقعی تست کنید — جمله‌های نمونهٔ نویسندگان خودتان، نه متن پیش‌فرض ابزار؛ اگر نویسه‌ای از دست رفته باشد، همان‌جا دیده می‌شود. دوم، زیرمجموعهٔ فارسی و لاتین را جدا بسازید تا صفحه‌های لاتین‌محور — آدرس ایمیل، کد، اعداد انگلیسی — فایل سنگین فارسی را نخواهند. در چک‌لیست زیر، حالت نهایی سالم خلاصه شده است؛ بعد از اعمال، همان پروتکل بخش ششم اثرش را نشان می‌دهد.

قدم سوم؛ font-display و پایان متن نامرئی

قدم سوم، رفتار مرورگر در لحظهٔ رسیدن فونت است و با ویژگی font-display تعیین می‌شود. چهار رفتار اصلی را بشناسید: حالت پیش‌فرض سخت‌گیرانه متن را تا رسیدن فونت نامرئی نگه می‌دارد؛ حالت تعویض (swap) بلافاصله با فونت جایگزین متن را نشان می‌دهد و وقتی وب‌فونت رسید، جایگزینش می‌کند؛ حالت fallback پنجرهٔ کوتاهی برای فونت اصلی می‌گذارد و بعد بی‌سروصدا به فال‌بک می‌رود؛ و حالت optional فونت را فقط وقتی استفاده می‌کند که خیلی سریع رسیده باشد. هر حالت، معامله‌ای است میان «ظاهر برند» و «متن همیشه دیده‌شده».

پیش‌فرض ما برای فونت متنِ بدنه، تعویض است: کاربر هیچ لحظه‌ای با صفحهٔ بی‌متن تنها نمی‌ماند و فونت وقتی رسید، تجربه کامل می‌شود — تنها هزینه‌اش یک لحظه تعویض کوتاه است که با فال‌بک هم‌شکل (قدم بعد) تقریباً نامحسوس می‌شود. برای فونت عنوان که بار هویتی بیشتری دارد می‌توانید حالت‌های محتاط‌تر را امتحان کنید، اما به تجربهٔ ما حتی آن‌جا، متنِ دیده‌شده با فونت نزدیک، بهتر از متنِ نامرئی با فونت اصلی است. بعد از تغییر، فقط یک استایل اعلام‌شده را تغییر دهید و در پروتکل سنجش ثبتش کنید؛ چند تغییر هم‌زمان، نتیجه را ناخوانا می‌کند.

قدم چهارم؛ پشتهٔ جایگزین سیستمی

قدم چهارم، پشتهٔ فونت است — همان فهرستی که بعد از نام وب‌فونت می‌نویسید و وقتی فونت اصلی نیامده یا در حال تعویض است، حکم می‌کند کاربر چه ببیند. شکل درست پشته برای سایت فارسی این است: وب‌فونت شما اول، بعد یک فونت سیستم فارسی‌پسندِ در دسترس — فونت‌هایی مثل Tahoma و Verdana و سنس‌های سیستمی که حروف فارسی را کامل رندر می‌کنند — و در انتها فونت عمومی بدون‌سریف. با این شکل، هیچ حالتی از کاربر متنِ نامرئی یا فونت پیش‌فرض بی‌ریش نمی‌بیند؛ بدترین حالت، فونتی سیستمی است که درست و بلافاصله نمایش داده می‌شود.

کیفیت پشته را با دو آزمون بسنجید. آزمون اول، هم‌اندازگی: فونت جایگزین نباید چیدمان را بپراند؛ ارتفاع خط و اندازه‌ها را طوری تنظیم کنید که با فونت جایگزین هم صفحه سالم بماند — ابزارهای تطبیق ابعاد فونت جایگزین در CSS همین کار را دقیق‌تر می‌کنند. آزمون دوم، شبیه‌سازی قطع: فایل فونت را موقتاً از بارگذاری محروم کنید و صفحه را با چشم کاربر ببینید؛ اگر متن خوانا و چیدمان سر جایش بود، پشته سالم است. همین شبیه‌سازی را بعد از هر تغییر فونت تکرار کنید — پروتکل بخش بعد آن را منظم می‌کند.

پروتکل سنجش؛ قبل و بعد، تکرارشدنی

بدون سنجش منظم، «سبک‌شدن فونت» فقط حس است. پروتکل ما شش قدم دارد و هر بار که فونتی را تغییر می‌دهید تکرار می‌شود: یک صفحهٔ نمونهٔ واقعی — پربار از متن و عنوان، نه صفحهٔ خالی — انتخاب کنید؛ پروفایل ثابت بسنجش تعریف کنید: دستگاه، مرورگر و نوع شبکه؛ قبل از تغییر دو سه بار بسنجید و عدد و اسکرین‌شات ثبت کنید؛ فقط یک تغییر را اعمال کنید — میزبانی، یا قالب، یا font-display، یا پشته؛ همان پروفایل را دوباره دو سه بار بسنجید؛ و هر دو سمت را در یک برگه کنار هم بنویسید. روش کامل ابزارها و خواندن نتایج را آموزش گام‌به‌گام تست سرعت سایت پوشش داده و این پروتکل همان را به سطح «تغییر فونت» می‌آورد.

در خواندن نتیجه، دو چیز را جدی بگیرید. اول، روند به‌جای یک عدد: میانگین چند بارِ سنجش در پروفایل ثابت، داور است؛ یک اجرای خوش‌شانس سند نیست. دوم، نگاه به رندر متن، نه فقط حجم: سؤال درست این نیست که چند کیلوبایت کم شد؛ این است که کاربر متن را چند لحظه زودتر خوانا دید و آیا لحظهٔ تعویض فونت محسوس بود. اسکرین‌شات‌های قبل و بعد از خودِ صفحه، همان چیزی است که این پاسخ را می‌دهد؛ عددِ حجم، فقط بخشی از تصویر است.

جمع‌بندی؛ چرخهٔ فصلی فونت

چهار قدم — میزبانی داخلی، woff2 و زیرمجموعه، font-display، پشتهٔ سالم — و یک پروتکل سنجش؛ مسیر کامل همین است و معمولاً در یک هفته بسته می‌شود. بعد از آن، فونت به چرخهٔ فصلی می‌رود: بازبینی وزن‌های استفاده‌نشده بعد از تغییر قالب، زیرمجموعهٔ تازه اگر برندینگ عوض شد، و تکرار پروتکل بعد از هر تغییر. فونت را مثل تصاویر به‌عنوان قلمی زنده ببینید که با هر بازطراحی باید دوباره وزن شود، نه فایلی که یک‌بار نصب شده و تا ابد می‌ماند.

و اگر زمان اجرای این چرخه را ندارید، خودکارسازی انتشار و نگهداری محتوا در قابلیت‌های پلتفرم بخشی از بار عملیاتی را از تیم برمی‌دارد و ممیزی رایگان دامنه نشان می‌دهد فونت و سایر اقلام سرعت، در صفحهٔ شما الان چه وضعیتی دارند. سنجهٔ پذیرش هم همان پروتکل است؛ فصلی یک‌بار تکرارش کنید و نتیجه را کنار گزارش سرعت بنویسید تا روند چندفصلی، سلامت فونت را مستند نگه دارد؛ نقطهٔ شروع را همان‌جا از داده بگیرید، نه از حس.

رصد ما، رشد شما.