Chrome Dev Insider: مقیاس عملکرد با اکوسیستم چارچوب

پل کینلان

من Paul Kinlan هستم و روابط توسعه دهندگان را برای Chrome رهبری می کنم. به عنوان بخشی از کارم، با تیمی از حامیان وب پرشور کار می‌کنم که وظیفه دارند دیدگاه توسعه‌دهندگان دنیای واقعی را به تیم‌های مهندسی و محصول خود بیاورند، با معیار ستاره شمالی برای بهبود رضایت توسعه‌دهنده .

ما می دانیم که "رضایت" یک معیار بلندپروازانه و ذهنی برای ردیابی و بهبود است، بنابراین به طور مداوم در مورد اینکه چگونه می توانیم در عین تمرکز بر نیازهای برنامه نویس تأثیر بگذاریم، تکرار می کنیم. یک اصل راهنما که پیروی از آن را مفید دانستیم این است: " با توسعه دهندگان در جایی که هستند ملاقات کنید ". یک مطالعه اخیر Stack Overflow نشان داد که 75٪ از توسعه دهندگان گزارش می دهند که از چارچوب ها یا نوعی انتزاع استفاده می کنند . بنابراین، از خود می‌پرسیدیم که چگونه به توسعه‌دهندگانی که قبلاً در مورد پشته فناوری خود تصمیم‌گیری کرده‌اند یا هیچ کنترلی بر آن ندارند، بهترین خدمات را ارائه می‌کنیم؟ چگونه آنها را بدون اضافه کردن سربار بیشتر بهره وری کنیم؟

تیم کوچکی در اینجا در Chrome روی پروژه‌ای به نام Aurora کار می‌کنند، با هدف کار با انتزاع‌های شخص ثالث از پلتفرم وب مانند چارچوب‌ها و کتابخانه‌ها. هدف آنها کمک به آوردن دستاوردهای عملکرد مستقیم به این انتزاعات است، به جای اینکه بار را بر دوش مشتریان خود - توسعه دهندگان وب بیاندازند.

برای نسخه سوم Chrome Dev Insider، با آدی عثمانی ، کارا اریکسون ، و حسین جیرده از تیم Project Aurora صحبت کردم تا درباره نحوه برخورد آنها با این پروژه و آنچه در انتظارشان است بیشتر بدانم.

Scoop Insider: کار با چارچوب های شخص ثالث

بیایید با پیدایش این پروژه شروع کنیم. چطوری این پیش آمد؟

Addy: Aurora با یک ایده ساده شروع کرد: بیایید توسعه دهندگان را در جایی که هستند ملاقات کنیم و به آنها کمک کنیم به جایی که باید برسند. برای مثال، به پشته فناوری محبوبی که انتخاب کرده‌اند کمک کنید تا عملکرد را بهبود بخشد. بسیاری از توسعه‌دهندگان اپلیکیشن‌ها این روزها با استفاده از React، Vue یا Angular - یا فریم‌ورک‌های متا* مانند Next.js و Nuxt - (و البته بسیاری دیگر... Svelte، Lit، Preact، Astro می‌سازند. فهرست ادامه دارد! ). به‌جای اینکه انتظار داشته باشیم این توسعه‌دهندگان به متخصصان عمیقی تبدیل شوند (مثلاً در عملکرد)، می‌توانیم با استفاده از بهترین روش‌ها به‌طور پیش‌فرض در این پشته‌ها، اطمینان حاصل کنیم که در گودال موفقیت قرار می‌گیرند. به این ترتیب، سایت‌های با کیفیت بهتر یک اثر جانبی ساختن فقط برای وب هستند.

Aurora چند فریم ورک و متا فریمورک پرکاربرد را برای مشارکت انتخاب می‌کند، ما آموخته‌های خود را مستند می‌کنیم (مانند نحوه ایجاد یک مولفه تصویر خوب)، به طوری که دیگران بتوانند سریعاً آن را دنبال کنند و سعی کنند از طریق سایر چارچوب‌ها و ابزارها از طریق کروم مقیاس بگیرند. صندوق چارچوب. در حالی که بهبود کیفیت تجربیات وب از طریق مرورگر امکان پذیر است، ما معتقدیم که این هدف می تواند (در برخی موارد) از طریق چارچوب ها نیز انجام شود. ما امیدواریم که این به ما در رسیدن به اهداف ما برای یک وب با کیفیت بالاتر برای همه کمک کند.

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

بنابراین فکر ما این است که اگر توسعه‌دهندگان زمان محدودی برای اختصاص دادن به عملکرد دارند، بیایید ساختن یک برنامه کاربردی را برای آنها آسان‌تر (و سریع‌تر) کنیم. اگر با چارچوب‌های وب محبوب شریک شویم، در لایه درستی از انتزاع هستیم تا تجربه توسعه‌دهنده را از طریق مؤلفه‌های سطح بالاتر، هشدارهای انطباق، و غیره بهبود دهیم. هرکسی که از آن ابزارهای محبوب استفاده کند به این مزایا دسترسی خواهد داشت. و از نظر تئوری، اگر توصیه‌های توصیه‌شده تغییر کند، می‌توانیم اجزای خود را در زیر کاپوت به‌روزرسانی کنیم و توسعه‌دهندگان نگران به روز ماندن نباشند.

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

اگر درست متوجه شده باشم، شما یک تیم از چه چیزی هستید، شش مهندس؟ شرط می بندم که نمی توانید با هر چارچوب یا کتابخانه ممکنی کار کنید. بنابراین چگونه انتخاب می کنید که با چه کسی کار کنید؟ و آنها چه کسانی هستند؟

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

به عنوان مثال، چارچوب‌های وب (Next.js، Nuxt.js، و تا حدی Angular) سعی می‌کنند نظرات و پیش‌فرض‌های بیشتری را نسبت به راه‌حل‌های دستی‌تر ایجاد کنند. این یکی از دلایلی است که ما دوست داریم با آنها کار کنیم! داشتن پیش‌فرض‌های قوی‌تر برای نحوه بارگیری تصاویر، فونت‌ها و اسکریپت‌ها برای Core Web Vitals بهتر در این مدل‌ها منطقی است.

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

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

برای مثال، اگر به تنهایی به محبوبیت نگاه کنیم، React، Vue و Angular «سه بزرگ» هستند که باید در نظر گرفته شوند. اما ما بیشتر با Next.js، Nuxt و Angular کار می کنیم. این به این دلیل است که کتابخانه‌های View مانند React و Vue بیشتر بر روی رندر تمرکز می‌کنند، بنابراین ساختن مستقیم همه ویژگی‌هایی که می‌خواهیم در آنها غیرممکن است. بنابراین ما بیشتر با متا فریمورک‌هایی که در بالای آنها ساخته شده‌اند کار می‌کنیم: Next.js و Nuxt. در این سطح از انتزاع، ما می توانیم اجزای داخلی ایجاد کنیم. آنها همچنین دارای سرورهای داخلی هستند، بنابراین ما می توانیم بهینه سازی سمت سرور را در نظر بگیریم.

ممکن است متوجه شوید که Angular در آن لیست مشارکت های عمیق قرار داشت، اما این یک متا چارچوب نیست. Angular یک مورد خاص است زیرا بسیار محبوب است، اما متا فریمورک مکملی مانند React و Vue ندارد. بنابراین ما مستقیماً با آنها کار می کنیم و در صورت امکان از طریق CLI آنها به ویژگی ها کمک می کنیم.

و شایان ذکر است که ما چندین رابطه در حال انجام با پروژه‌های دیگری مانند گتسبی داریم که در آن به طور منظم در طراحی همگام‌سازی می‌کنیم اما به طور فعال کد را ارائه نمی‌کنیم.

پس این در عمل چگونه به نظر می رسد؟ رویکرد شما برای حل این مشکل چه بود؟

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

برای ما واقعاً مهم است که تأیید کنیم تأثیر عملکرد همان چیزی است که پیش‌بینی کرده بودیم، بنابراین با شرکت‌های خارجی نیز برای انجام آزمایش عملکرد در تولید کار می‌کنیم. اگر نتایج دلگرم‌کننده باشد، به این ویژگی کمک می‌کنیم تا به "پایدار" برسد و به طور بالقوه آن را به صورت پیش‌فرض تبدیل کنیم.

همه اینها به این آسانی که شما آن را به صدا در می آورید نمی تواند باشد. برخی از چالش ها یا آموخته هایی که تاکنون داشته اید چه بوده است؟

حسین: یکی از چیزهای مهمی که ما سعی می‌کنیم به بهترین شکل ممکن از آن استفاده کنیم، مشارکت در مخازن منبع باز محبوب است که اولویت‌های رقیب زیادی دارند. فقط به این دلیل که ما یک تیم Google هستیم لزوماً به این معنی نیست که ویژگی‌های ما در اولویت قرار می‌گیرند، بنابراین ما تمام تلاش خود را می‌کنیم تا با فرآیند معمولی پیشنهاد و ارسال ویژگی‌های جدید بدون زیر پا گذاشتن انگشتان کسی هماهنگ شویم. ما بسیار خوش شانس بوده ایم که با نگهدارنده های گیرنده در اکوسیستم های Next.js، Nuxt و Angular کار کرده ایم. ما سپاسگزاریم که آنها برای گوش دادن به نگرانی های ما در مورد اکوسیستم وب و مایل به همکاری با ما به روش های مختلف هستند.

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

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

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

در ادامه، روی چه نوع بهینه سازی هایی تمرکز کرده اید؟

حسین: پس از تجزیه و تحلیل هزاران برنامه، متوجه شدیم که بزرگترین مشکلات عملکرد معمولاً به دلیل وجود الگوهای ضد الگو در کد برنامه است تا خود چارچوب. به عنوان مثال، ارسال تصاویر بزرگ غیرضروری، بارگیری فونت های سفارشی خیلی دیر، واکشی بیش از حد درخواست های شخص ثالث که رشته اصلی را مسدود می کند، و عدم رسیدگی به این که چگونه محتوای ناهمزمان می تواند باعث جابجایی چیزهای دیگر در صفحه شود. همه این‌ها مسائلی هستند که صرف‌نظر از ابزاری که استفاده می‌کنید ممکن است به وجود بیایند، بنابراین ما فکر کردیم که آیا می‌توانیم برخی بهینه‌سازی‌های پیش‌فرض را بسازیم که به خوبی از عهده آن‌ها برآیند، اما با یک تجربه توسعه‌دهنده منظم که به خوبی در چارچوب ابزار آنها قرار می‌گیرد؟

با این تفکر، ما ارسال کرده ایم:

کار ما الهام بخش دیگر چارچوب ها و ابزارها برای پیاده سازی بهینه سازی های مشابه است. این شامل، اما محدود به موارد زیر نیست:

آیا می توانید برخی از نتایج مثبت کار خود را با برخی از این بازیکنان در میان بگذارید؟

حسین: بسیاری از سایت‌ها به دلیل بهینه‌سازی‌هایی که ما ارسال کرده‌ایم، بهبود عملکرد داشته‌اند. یکی از نمونه های مورد علاقه من Leboncoin است که LCP خود را از 2.4 به 1.7s پس از تغییر به مولفه تصویر Next.js کاهش داد . در حال حاضر تعداد بسیار بیشتری در مرحله آزمایش و آزمایش وجود دارد و ما به اشتراک گذاری آموخته ها و برنده های آن ها در اینجا ادامه خواهیم داد.

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

Addy: بسیاری از بهینه‌سازی‌های عملکردی که Aurora با آنها همکاری می‌کند، می‌توانند توسط هر چارچوبی تکرار شوند. برای مثال، به تلاش‌های مؤلفه تصویر یا اسکریپت نگاهی بیندازید، آنها اغلب مجموعه‌ای از بهترین شیوه‌های موجود را کدگذاری می‌کنند. ما سعی می کنیم "چگونگی" ساخت چنین اجزایی و شکل ظاهری آنها را در هر چارچوب مستند کنیم . امیدوارم این شروع خوبی برای کپی کردن ایده باشد.

ما موفقیت های خوبی را با گرفتن آموخته های یک اکوسیستم (مثلاً React و Next.js) و آوردن آنها به سایرین مشاهده کرده ایم. به عنوان مثال، دستورالعمل جدید تصویر زاویه‌ای (ساخته شده بر روی آموخته‌های ما در ساخت مؤلفه تصویر Next.js) یا گتسبی رویکرد ما را برای تکه‌سازی جاوا اسکریپت دانه‌ای ارسال می‌کند.

در عین حال، می‌دانیم که هر چارچوبی پهنای باند یا بودجه لازم برای مشارکت‌کنندگان برای ایجاد ویژگی‌های عملکرد مشابه یا سرمایه‌گذاری در بهینه‌سازی‌های دیگری را که معتقدند برای کاربرانشان مهم است، ندارند. صندوق Chrome Web Frameworks راهی برای حمایت مالی از کار عملکرد در اکوسیستم جاوا اسکریپت است تا پروژه‌ها بتوانند به مشارکت‌کنندگان خود پول پرداخت کنند و کار عملکرد را در اکوسیستم گسترش دهیم.

بنابراین نقشه راه پیش رو برای تیم شما چیست؟

کارا: ما پروژه های هیجان انگیز زیادی در پیش داریم! برخی از نکات برجسته:

  • کاهش CLS مرتبط با فونت: زمانی که یک فونت وب بارگذاری می شود و جایگزین فونت برگشتی می شود، مشاهده تغییر طرح نسبتاً معمول است. ما در حال بررسی استفاده از لغو متریک فونت و ویژگی "size-adjust" برای کاهش CLS مرتبط با فونت به طور پیش فرض در Next.js هستیم. ما همچنین با تیم Nuxt در این مورد مشورت کرده‌ایم و قصد داریم این ایده را در سال آینده به چارچوب‌های بیشتری گسترش دهیم.
  • اشکال زدایی INP: اکنون که معیار Interaction to Next Paint (INP) منتشر شده است، ما در حال کار با چارچوب هایی هستیم تا شایع ترین علل ریشه ای مشکلات INP را برای جوامع آنها بررسی کنیم و راه حل هایی را پیشنهاد کنیم. ما در این زمینه با Angular همکاری نزدیکی داشته ایم و امیدواریم به زودی نتایجی برای به اشتراک گذاشتن داشته باشیم!
  • بهینه سازی اسکریپت های 3P رایج: بارگیری اسکریپت های شخص ثالث در زمان نامناسب می تواند تأثیر منفی قابل توجهی بر عملکرد داشته باشد. از آنجایی که چند 3P وجود دارد که بسیار رایج هستند، ما به دنبال این هستیم که آیا می‌توانیم برخی از wrapper‌ها را برای آنها ارائه دهیم تا مطمئن شویم که آنها به‌طور بهینه با فریم‌ورک‌ها بارگذاری می‌شوند و رشته اصلی را مسدود نمی‌کنند. ما از مؤلفه اسکریپت Next.js به عنوان نقطه شروع برای این تحقیق استفاده می کنیم.

توسعه دهندگان می توانند پیشرفت ما را در این سایت دنبال کنند.

در اخبار

قبل از اینکه امضا کنم، می‌خواستم چند به‌روزرسانی جالب از دنیای فریم‌ورک‌ها را که در گوگل اتفاق می‌افتد، در اختیارتان بگذارم.

در ماه ژوئیه، تیم Chrome آخرین دور بودجه 500 هزار دلاری را برای صندوق Frameworks and tools اعلام کرد که بر تامین مالی پروژه‌هایی متمرکز است که هدفشان کمک به بهبود عملکرد، تجربه کاربر و تجربه توسعه‌دهنده در وب است. بودجه آینده پروژه های جدید را در نظر می گیرد، بنابراین به یاد داشته باشید که درخواست خود را ارسال کنید .

و البته، هزاران چیز شگفت انگیز نیز در جامعه رخ می دهد. این اکوسیستم با چارچوب‌های جدیدی مانند Deno's Fresh و تجربیات عالی مانند آموزش نصب Svelte که نه تنها یک نسخه آزمایشی درون مرورگر است، از Web Container API برای اجرای Node.js به‌صورت بومی در مرورگر نیز استفاده می‌کند. خیلی چیزهای خوب!

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

تا اینسایدر بعدی، هویل فاور.

نظر شما در مورد این نسخه از Chrome Dev Insider چیست؟ بازخورد خود را به اشتراک بگذارید .