آموزش اندازه گیری سرعت سایت

با چه چیزی اندازه بگیرید، و چرا یک بار کافی است

سه اسم را زیاد می شنوید و هر سه یک چیز نیستند. Lighthouse موتور تست است که صفحه را در شرایط شبیه سازی شده باز می کند و گزارش می سازد. PageSpeed Insights سرویسی است که همان موتور را برای شما اجرا می کند و اگر داده واقعی کاربران آن صفحه موجود باشد، آن را هم کنارش می گذارد. CrUX یا گزارش تجربه کاربری کروم همان داده واقعی است، و گزارش Core Web Vitals در سرچ کنسول هم از همین سرچشمه می آید.

نکته ای که خیلی کم گفته می شود و کار را کوتاه می کند: یک درخواست به API خود PageSpeed هر دو را با هم برمی گرداند. در پاسخ، بخش lighthouseResult عدد آزمایشگاهی است و بخش loadingExperience داده میدانی. لازم نیست از دو جا دو گزارش بگیرید.

و همان پاسخ حقیقت سومی را هم لو می دهد: بخش داده میدانی ممکن است اصلا در پاسخ نباشد. برای بیشتر سایت های فارسی همین حالت پیش می آید و خرابی نیست. تفاوت این دو داده و اینکه چرا صدک ۷۵ اهمیت دارد را در درس قبلی همین مسیر باز کرده ایم.

برای گرفتن گزارش، ساده ترین راه باز کردن سرویس PageSpeed در مرورگر است. اگر می خواهید همان را خودکار کنید، یک درخواست کافی است و از اینجا به بعد کار روی یک فایل JSON انجام می شود:

curl -s "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://example.com&strategy=mobile&category=performance&key=KEY" -o psi.json

یک هشدار که وقت شما را می خرد: این نشانی بدون کلید دیگر جواب نمی دهد. سهمیه روزانه بدون کلید صفر است و پاسخ ۴۲۹ برمی گردد. کلید از کنسول گوگل کلاد رایگان گرفته می شود و همین یک قلم، فرق بین گزارش واقعی Lighthouse و چیزی است که یک ابزار جایگزین به شما نشان می دهد.

فایل خامی که به دست می آید برای خواندن با چشم و برای چسباندن در یک پنجره چت خیلی بزرگ است. این دستور فقط همان چیزی را در می آورد که به کار می آید: نمره، چهار شاخص آزمایشگاهی، وضعیت داده میدانی، و فرصت های بالای صد میلی ثانیه. اگر بخش داده میدانی در پاسخ نبود، خودش field: none چاپ می کند و همین جواب مفیدی است.

python3 -c 'import json;d=json.load(open("psi.json"));l=d["lighthouseResult"];a=l["audits"];print("score",round(l["categories"]["performance"]["score"]*100));[print("lab",k,a[k]["displayValue"]) for k in ("first-contentful-paint","largest-contentful-paint","total-blocking-time","cumulative-layout-shift") if k in a];f=d.get("loadingExperience",{}).get("metrics",{});print("field: none") if not f else [print("field",k,v["percentile"],v["category"]) for k,v in f.items()];[print("fix",int(x["details"]["overallSavingsMs"]),"ms",x.get("title","")) for x in sorted(a.values(),key=lambda x:-x.get("details",{}).get("overallSavingsMs",0)) if x.get("details",{}).get("type")=="opportunity" and x["details"].get("overallSavingsMs",0)>100]'

نمره از چه ساخته شده، و چه چیزی در آن نیست

عدد بزرگ رنگی بالای گزارش، خودش یک اندازه گیری نیست. میانگین وزنی چند شاخص آزمایشگاهی است و مستندات Lighthouse وزن هر کدام را منتشر کرده: زمان مسدودی کل ۳۰٪، بزرگ ترین رسم محتوایی ۲۵٪، جابه جایی تجمعی چیدمان ۲۵٪، اولین رسم محتوایی ۱۰٪ و شاخص سرعت ۱۰٪. مستندات همان جا نوشته که وزن ها در طول زمان عوض شده اند، چون تیم Lighthouse مرتب تحقیق می کند که چه چیزی بیشتر روی تجربه ادراک شده اثر دارد.

حالا به آن فهرست دقیق نگاه کنید و ببینید چه چیزی در آن نیست: INP. یکی از سه شاخص Core Web Vitals هیچ سهمی در نمره ندارد. دلیلش هم منطقی است و نه توطئه: INP وقتی معنا پیدا می کند که کسی واقعا روی صفحه کلیک کند، و در یک اجرای خودکار کسی کلیک نمی کند. زمان مسدودی کل جانشین آزمایشگاهی آن است، نه خودش.

پیامد عملی این یک جمله است: می شود نمره صد گرفت و صفحه ای داشت که بعد از کلیک کاربر یک ثانیه هیچ کاری نمی کند. اگر ویجت چت و اسکریپت تبلیغاتی شما بعد از بارگذاری اولیه کار سنگین می کنند، نمره چیزی درباره اش نمی گوید.

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

چرا هر بار که تست می گیرید عدد فرق می کند

می گیرید ۶۸، دوباره می گیرید ۷۴، بار سوم ۶۱، و هیچ چیز سایت عوض نشده. این خرابی نیست و مستندات Lighthouse یک بخش کامل به همین اختصاص داده: بخش زیادی از این نوسان اصلا مال Lighthouse نیست، مال شرایطی است که تست در آن اجرا می شود. شبکه، بار لحظه ای سرور، حتی اینکه دستگاه تست در آن لحظه چقدر بیکار بوده.

از این یک قاعده کاری در می آید: یک اندازه گیری، اندازه گیری نیست. اگر می خواهید اثر یک تغییر را ببینید، سه بار قبل و سه بار بعد بگیرید و میانه را نگاه کنید، نه بهترین عدد را. آدم ها همیشه بهترین عدد قبل از تغییر و بهترین عدد بعد از تغییر را کنار هم می گذارند و به خودشان دروغ می گویند.

یک تله دیگر که کمتر کسی می شناسد: خیلی از ابزارهای سرعت، از جمله ابزار خود ما، نتیجه هر نشانی را مدتی کش می کنند. یعنی اگر یک دقیقه بعد دوباره تست بگیرید، ممکن است عددی که می بینید اصلا اجرای تازه ای نباشد. عدد ثابت لزوما یعنی سایت پایدار است؛ گاهی یعنی چیزی دوباره اجرا نشده. اگر دو تست پشت سر هم دقیقا یک عدد داد، به همین شک کنید.

از یک فهرست بلند به یک کار

گزارش که آمد، بخش فرصت های بهبود یک فهرست بلند به شما می دهد و کنار هر کدام تخمینی از زمانی که صرفه جویی می شود. اشتباه رایج این است که از بالای فهرست شروع کنید. آن فهرست بر اساس چیزی مرتب شده که ابزار می تواند اندازه بگیرد، نه بر اساس اینکه انجامش برای شما چقدر زحمت دارد.

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

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

و کار را با یک جمله تمام کنید و نه با یک گزارش: این ماه روی این یک چیز کار می کنیم، به این دلیل. اگر نتیجه اندازه گیری تان یک فهرست ده تایی شد، هنوز تصمیم نگرفته اید.

بعد از تعمیر، چه چیزی را دوباره اندازه بگیرید

تغییر که انجام شد، عدد آزمایشگاهی همان روز جواب می دهد. سه بار بگیرید و میانه را با میانه قبلی مقایسه کنید. اگر تفاوت کمتر از نوسان طبیعی تست بود، کار شما اثری نداشته که بشود اثباتش کرد و بهتر است همین را بپذیرید تا اینکه دنبال عددی بگردید که حرفتان را تایید کند.

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

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