می دانستیم که مشکلی داریم.
در سال 2019 ، SitePoint امتیازهای Lighthouse Speed را کمتر از 10 در تلفن همراه و بین 20 تا 30 را در دسک تاپ دریافت می کرد.
تلاش های ما برای کنترل نفخ UX به دنبال یک فضای تجاری انتشاراتی که درست زمانی که ما به طور موقت وصل آخرین مورد را به پایان رساندیم ، نشت های جدیدی به وجود آورد ، در حال شکست بود. اعتماد ما به تبلیغات ، کنترل شده توسط اشخاص خارجی ، مانع اصلی در بهبود عملکرد سایت بود. رشد ترافیک ما به کاهش تبدیل شده بود.
در سایتی که مکانی برای مراجعه به افراد فراهم کرده و می توانند با بهترین روش ها کد نویسی را یاد بگیرند ، این ظاهر خوبی نبود. یا سایتی نبود که بتوانیم به آن افتخار کنیم.
برای بدتر کردن اوضاع ، تنگناهای عملیاتی بوجود آمده بود که سازگاری را به یک تجارت تدارکاتی روی حیله و تزویر تبدیل می کرد. تیم ما برای ایجاد تغییر در سایت تلاش می کرد: چندین سال که روی تجربه Premium خود متمرکز شده بودیم ، به یک توسعه دهنده با تجربه وردپرس و PHP محدود شدیم. برای آزمایش تغییرات کد ، تیم باید در صف منتظر بماند تا به سرور مرحله بندی ما دسترسی پیدا کند.
برای هرکسی انرژی بخش نبود و مطمئناً هم کارآمد نبود.
وقت آن رسیده بود که برخی تغییرات را اعمال کنیم ، و ما تصمیم گرفتیم تا به دنبال راه حلی باشیم. پس از تحقیقات زیاد ، تصمیم گرفتیم که گتسبی برای تیم ما بسیار مناسب خواهد بود. این به نقاط قوت استعداد ما کمک می کند ، به ما کمک می کند همه مواردی را که شناسایی کرده ایم حل کنیم و به ما امکان می دهد تا از WordPress برای backend استفاده کنیم تا فرایند تحریریه تغییر نکند.
چرا ما به گتسبی نقل مکان کردیم
نتیجه نهایی
در اوایل مراحل تحقیق ، گتسبی شروع به ظاهر شدن به عنوان یک پیشرو جدی کرد. SitePoint سایت کوچکی نیست ، بنابراین می دانستیم که فناوری انتخابی ما باید بتواند تقاضاهای بسیار شدید را برطرف کند. گتسبی همه جعبه های ما را بررسی کرد:
- ما می توانیم همه چیز را در آن کد کنیم عکس العمل نشان دهید، فنی است که هر یک از اعضای تیم front-end آن را می شناسند و روزانه از آن استفاده می کنند.
- گتسبی در هسته اصلی خود بسیار سریع عمل می کند – عملکرد اصلی این پروژه بود و ما می توانیم از یک پایه خوب شروع کنیم.
- کل سایت بصورت استاتیک ارائه می شود که برای سئو بسیار مناسب است.
- ما می توانیم آن را به عنوان یک پروژه جدید بسازیم ، و این هیچ نگرانی در مورد کد کد موجود نیست ، که مقدار زیادی کد قدیمی را با خود به همراه داشت.
- ما می توانیم از Gatsby Cloud استفاده کنیم ، به تیم این امکان را می دهد تا در هر زمان فقط با فشار دادن شعبه به GitHub بازخورد مربوط به ساخت را دریافت کند.
- حملات DDoS به وردپرس مشکلی برای ما ایجاد نمی کند ، زیرا قسمت جلویی کاملاً مستقل است.
CSS قابل نگهداری بیشتر با styled-components
از آنجایی که ما قصد داشتیم سایت را از ابتدا بازسازی کنیم ، قصد داشتیم همزمان تغییرات طراحی ایجاد کنیم. برای کمک به این کار تصمیم گرفتیم استفاده کنیم اجزای سبک.
styled-components باعث می شود که سبک طراحی سایت آسان نباشد و ما می دانیم وقتی می خواهیم سبک چیزی را تغییر دهیم کجا را جستجو کنیم – سبک همیشه با م componentلفه است.
چگونه ساخت آن اتفاق افتاد
ما با دنبال کردن اسناد اصلی گتسبی و ارسال پست های خود با gatsby-source-wordpress پلاگین
این یک آزمایش اولیه بزرگ برای ما بود: باید ببینیم که آیا یکنواخت است یا نه ممکن برای استفاده از گتسبی برای سایت ما.
پس از 20 سال وبلاگ نویسی ، بیش از 17000 پست منتشر شده داریم. ما می دانستیم که مدت زمان ساخت این کار طولانی خواهد بود ، اما باید می فهمیدیم که آیا گتسبی می تواند با چنین حجم عظیمی از محتوا کنار بیاید. همانطور که احتمالاً فهمیده اید ، این آزمون خبر خوبی را ارائه داده است: گتسبی کار می کند.
یک نکته سریع برای تیم های دیگر که با سایت های بزرگ کار می کنند: برای اینکه توسعه بهتر شود ، ما از محیط های مختلف برای جلوگیری از واکشی گتسبی استفاده کردیم همه از پست های سایت در حال توسعه است. چیزی کاملاً مشابه بارگیری مجدد داغ 60 دقیقه ای نیست تا پیشرفت کند داشته باشید.
if (hasNextPage && process.env.NODE_ENV != "development") {
return fetchPosts({ first: 100, after: endCursor });
}
از این مرحله ، با افزونه منبع وردپرس به محدودیت هایی برخوردیم. ما نتوانستیم تمام داده های مورد نیاز خود را بدست آوریم ، بنابراین به بخش افزونه وردپرس GraphQL.
ما از Yoast برای تنظیم فراداده خود برای سئو استفاده می کنیم و باید اطمینان حاصل کنیم که اطلاعات صحیح را به دست می آوریم. ما توانستیم این کار را با وردپرس GraphQL انجام دهیم. با انجام این روش ، تیم محتوا همچنان می تواند فراداده را به همان شیوه ویرایش کند ، و داده ها همچنان پویا بوده و از هر ساخت ساخته می شوند.
در طول ساخت ، سه یا چهار نفر در تیم مشغول کار بر روی بخشهایی از وبلاگ جدید هستیم. در گذشته ، اگر آنها می خواستند بازخورد بگیرند ، باید به سرور staging ما فشار بیاورند و مطمئن شوند هیچ کس از آن استفاده نمی کند.
ما دریافتیم که Gatsby Cloud یک راه حل عالی برای این مسئله است. اکنون وقتی کسی به یک شعبه در GitHub فشار می آورد ، ایجاد یک ساختار در Gatsby Cloud همراه با پیوند پیش نمایش می کند. توسعه دهندگان ما می توانند این پیوند را به اشتراک بگذارند و آزمایش و بازخورد فوری را بسیار م testingثرتر از قبل دریافت کنند.
این چرخه بازخورد سریعتر حضور چندین نفر در تیم را که روی ساخت کار می کنند آسان کرده و به یک گلوگاه اصلی پایان می دهد.
راه اندازی سرگرم کننده روز
در روز بزرگ ، سایت جدید را راه اندازی کردیم و آزمایشات اولیه خود را انجام دادیم. وبلاگ جدید بود پرواز کردن – بارگیری هر صفحه بلافاصله احساس می شود.
در SitePoint Premium با مشکلاتی روبرو شدیم که شروع به کندی و حتی خرابی می کند. مقصر عنصر جدیدی در صفحات وبلاگ بود که کتابهای مشهوری را که مردم در حال حاضر می خوانند ، کشانده است. این کار را از طریق تماس API در سمت مشتری انجام می دهد و مدیریت Premium به دلیل میزان ترافیکی که از طرف وبلاگ به دست می آوریم بسیار زیاد بود.
ما به سرعت برخی از حافظه پنهان صفحه را به API اضافه کردیم تا مشکلات را به طور موقت حل کنیم. فهمیدیم که این کار را اشتباه انجام داده ایم – باید در زمان ساخت این داده ها را تهیه می کردیم ، به طوری که وقتی صفحه را به کاربر ارائه می دهیم ، کتابهای مشهور بارگیری می شوند.
این تغییر ذهنیت اصلی است که شما باید هنگام استفاده از گتسبی انجام دهید: هر داده ای که می توانید در زمان ساخت بدست آورید باید در زمان ساخت دریافت شود. فقط درصورت نیاز به داده های مستقیم باید از تماس های API سمت مشتری استفاده کنید.
وقتی خواستار تماس API شدیم که در حین ساخت اتفاق می افتد ، بارگذاری یک صفحه وبلاگ حتی سریعتر بود – و Premium خرابی را متوقف کرد.
آنچه هنوز باید حل کنیم
اگرچه دشوار است بیش از حد بیان کنیم که امروز تجربه کاربری در سایت بهتر است ، هنوز چند نکته درد وجود دارد که باید آنها را حل کنیم.
اگر مقاله جدیدی منتشر شود ، یا اگر محتوایی به روز شود – همانطور که در روز چند بار انجام می شود – ما باید قبل از نمایش این تغییرات ، ساخت Gatsby را دوباره اجرا کنیم.
راه حل ما برای آن در حال حاضر یک کار ساده cron است که در زمان های از قبل تعیین شده در طول یک روز اجرا می شود. راه حل طولانی مدت این مسئله این است که یک وب وب به دکمه انتشار و به روزرسانی وردپرس اضافه کنید ، به طوری که پس از فشار دادن ، ساخت جدید ایجاد می شود.
ما همچنین باید ساخت های افزایشی را اجرا کنیم. در حال حاضر ، کل سایت هر بار باید دوباره ساخته شود و با توجه به بایگانی محتوای ما ، این ممکن است مدتی طول بکشد. گتسبی به محض پخش مستقیم ساخت های افزایشی را معرفی کرد و ما در حال پیاده سازی این مورد در سایت خود هستیم. اگر تنها چیزی که تغییر کرده است محتوا باشد ، سرعت ساخت ما بسیار سریعتر خواهد بود.
نمره سرعت ما هنوز در جایی که می خواهیم نیست. در حالی که سایت از نظر ذهنی بسیار سریع احساس می شود ، ما هنوز در Lighthouse نمره مداومی کسب نمی کنیم. ما می خواهیم موبایل و دسک تاپ را برای داشتن تجربه بهینه کاربر و سئو به منطقه سبز (امتیازات بیش از 90) وارد کنیم.
آیا ما دوباره این کار را خواهیم کرد؟
راه اندازی این نوع به طور معمول یک رویداد کاملاً اعصاب خردکن است و در روز راه اندازی کار زیادی از تیم می گیرد.
با استفاده از گتسبی ، راه اندازی ما واقعاً آسان بود. ما فقط مجبور شدیم وردپرس را به یک دامنه جدید منتقل کنیم و sitepoint.com را به نسخه گتسبی سایت نشان دهیم.
سپس عقب نشستیم و اعداد را تماشا کردیم تا ببینیم چه اتفاقی برای ترافیک ما افتاده است. در عرض چند روز ، داده ها شروع به ورود کردند و ما شاهد افزایش 15 درصدی ترافیک بودیم. معیارهای تعامل کاربر در همه موارد بالا بود.
فهمیدن اینکه چرا این عوارض بسیار فوری بوده دشوار نیست. ما SEO بهتری را در صفحات HTML و CSS استاتیک اجرا می کردیم ، و بهبود سریع سرعت با انتقال به گتسبی امکان پذیر بود.
از زمانی که ما این حرکت را انجام داده ایم ، امتیازات سرعت Lighthouse خود را از 6-15 در موبایل به محدوده 50-60 و از 30s در دسک تاپ به 70 رسانده ایم. ما می خواستیم اطمینان حاصل کنیم که سرعت با این تغییر در ذهن ما باقی مانده است ، بنابراین ما از ابزاری عالی به نام استفاده می کنیم کالیبر که هر روز تستهای سرعت را روی تعدادی از صفحات برتر اجرا می کند و ما را از امتیازات آگاه می کند. ما از این ابزار برای بهبود نمره خود استفاده می کنیم ، بنابراین امیدوارم ظرف سه ماه که همه چیز را برای باقی ماندن در محدوده 90+ بدست آوریم مقاله دیگری برای شما داشته باشیم.
این تیم کار در گتسبی را دوست دارد. پایگاه کد وبلاگ چیزی بود که هیچ کس نمی خواست روی آن کار کند. اکنون ، همه به لطف تجربه عالی توسعه دهنده می خواهند آن کارت ها را بگیرند.
اگر شما منتظر یک حرکت به گتسبی بوده اید و فکر می کنید آیا برای زمان نخست آماده است ، توصیه ما را بپذیرید – ارزش تعویض آن را دارد.
