- صفحه اصلي
- انجمن
- ورود
- ثبت نام
- ليست کاربران
آیا واقعا به صفحات موبایل شتاب یافته گوگل (AMP) نیاز داریم؟
هم اکنون شما در تاپيک :آیا واقعا به صفحات موبایل شتاب یافته گوگل (AMP) نیاز داریم؟حضور داريد
آیا واقعا به صفحات موبایل شتاب یافته گوگل (AMP) نیاز داریم؟ تعداد بازديد : 460
|
|||
farsiseo![]() ![]() |
آیا واقعا به صفحات موبایل شتاب یافته گوگل (AMP) نیاز داریم؟
مقدمه گوگل به تازگی پروژه صفحات موبایل شتاب یافته (Accelerated Mobile Pages Project یا به اختصار AMP) را معرفی کرده است. هدف این پروژه افزایش قابل توجه عملکرد اینترنت در پلتفورم موبایل است، اما از یک دیدگاه متفاوت، می تواند با عدم پشتیبانی از استانداردی که بنیاد اینترنت است به قطعه قطعه شدن آن بینجامد. در کنار اعلام آغاز این پروژه، گوگل وبسایت پروژه AMP را نیز راه اندازی کرده است (که در ادامه به جزئیات آن هم خواهیم پرداخت). اما آیا این یک گام درست و رو به جلو است یا گام بلندی به عقب محسوب می شود؟ چرا گوگل فکر می کند که مرور اینترنت در موبایل به بازسازی نیاز دارد؟ توسعه برای موبایل از برخی جهات آسانتر است. گوشی های هوشمند در مقایسه با رایانه های رومیزی (PC) نسبتا جدید هستند، لذا مرورگرهای آنها خیلی بیشتر از مرورگرهای رایانه با استانداردها مطابقت می کند؛ و اغلب نیازی به کدنویسی برای نسخه های قدیمی مرورگرها -مانند کاری که باید برای اینترنت اکسپلورر رایانه های رومیزی انجام شود- نیست. بر طبق تجربه ، کاربران نیز در هنگامی که یک وبسایت کند است یا لود نمی شود، به جای سرزنش وبسایت، بیشتر موبایل خود را مقصر می دانند. علاوه بر این، روش فروش گوشی های موبایل که اغلب بر پایه قراردادهای دو ساله انجام می شود، کاربران را به ارتقای زودهنگام گوشی ترغیب می کند، در صورتی که در مورد رایانه چنین چیزی مصداق ندارد. بنابراین، به طور کلی و به صورت بالقوه، موبایل از رایانه به روز تر است (اگرچه این استدلال مخالفانی هم دارد، چرا که به این واقعیت توجه نمی کند که به روز رسانی بسیاری از سیستم های عامل موبایل به سرویس دهنده خط بستگی دارد، بنابراین تا زمانی که سرویس دهنده سیستم را به روز رسانی نکند، کاربر به ناچار باید از سیستم عامل قدیمی استفاده کند. علاوه بر این، دنیای خارج از جهان اول آنقدرها هم گل و بلبل نیست). اما از طرف دیگر، توسعه برای موبایل به مانند توسعه ای است که ده سال قبل برای رایانه ها انجام می گرفت: اندازه صفحه کوچک است، ورودی دشوار است (اغلب مبتنی بر صفحات لمسی و بدون صفحه کلید)، بهینه سازی سایت حافظه محدود است، تاخیر شبکه (network latency) افتضاح است، پهنای باند شبکه (علیرغم اینکه پتانسیل این را دارد که بهتر از پهن باند (broadband) باشد) به محض ازدحام افول می کند. برخی از این محدودیت ها قابل رفع نیستند. علیرغم افزایش اندازه و وضوح صفحات همزمان با پیشرفت تکنولوژی، اندازه صفحات به دلیل طبیعت موبایل و کمبود روش های جدید برای نمایش ورودی (به عنوان نمونه چیزی مانند عینک گوگل، اما به محبوبیت نرسید) محدود است و این همیشه یک مشکل باقی خواهد ماند. به همین ترتیب، روش های ورود اطلاعات نیز به دلیل اندازه فیزیکی دستگاه با محدودیت مواجه هستند و اگرچه روش های ورودی دیگر مانند استفاده از لمس رونق یافته است، هنوز هم یک چالش به حساب می آید. پردازنده، حافظه و پهنای باند شبکه افزایش خواهد یافت، اما بزرگترین مساله با تاخیر شبکه ارتباط دارد که باز هم به ذات این پلتفورم بر می گردد. HTTP/2 بسیار در این مورد سودمند ظاهر خواهد شد، اما برخی محدودیت های فیزیکی برای مساله تاخیر شبکه قابل رفع و رجوع نخواهد بود. این محدودیت ها در حالی وجود دارند که رَویه موجود نشان می دهد که وبسایت ها از نظر حجم و پیچیدگی در حال رشد هستند. بنابراین، ما در پلتفورم اصلی آینده اینترنت منابع کمتری در اختیار داریم، در حالیکه نیاز به منابع بیشتر روز به روز افزایش پیدا می کند. مطمئنا همه ما هنگامی که مجبور به استفاده از یک ارتباط کُند اینترنتی بوده ایم، از خیره شدن طولانی مدت به صفحه سفید موبایل رنج برده ایم. این واقعا عذاب آور است و من جداً امیدوارم که صاحبان وبسایتها به بهبود عملکرد وبسایتهای خود بیندیشند. یکی از دلایلی که من این وبسایت را راه اندازی کردم همین بود که به جای شِکوِه و ناله، کاری در این رابطه انجام دهم. گوگل برای ایجاد انگیزه برای توسعه وبسایت های بهتری برای پلتفورم موبایل، روش های دیگری را نیز امتحان کرده است. به روزرسانی اخیر الگوریتم موتور جستجوی گوگل موسوم به Mobilegeddon سر و صدای زیادی به پا کرد و اگرچه اثر آن هنوز در حال بحث و بررسی است، اما بسیاری را ترغیب کرد تا سایت های خود را با موبایل سازگار کنند. عملکرد سایت نیز یکی از عوامل دخیل در سئو است و گوگل نیز ابزارهای متعددی را برای بهبود عملکرد سایت ها ارائه می کند و اکنون راهکار دیگری نیز برای مدیریت این مساله ارائه شده است. AMP چیست؟ AMP چند چیز است: • اساساً اِعمال محدودیت بر بخش های کُند تکنولوژیهای اینترنت است. در حالیکه بیشتر تمرکز آن روی حذف مجازی جاوا اسکریپت قرار دارد، بخش هایی از HTML و CSS را نیز محدود می کند. • برای پرکردن جای خالی قابلیت های حذف شده به دلیل محدودیت های بالا، برای مولفه های اینترنتی محدود شده، تعیین شده و موثر از تگ های سفارشی استفاده می کند. • تبلیغات هنوز هم پشتیبانی می شود، اما باز هم به شکل محدود با استفاده از تگ های سفارشی . • گوگل قابلیت کش (cache) کردن را به صفحات AMP اضافه می کند تا به سرعت از سرور دریافت شوند. در عمل، این مزایای یک CDN را به رایگان در اختیار شما قرار می دهد. شما می توانید یا فقط از تکنولوژی AMP در صفحات خود استفاده کنید (در اینصورت باید چند تغییر کوچک در HTML خود ایجاد کنید)، یا اینکه یک نسخه سازگار با AMP از صفحات خود بسازید و در صفحات استاندارد خود به آن لینک بدهید (با استفاده از سینتکس در صفحه اصلی). جزئیات بیشتر در صفحه گیت هاب AMP در دسترس علاقمندان قرار دارد. AMP عمدتا برای صفحات استاتیک در نظر گرفته شده است؛ مقالات خبری، وبلاگ ها و امثال آنها. نرم افزارهای پیشرفته تحت وب برای AMP مناسب نبوده و در آن کار نخواهند کرد، درحالیکه اینها صفحاتی هستند که بیشترین مشکل را با پلتفورم موبایل دارند. جایگزینهای AMP AMP عمدتا به عنوان یک واکنش به نمونه هایی مانند Facebook\'s Instant Articles و Apple News که هر دو برای رفع و رجوع مشکل مشابهی تلاش می کنند در نظر گرفته می شود، اما باعث بروز این نگرانی می شود که مبادا باغ محصوری از محتوا را به دور از دنیای آزاد اینترنت ایجاد کند. از آنجایی که مدل عمده کسب و کار گوگل، خود مبتنی بر وب و تبلیغاتی است که به واسطه آن جذب می کند، دلیل ابداع یک راهکار دیگر به راحتی قابل درک است. از آنجایی که AMP بر پایه تکنولوژی های وب استاندارد ایجاد شده، باید از نقطه ضعف عمده Instant Articles اجتناب کند (مساله \"باغ محصور\")، اما عده ای هنوز هم این را به عنوان محدودیت در اینترنت و عمدتاً در پیوند با یک تامین کننده می دانند – که هر دو آنها هم صحیح است، اما برای اینکه قضاوت عادلانه ای نسبت به گوگل داشته باشیم، باید اذعان کرد که گوگل برای حل مشکل دوم این پروژه را به صورت متن باز (Open Source) ارائه کرده است. به علاوه، این می تواند واکنشی به مباحث جاری درباره مسدودکننده های تبلیغات باشد. با قابلیت جدید iOS9 برای افزودن مسدودکننده های تبلیغات و درک فزاینده نسبت به این امر که تجربه کاربری به شدت توسط تبلیغات مضمحل شده است –مخصوصا در بستر موبایل-، گوگل منبع اصلی درآمد خود (و البته مباحث بسیار مهم تجربه کاربری که قطعا انگیزه مهمی برای گوگل محسوب می شوند، فقط نمی توان مطمئن بود که تنها انگیزه یا انگیزه اصلی باشد!) را در معرض خطر می بیند. به نظر می رسد که گوگل با رفع و رجوع این مساله، در عین حال که به تبلیغاتی که زیاد روی عملکرد تاثیر نمی گذارند اجازه نمایش می دهد، امیدوار است جلوی از دست رفتن بخش قابل توجهی از درآمد خود و درآمد وبسایت های مرتبط را بگیرد. اینترنت محدود در گذشته نیز امتحان شده است. از WAP و سایت های موسوم به m. گرفته، تا وبسایت های واکنشگرایی که امروزه به شکل فزاینده ای در حال همه گیر شدن است. گوگل در کشورهایی که با کندی سرعت اینترنت مواجه هستند، در حال آزمایش Google Web Light نیز هست. این سیستم به طور خودکار وبسایت ها را تغییر می دهد (اگرچه به دلیل اینکه محدودیت های آن باعث بهم ریختگی وبسایت ها می شود و این واقعیت که بدون اطلاع از صاحب سایت و به شکل خودکار انجام می شود -مگر اینکه شخصا برای صرف نظر از سایت تان درخواست بدهید- باعث بروز واکنش های منفی نسبت به Google Web Light شده است). خلاصه پروژه صفحات موبایل شتاب یافته مفهوم جالبی است و همانطور که در انتهای صفحه اصلی سایت این پروژه قابل مشاهده است، بسیاری از نام های شناخته شده به آن پیوسته اند. من هرگز در مورد تکنولوژی های وب نسبت به گوگل بدبین نبوده ام، اما صادقانه بگویم؛ درک منطق پشتوانه AMP برایم دشوار است. چرا خودتان یک صفحه سبکتر ایجاد نکنید؟ درست است که قابلیت کش کردن صفحات یک انگیزه مضاعف است، اما این اساسا با استفاده از CDN که تقریبا مورد استفاده همه ناشران بزرگ است تفاوتی ندارد. بسیاری از مسائلی که AMP نیت رفع آنها را دارد، در واقع به دلیل اجزای ثالثی که همراه با صفحه بارگذاری می شوند بوجود می آیند، مثلا دکمه های بیش از حد حجیم رسانه های اجتماعی، تبلیغات و کتابخانه های جاوااسکریپت و فریم ورک هایی که انبوهی از کد را به صفحه اضافه می کنند، در حالیکه ممکن است ضرورتی نداشته باشند. در واقع، اینکه پروژه ای مانند AMP می خواهد به این مشکل رسیدگی کند خوب است، اما در جایی که از روش افراطی مسدود کردن همه اینها استفاده می کند، چه دلیلی دارد که صاحبان وبسایت ها خود لزوم و سودمندی آن برای همه کاربران و نه تنها کاربران موبایل را ارزیابی نکنند؟ یا اینکه چرا مستقیما به سراغ ریشه مشکل نرویم و از طرف های ثالث نخواهیم که جاوااسکریپت خود را بهبود بخشند؟ به عنوان مثال، چرا آیکن های رسانه های اجتماعی در حالیکه می توانند بسیار کم حجم تر طراحی شوند، اینقدر باید روی عملکرد سایت ها تاثیر بگذارند؟ تبلیغات نیز عامل عمده دیگری در تضعیف عملکرد هستند، اما از آنجایی که گوگل خود در این حوزه بزرگترین نقش را دارد، می تواند تاثیر مستقیمی بر ایجاد ابزارهایی برای تهیه تبلیغات پربازدهی داشته باشد که با عملکرد صفحه تداخل پیدا نمی کنند، یا اینکه می تواند ابزارهای بهتری برای نمایش تاثیر هر جزء روی وبسایت ها فراهم کند؛ شاید با یک پیش نمایش به سبک AMP با چنین عنوانی «ببینید وبسایت شما بدون آن محتوا چقدر سریع تر بارگذاری می شود». در غیاب چنین مواردی، صفحات غیر AMP به تاثیر فزاینده خود بر کلیت اینترنت غیرموبایل ادامه می دهند. همچنین تصور اینکه ناشران تمایل به افزودن یک فرمت دیجیتال دیگر به وبسایت اصلی، اپ های موبایل، Facebook Instant Articles، Apple News و هر چیز دیگری که برای انتشار محتوای خود از آن استفاده می کنند داشته باشند دشوار است. برخی از این موارد به جای تبدیل به یک فرمت دیگر نیازمند پیراستن صفحه به نحوی که تنها محتوای اصلی باقی می ماند هستند. البته هنوز هم اساسا از استانداردهای وب استفاده می شود (اگرچه با اعمال محدودیت روی برخی از آنها)، اما اگر قرار است که کد را با استفاده از تگ های تبدیل و دوباره همه چیز را بررسی کنید، چرا از ابتدا بهبود کد را در دستور کار خود قرار ندهید؟ همانطور که بسیاری از صاحب نظران در اینترنت دیدگاه خود را ابراز کرده اند: اگر عملکرد برای صاحبان یک وبسایت اهمیت داشته باشد، به احتمال زیاد بهینه سازی های لازم و ممکن را خودشان انجام می دهند، بنابراین عواید AMP کمتر خواهد بود، و اگر به عملکرد اهمیت نمی دهند، در این صورت به AMP هم توجهی نخواهند کرد. به علاوه، وبسایت پروژه AMP را به سختی می توان نمونه درخشانی از آنچه این پروژه در پی آن است دانست، در واقع کاملا عکس این قضیه صادق است! |
||
شنبه 05 فروردین 1396 - 12:06 |
|