وب هسته های حیاتی واقعاً مشکل شما نیستند؟

اگر در تلاش برای بهبود امتیازات Core Web Vital و کوتاه آمدن هستید ، تنها نیستید. شواهد حکایتی نشان می دهد که دستیابی به عملکرد بالای Core Web Vital دشوار است. دلیل آن اینست که ناشران و سئو در تلاشند چیزی را که از نظر فنی خراب نشده است برطرف کنند.

تغییر پارادایم در چگونگی توسعه سایت ها

ما در مراحل ابتدایی تغییر الگوی اصلی نحوه ایجاد صفحات وب هستیم. یک میزبان وب سریعتر مفید است اما مشکلات Core Web Vital را برطرف نمی کند.

Core Web Vital در پایین دست دستگاه همراهی که با سرعت 3G یا 4G باعث کاهش صفحات وب شما در تلفن همراه می شود ، محاسبه می شود. این همان جایی است که داده های Core Web Vital از آن سرچشمه می گیرد و اگر وب سایت سرور سریع در صورت کم شدن اتصال اینترنت به تلفن ، باعث کم شدن استفاده از وب سرور شود ، در آن مرحله کاربرد چندانی ندارد.

بهبود Core Web Vital کمتر در مورد میزبانی وب و بیشتر در مورد اصلاح کد است.

رفع آنچه شکسته نشده است

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

آنها برای بهبود امتیازات تجربه صفحه Google مجبور بودند نحوه مدیریت وردپرس با CSS و JavaScript را شخصی سازی کنند.

به عبارت دیگر ، در طراحی مجدد وب سایت خود برای کسب امتیاز خوب برای Core Web Vital ها ، WP Rocket مجبور بود وردپرس را به صورت سفارشی تنظیم کند ، تا به چیزی تبدیل شود که برای آن طراحی نشده است.

Core Web Vital-غیر دوستانه

استانداردهای Core Web Vital چیزی نیست که توسعه دهندگان وردپرس هنگام ایجاد وردپرس در ذهن داشته باشند. به همین دلیل تعبیه توییت ها در یک پست باعث تغییر تجمعی چیدمان می شود.

وردپرس و مضامین برای Google کدگذاری نمی کنند. آنها نیاز ناشران را کدگذاری می کنند که تا مه 2020 نیازی به ناشر نبود.

فقط وردپرس نیست. اکثر سیستم های مدیریت محتوای دیگر بهترین Core Web Vital ها را در خود ندارند.

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

Core Web Vital یک مشکل وردپرس نیست

Core Web Vital مجموعه ای از معیارها است که بطور مستقل توسط Google توسعه داده شده و ناشر و جامعه جستجوگرها را برای کار با آنها سوق می دهد.

وردپرس هیچ ارتباطی با آن نداشت. Core Web Vital در ماه مه سال 2020 ظاهر شد، ظاهرا بدون هیچ گونه هماهنگی یا مشورتی با اکوسیستم توسعه دهنده.

در سمت وردپرس ، توسعه به گونه ای پیش می رود که گویا Core Web Vital وجود ندارد. در حالی که در سمت ناشر و سئو هستند ، کاربران “وردپرس” وظیفه “رفع” وردپرس ، دروپال ، phpBB و غیره را بر عهده دارند.

در دنیای کامل ، کار ایجاد سیستمی که نیازهای کاربران را برطرف کند ، به عهده توسعه دهنده است. اما این اتفاق نمی افتد.

وردپرس حتی Core Web Vital را به عنوان یک مسئله وردپرس نمی داند.

وقتی کسی شروع به کار کرد موضوع پشتیبانی در انجمن های وردپرس در این باره به آنها گفته شد که در بخش پشتیبانی Google از آنها س askال کنند.

“شما باید در یک انجمن گوگل بپرسید ، زیرا وردپرس هیچ ارتباطی با این موضوع ندارد.”

ناشر و انجمن جستجوگرها با رعایت قوانین سازگار هستند

ناشران وردپرس در تلاشند تا وب سایت ها را با استانداردی مطابقت دهند که آن وب سایت ها هرگز برای مطابقت با آن طراحی نشده اند.

این دلیل این است که بسیاری از افراد با Core Web Vital ها دست و پنجه نرم می کنند. ناشران و سئوکاران تلاش زیادی برای حل مسئله ای دارند که به طور ایده آل باید در سطح کد رفع شود.

بهبود نمرات Core Web Vital می تواند احساس کند سعی در بهبود عملکرد یک هوندا سیویک به استانداردهای یک Chevy Corvette است.

توسعه دهندگان یک کوروت نساختند. آنها هوندا سیویک ساختند.

اما گوگل از رانندگان خواستار است (نه تولید کنندگان) عملکرد را به سطح Corvette ارتقا دهید. به نظر شما منصفانه است؟

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

مشکل انطباق نرم افزار با Core Web Vital ها در سطح کد وجود دارد ، نه در سطح کاربر.

پس چرا ناشران و جامعه جستجوگرها برای رفع مشکلاتی که فقط کاربران آن هستند سنگین می شوند؟

آیا گوگل مفید است؟

Google ابزارهای زیادی برای تشخیص مشکلات و مقالاتی عمیق در مورد چگونگی رفع این مشکلات برنامه نویسی ارائه می دهد.

اما اینها مشکلات کدگذاری است نه مشکلات کاربر.

مثالی از قطع ارتباط بین جامعه توسعه و Google مشکل Cumulative Layout Shift است ، جایی که صفحه وب هنگام بارگیری عناصر صفحه تغییر می کند و خود را مرتب می کند.

یک دلیل متداول برای تغییر آرایش تجمعی این است که تصاویر اندازه و عرض اعلام نشده دارند. Google راه حل های عجیب و غریب مانند استفاده از CSS برای سبک سازی تصاویر با استفاده از جعبه های نسبت ابعاد را توصیه می کند.

ناشر متوسط ​​و سئو احتمالاً نمی خواهد بفهمد که جعبه های نسبت ابعاد چیست و چگونه می توان نسبت ها را در سطح سایت محاسبه کرد به گونه ای که وب سایت را خراب نکند.

نگاهی بیاندازید در این و شرح جعبه های نسبت ابعادی که Google پیوند می دهد و ببینید آیا برای شما منطقی است:

“مربع های عالی و چیزهای 16: 9 عالی هستند ، اما مقادیر استفاده شده برای آنها فقط یک ریاضی ساده است. نسبت ابعادی می تواند هر چیزی باشد و معمولاً کاملاً خودسرانه است. یک فیلم یا تصویر را می توان در هر اندازه ای برش داد.

بنابراین چگونه می توانیم سطح بالشتک SVG 1127.34 × 591.44 SVG خود را تشخیص دهیم؟

یک راه استفاده از calc () است ، مانند این:

padding-top: calc (591.44 / 1127.34 * 100٪)؛ “

نیکی بخشنده!

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

اینها دلایلی است که WP Rocket مجبور به کاوش و ایجاد تغییراتی در سایت CSS و JavaScript شد.

به عنوان مثال ، وردپرس گوتنبرگ ، تمام CSS موجود را بارگیری می کند ، صرف نظر از اینکه آیا مورد نیاز است یا نه. بنابراین توسعه دهنده WP Rocket مجبور بود کد راه حلی را برای آن ارائه دهد.

این چگونه است WP Rocket توضیح داد آنچه آنها به عنوان بخشی از طراحی مجدد خود انجام دادند:

“… ما چندین بلوک را که استفاده نشده است منسوخ کردیم. ما یک سیستم enqueue سفارشی ایجاد کردیم تا CSS & JS بلوک بارگذاری شده را فقط در صورت لزوم داشته باشد. فقط چند دقیقه طول کشید تا این سیستم را توسعه دهیم.

همچنین تصمیم گرفتیم از پرونده CSS Gutenberg استفاده نکنیم. درعوض ، ما CSS مورد نیاز خود را به درون صفحه سبک خود ، در یک فایل اختصاصی CSS ، “مهاجرت” کردیم. این کلاهبرداری را انجام داد. “

بازنگری در مورد نحوه ایجاد سایت ها

درک مسئله Core Web Vital بسیار مهم است. گوگل خواستار آن است که ناشران و سئوکاران راه حل هایی را انتخاب کنند که جامعه توسعه CMS علاقه ای به پرداختن به آنها ندارد.

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

بیایید در مورد فونت ها صحبت کنیم.

مسدود کردن منابع شخص ثالث می تواند تأثیر منفی بر بزرگترین محتوای رنگ آمیزی بگذارد. یک گلوگاه رایج بارگیری قلم ها از یک سایت شخص ثالث مانند Google Fonts است.

تعدادی از ترفندها برای استفاده وجود دارد که ترکیبی از استفاده از ویژگی پیوند بارگیری و شاید برخی JavaScript و غیره است که روند بارگیری قلم های شخص ثالث Core Web Vital را دوستانه می کند.

اما آیا پشت سر گذاشتن آن قلم فانتزی سایت شما را می کشد؟

یک راه حل ساده که به امتیاز بهتر کمک می کند ، تغییر قلم وب سایت به قلم sans serif است که دستگاه های اپل ، ویندوز و اندروید از قبل در سیستم خود بارگیری کرده اند.

تغییر به یک قلم جذاب که در دستگاه تعبیه شده است به این معنی است که سایت دیگر برای بارگیری یک قلم فانتزی منتظر نمی ماند.

یک رویکرد می تواند چیزی مانند این باشد:

font-family: Helvetica, Tahoma, sans-serif;

اگر اندروید Helvetica یا Tahoma را از قبل در مرورگر بارگیری نکرده باشد ، دستگاه سایت را با استفاده از فونت Roboto نمایش می دهد.

عکس صفحه از نمونه فونت Roboto

برای افرادی که به استفاده از فونت های فانتزی عادت کرده اند ، استفاده از فونت های سیستم بسیار افراطی به نظر می رسد. اما این نمونه ای از انواع مصالحه هایی است که ممکن است ناشران وب انجام دهند ، به ویژه ناشرانی که در سطح رقابت بالایی قرار دارند.

این نوع تصمیم گیری برای یک سایت وابسته و متمرکز بر سرعت صفحه و تبدیلات کاری بی فایده است.

لحظه ای از انتقال

آنچه امروز اتفاق می افتد این است که ما در یک لحظه گذار زندگی می کنیم. اوضاع از نحوه انجام کارها در گذشته به نحوه توسعه دهندگان برای انجام کارها (خارج از محدوده) در آینده تغییر می کند.

توسعه دهندگان به تقاضای سایت های دوستانه تلفن همراه پاسخ دادند. به مرور ممکن است آنها به تقاضای سایتهایی که امتیاز خوبی برای Core Web Vital دارند ، پاسخ دهند.

نحوه طراحی سیستم ها ، الگوها و پلاگین های CMS پاسخگوی ناشران نیاز به توجه به Core Web Vital ها نیست.

در حال حاضر ، SEO فن آوری و جامعه توسعه دهندگان مجبورند “آنچه را که خراب نشده است” برطرف کنند تا بتوانند به ایده گوگل در مورد شکل ظاهری وب پایبند باشند.

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

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

اتفاقی که ممکن است بیفتد این است که ممکن است بعضی از افراد مفید باشند که تا آنجا که می توانند برطرف کنند و بقیه موارد را برای زمان وردپرس و سایر نرم افزارهای CMS بگذارند.