وب وایتالها یک تحویلدادنی هستند، نه یک کار بعد از طراحی
بزرگترین دلیل کند بودن سایتها، تصمیمهای طراحی بدون محدودیت عملکرد است
بزرگترین عامل کندی سایتها، تصمیمهای طراحیای هستند که بدون درنظر گرفتن محدودیتهای عملکرد گرفته میشوند. ویدئوی هیرویی که هیچکس به آن ایراد نگرفت. ست فونتی با هفت وزن مختلف. لندینگپیجی با سی بخش و یک تصویر پارالاکس برای هر بخش.
هر تصمیم، دویست میلیثانیه اضافه میکند. تا زمانی که سایت به مرحلهٔ تولید برسد، صفحه پنج ثانیه هزینه دارد.
محدودیت، خودِ طراحی است
ما LCP، CLS و INP را بهعنوان محدودیتهای طراحی درنظر میگیریم — نه مشکلاتی که تیم فنی باید بعداً اصلاح کند. یعنی: قبل از اینکه طرح را به تیم توسعه تحویل بدهیم، دقیقاً میدانیم:
-
عنصر LCP چیست
-
وزنش چقدر است
-
و بودجهٔ عملکرد برای بقیهٔ صفحه چقدر است
این کار خستهکننده بهنظر میرسد. واقعاً هم خستهکننده است. اما همین دلیل است که سایتهای ما
روز اول لانچ، هر سه Web Vital را سبز تحویل میدهند نه اینکه بعد از لانچ، شش هفته زمان برای بهینهسازی لازم باشد.
جایگزینهایی که از همان ابتدا انجام میدهیم
-
ویدئوی هیرو → WebP متحرک با یکدهم حجم، همراه با یک تصویر پوستر بهعنوان LCP
-
انیمیشن ۶۰ فریم → انیمیشن CSS که به prefers-reduced-motion احترام میگذارد
-
فونت با وزنهای 100 تا 900 → فونت متغیر با دو محور وزن
-
بخشهای تصویری سنگین → تصاویر بالای صفحه preload، تصاویر پایین صفحه lazy-load با قابلیت بومی مرورگر
چرا این موضوع فراتر از Lighthouse اهمیت دارد
اهمیت این موضوع فقط این نیست که گوگل سایتهای سریع را در جستجو بهتر نمایش میدهد — این کار را میکند، اما دلیل مهمتر این است که سایتهای سریع تبدیل میکنند.
لندینگپیجی که سه ثانیه طول میکشد تا قابل تعامل شود، ۳۰٪ از ترافیک موبایل را قبل از اینکه کاربر حتی یک تصمیم دربارهٔ برند بگیرد، از دست میدهد.
زیباترین صفحهٔ طراحیشده اگر کند باشد، دیگر یک صفحهٔ زیبا نیست.
یک صفحهٔ کند است که هیچکس آن را ندید.
Web Vitals are a deliverable, not an afterthought
The single largest cause of slow websites is design choices made without performance constraints in the room. The hero
video that nobody flagged. The custom font set with seven weights. The thirty-section landing page with a parallax background image per section. Each decision adds two hundred milliseconds. By production, the page costs five seconds.
The constraint is the design
We treat Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint as design constraints not engineering remediations. That means: before we ship a design to the build team, we know what the LCP element will be, what its weight is, and what the budget is for everything else.
This sounds tedious. It is tedious. It is also the reason our shipped sites land in green for all three Core Web Vitals on launch day, instead of needing a six-week post-launch optimization sprint.
The substitutions we make on the way in
Hero video → animated WebP at 1/10 the file size, with a poster image as the LCP element. Sixty-fps motion → CSS-driven animation that respects prefers-reduced-motion. Font weight 100, 200, 300, 400, 500, 600, 700, 800, 900 → variable font axis with two ranges defined. Image-heavy editorial sections → above-the-fold images preloaded, below-the-fold lazy-loaded with native browser support, no external library required.
Why this matters beyond Lighthouse
The reason this matters is not that Google rewards fast sites in search. It does, but the bigger reason is that fast sites convert. A landing page that takes three seconds to interact loses 30% of mobile traffic before a single brand decision is made. The most beautifully designed page that is too slow to use is not a beautifully designed page. It is a slow page that nobody saw.