Blog

İndekslənə bilən Progressive Web Apps qurulması

Çərşənbə, 9 noyabr 2016-cı il

Progressive Web Apps
(PWAs) mobil saytların və yerli tətbiqlərin ən yaxşı xüsusiyyətlərini istifadəçilərə təqdim etmək üçün yeni texnologiyalardan istifadə edir və onlar internetdəki ən maraqlı yeni ideyalardan biridir. Lakin həqiqətən təsirli olmaları üçün onların indekslənə bilən və linklənə bilən olması vacibdir. Bu məqalədə təqdim olunan hər bir tövsiyə, Progressive Web App və ya sadə statik veb sayt qurmağınızdan asılı olmayaraq, indekslənmə üçün mövcud olan ən yaxşı təcrübədir. Buna baxmayaraq, sizi istiqamətləndirmək üçün bu ən yaxşı təcrübələri bir siyahıda topladıq:

İndekslənə bilən Progressive Web Apps qurulması

Məzmununuzu Crawl edilə bilən edin

Niyə? Tarixən veb saytlar HTML-i həmişə serverdə yaradır və ya render edirdi ki, bu da məzmununuzun birbaşa linklənə bilməsini təmin etməyin ən sadə yoludur. Veb tətbiqləri, istifadəçi səhifəni yeniləmədən naviqasiya etdikcə məzmunun səhifədə dinamik şəkildə yeniləndiyi müştəri tərəfli render (client-side rendering) konsepsiyasını populyarlaşdırdı.

Müasir yanaşma hibrid renderdir; burada istifadəçi birbaşa URL-ə keçdikdə server tərəfli render, ilkin səhifə yükləndikdən sonra sonrakı naviqasiya və asinxron sorğular üçün isə müştəri tərəfli render istifadə olunur.

Bizim
server tərəfli PWA nümunəmiz
saf server tərəfli renderi nümayiş etdirir, bizim
hibrid PWA nümunəmiz isə
kombinə edilmiş yanaşmanı nümayiş etdirir.

Əgər server tərəfli və müştəri tərəfli render terminologiyası ilə tanış deyilsinizsə,
müştəri və server tərəfli renderhaqqında bu məqalələrə və
react və node.js-də server tərəfli render

haqqında məqalələrə baxın.

Ən yaxşı təcrübələr:

İstifadəçilərin məzmunu veb sorğularının ilkin yükündə alması üçün server tərəfli və ya hibrid renderdən istifadə edin.

URL-lərinizin müstəqil şəkildə əlçatan olduğundan həmişə əmin olun:

Yuxarıdakılar həmin xüsusi resursa dərin keçid (deep link) etməlidir.

Əgər Progressive Web App-iniz üçün server tərəfli və ya hibrid renderi dəstəkləyə bilmirsinizsə və müştəri tərəfli renderdən istifadə etməyə qərar verirsinizsə, məzmununuzun bizim Axtarış crawler-imiz üçün uğurla render olunduğunu yoxlamaq üçün Google Search Console “Fetch as Google tool”-dan istifadə etməyi tövsiyə edirik.

Dərin keçidlərə daxil olan istifadəçiləri veb tətbiqinizin ana səhifəsinə yönləndirməyin.


Bundan əlavə, dərin keçid əvəzinə istifadəçilərə xəta səhifəsi göstərməkdən də qaçınmaq lazımdır.

Təmiz URL-lər təmin edin Niyə?Fraqment identifikatorları ( #user/24601/ və ya#!user/24601/

) brauzerlərin səhifəni yeniləmədən serverdən yeni məzmunu AJAX ilə yükləməsi üçün effektiv bir həll yolu idi. Bu dizayn müştəri tərəfli render kimi tanınır. Lakin fraqment identifikatoru sintaksisi bəzi veb alətləri, çərçivələr və protokollarla uyğun deyil, məsələn,.

Facebook-un Open Graph protokolu History API bizə fraqment identifikatorları olmadan URL-i yeniləməyə, eyni zamanda resursları asinxron şəkildə yükləməyə və beləliklə səhifənin yenilənməsindən qaçınmağa imkan verir — bu, hər iki dünyanın ən yaxşısıdır. AJAX crawling sxemi #! (özünün

#! escaped-fragment URL-ləri ilə) öz dövründə məntiqli idi, lakin artıq tövsiyə edilmir. Bizim
hibrid PWA və müştəri tərəfli PWA nümunələrimiz

History API-ni nümayiş etdirir.

Ən yaxşı təcrübələr:# Fraqment identifikatorları olmayan təmiz URL-lər təmin edin ( #!və ya

) məsələn:

Müştəri tərəfli və ya hibrid renderdən istifadə edirsinizsə, History API ilə brauzer naviqasiyasını dəstəklədiyinizə əmin olun.

Qaçının: #! Unikal URL-lər yaratmaq üçün

URL strukturundan istifadə etmək tövsiyə edilmir: # O, History API-nin yaranmasından əvvəl bir həll yolu kimi təqdim edilmişdi. Bu, sırf

URL strukturundan fərqli bir nümunə hesab olunur. # Müvafiq ! simvolu olmadan

URL strukturundan istifadə etmək dəstəklənmir:

https://www.example.com/#product/25/


Bu URL strukturu artıq internetdə bir konsepsiyadır və müəyyən bir səhifədəki məzmuna dərin keçidlə əlaqəlidir.

Kanonik URL-ləri təyin edin Niyə?

Eyni məzmun bir neçə URL altında (eyni və ya fərqli domenlər olsa belə) mövcud olduqda indekslənmə üçün çaşqınlığı aradan qaldırmağın ən yaxşı yolu bir səhifəni kanonik olaraq qeyd etmək və həmin məzmunu təkrarlayan bütün digər səhifələrin ona istinad etməsini təmin etməkdir.

Ən yaxşı təcrübələr:

Müəyyən bir məzmun parçasını əks etdirən bütün səhifələrdə aşağıdakı teqi daxil edin:
Əgər Accelerated Mobile Pages-i dəstəkləyirsinizsə, onun qarşılığı olan rel=”amphtml”

təlimatını da düzgün istifadə etdiyinizə əmin olun.

Qaçının:
Məzmunu bir neçə URL-də qəsdən təkrarlamaqdan və rel=”canonical”

link elementindən istifadə etməməkdən çəkinin. Məsələn, rel=”canonical”

link elementi izləmə parametrləri olan URL-lər üçün qeyri-müəyyənliyi azalda bilər.


Səhifələriniz arasında ziddiyyətli kanonik istinadlar yaratmaqdan çəkinin.

Çoxsaylı cihazlar üçün dizayn edin Niyə?

Veb saytınıza baxarkən bütün istifadəçiləriniz üçün cihazından asılı olmayaraq mümkün olan ən yaxşı təcrübəni əldə etmələri vacibdir.
Saytınızı dizaynında
—şriftlər, kənarlar, boşluqlar, düymələr və saytınızın ümumi dizaynı ekran icazələri və cihaz görünüşləri əsasında dinamik şəkildə miqyaslanmalıdır.

Masaüstü və ya planşet cihazları üçün böyüdülmüş kiçik şəkillər zəif təcrübə yaradır. Əksinə, yüksək keyfiyyətli şəkillərin mobil telefonlarda yüklənməsi uzun vaxt aparır və mobil sürüşdürmə performansına mənfi təsir göstərə bilər.

Daha ətraflı oxuyun
PWA üçün UX.

Ən yaxşı təcrübələr:

İstifadə edin
srcset atributu
cihazın ekranının göstərə biləcəyindən daha böyük şəkillərin yüklənməsinin qarşısını almaq üçün müxtəlif sıxlıqlı ekranlar üçün fərqli ölçülü şəkilləri əldə etmək üçün.

Mətninizin cihazın ölçüsündən asılı olmayaraq oxunaqlı olmasını təmin etmək üçün şrift ölçüsünü və sətir hündürlüyünü tənzimləyin. Eyni şəkildə elementlərin boşluqlarının və kənarlarının da məntiqli şəkildə miqyaslandığından əmin olun.

Test edin
müxtəlif ekran icazələri
istifadə edərək
Chrome Developer Tool-un Cihaz Rejimi
funksiyası və
Mobil Dostluq Test aləti.

İstifadəçilərə Google-a göstərdiyinizdən fərqli məzmun göstərməyin. Əgər
yönləndirmələr və ya istifadəçi agentinin aşkarlanması
(yəni brauzer yoxlanışı və ya
dinamik xidmət) istifadə edirsinizsə, saytınızın dizaynını müxtəlif cihazlar üçün dəyişdirmək üçün məzmunun özünün eyni qalması vacibdir.

Google tərəfindən əldə edilən məzmunun istifadəçinin gördüyü məzmunla uyğun olduğunu yoxlamaq üçün Search Console-un “Fetch as Google” alətindən istifadə edin.

İstifadə rahatlığı üçün sabit ölçülü şriftlərdən istifadə etməyin.

İterativ şəkildə inkişaf etdirin

Niyə? Veb tətbiqinə funksiyalar əlavə edərkən ən təhlükəsiz yollardan biri dəyişiklikləri iterativ şəkildə etməkdir. Əgər funksiyaları bir-bir əlavə etsəniz, hər bir fərdi dəyişikliyin təsirini müşahidə edə bilərsiniz.

Alternativ olaraq, bir çox tərtibatçı öz proqressiv veb tətbiqlərini mobil saytlarını bir anda yeniləmək üçün bir fürsət kimi görürlər — yeni veb tətbiqi izolyasiya edilmiş mühitdə hazırlayır və hazır olduqda mövcud mobil saytları ilə əvəz edirlər.

Funksiyaları iterativ şəkildə hazırlayarkən dəyişiklikləri ayrı hissələrə bölməyə çalışın. Məsələn, server tərəfində renderinqdən hibrid renderinqə keçmək istəyirsinizsə, bunu digər funksiyalarla birlikdə deyil, tək bir iterasiya kimi həll edin.

Hər iki yanaşmanın öz müsbət və mənfi tərəfləri var. İterasiya, keçid davamlı olduğu üçün axtarış indeksləşdirilməsi ilə bağlı mürəkkəbliyi azaldır. Bununla belə, iterasiya daha yavaş inkişaf prosesinə və inkişaf sıfırdan başlamadıqda daha az innovativ yenilənməyə səbəb ola bilər.

Hər iki halda, diqqət yetirilməli olan ən həssas sahələr kanonik URL-ləriniz və saytınızın robots.txt konfiqurasiyasıdır.

Ən yaxşı təcrübələr:

Yeni funksiyaları hissə-hissə əlavə edərək saytınızı artan şəkildə iterasiya edin.

Məsələn, hələ HTTPS-i dəstəkləmirsinizsə, təhlükəsiz sayta keçidlə başlayın.

Qaçının:

Əgər proqressiv veb tətbiqinizi izolyasiya edilmiş mühitdə hazırlamısınızsa, rel-canonical linklərinin və robots.txt-in düzgün qurulduğunu yoxlamadan onu işə salmaqdan çəkinin.

Rel-canonical linklərinizin real sayta yönəldiyinə və robots.txt konfiqurasiyanızın krolerlərin yeni saytınızı taramasına icazə verdiyinə əmin olun.

İşə salmazdan əvvəl krolerlərin inkişaf mərhələsində olan saytınızı indeksləşdirməsinin qarşısını almaq məntiqlidir, lakin işə saldıqda krolerlərin yeni saytınıza daxil olmasına icazə verməyi unutmayın.


Proqressiv Təkmilləşdirmədən istifadə edin

Niyə? Mümkün olan hər yerdə brauzer funksiyalarını istifadə etməzdən əvvəl aşkar etmək vacibdir. Funksiyanın aşkarlanması, müəyyən bir funksiyanı dəstəklədiyinə inandığınız brauzerləri test etməkdən daha yaxşıdır.

Keçmişdə geniş yayılmış pis təcrübə, istifadəçinin hansı brauzerə sahib olduğunu yoxlayaraq funksiyaları aktivləşdirmək və ya deaktiv etmək idi. Lakin brauzerlər funksiyalarla daim inkişaf etdiyi üçün bu texnika qətiyyən tövsiyə edilmir.

Service Worker nisbətən yeni bir texnologiyadır və tərəqqi naminə uyğunluğu pozmamaq vacibdir — bu, proqressiv təkmilləşdirmədən istifadə etmək üçün mükəmməl bir nümunədir.

Ən yaxşı təcrübələr:

Service Worker-i qeydiyyatdan keçirməzdən əvvəl onun API-sinin mövcudluğunu yoxlayın:

Saytınızın bütün funksiyaları üçün API aşkarlama metodundan istifadə edin.

Veb tətbiqinizdə funksiyaları aktivləşdirmək və ya deaktiv etmək üçün heç vaxt brauzerin istifadəçi agentindən istifadə etməyin. Həmişə funksiyanın API-sinin mövcud olub-olmadığını yoxlayın və mövcud olmadıqda zərif şəkildə geri çəkilin.

Saytınızı bir neçə brauzerdə test etmədən yeniləməkdən və ya işə salmaqdan çəkinin! İstifadəçi bazanız arasında hansı brauzerlərin ən populyar olduğunu öyrənmək üçün sayt analitikanızı yoxlayın.


Search Console ilə test edin

Niyə? Google Axtarışın saytınızın məzmununu necə gördüyünü başa düşmək vacibdir. Siz
Search Console istifadə edərək
saytınızdan fərdi URL-ləri əldə edə
və “Crawl > Fetch as Google” funksiyasından istifadə edərək Google Axtarışın onları necə gördüyünü görə bilərsiniz. Search Console JavaScript-inizi emal edəcək və bu seçim seçildikdə səhifəni render edəcək; əks halda yalnız xam HTML cavabı göstərilir.

Google Search Console həmçinin səhifənizdəki məzmunu müxtəlif yollarla, o cümlədən Strukturlaşdırılmış Məlumatların, Rich Cards-ın, Sitelinks-in və Accelerated Mobile Pages-in mövcudluğunu aşkar etməklə təhlil edir.

Ən yaxşı təcrübələr:

Search Console-dan istifadə edərək saytınızı izləyin və Fetch as Google daxil olmaqla onun funksiyalarını araşdırın.

Search Console vasitəsilə sayt xəritəsi təqdim edin Krol > Sayt xəritələri. Google Axtarışın saytınızın bütün səhifələrindən xəbərdar olmasını təmin etmək üçün effektiv bir yol ola bilər.


Schema.org strukturlaşdırılmış məlumatları ilə qeyd edin

Niyə? Schema.org strukturlaşdırılmış məlumatlar, səhifənizin ən vacib hissələrini maşın tərəfindən emal edilə bilən məlumatlar kimi ümumiləşdirmək üçün çevik bir lüğətdir. Bu, səhifənin bir NewsArticleolduğunu sadəcə demək qədər ümumi ola bilər və ya qastrol səfərində olan qrup üçün yer, qrup adı, məkan və bilet satıcısını təfərrüatlandırmaq və ya resept üçün inqrediyentləri və addımları ümumiləşdirmək qədər spesifik ola bilər.

Bu metadatanın istifadəsi veb tətbiqinizdəki hər səhifə üçün məntiqli olmaya bilər, lakin məntiqli olduğu yerlərdə tövsiyə olunur. Google onu səhifə render edildikdən sonra çıxarır.

NewsArticle Recipe, vəProduct
kimi bir neçə məlumat növü var. Siz həmçinin bütün dəstəklənən məlumat növlərini burada
araşdıra bilərsiniz.

Ən yaxşı təcrübələr:

Schema.org meta məlumatlarınızın Google-un
Strukturlaşdırılmış Məlumat Test Aləti.

vasitəsilə düzgün olduğunu yoxlayın.

Təqdim etdiyiniz məlumatların göründüyünü və heç bir xətanın olmadığını yoxlayın. Səhifənizin faktiki məzmununa uyğun gəlməyən məlumat növündən istifadə etməyin. Məsələn, istifadə etməyin
Resept satdığınız bir köynək üçün—əvəzinə Məhsul istifadə edin.


Open Graph və Twitter Cards ilə annotasiya edin

Niyə? Schema.org metadata-sına əlavə olaraq, Facebook-un Open Graph protokolu və Twitter rich cards üçün də dəstək əlavə etmək faydalı ola bilər.

Bu metadata formatları məzmununuz müvafiq sosial şəbəkələrdə paylaşıldıqda istifadəçi təcrübəsini yaxşılaşdırır.

Əgər mövcud saytınız və ya veb tətbiqiniz bu formatlardan istifadə edirsə, optimal yayılma üçün onların sizin progressive web application-ınıza da daxil edildiyindən əmin olmaq vacibdir.

Ən yaxşı təcrübələr:

Open Graph işarələrinizi bununla yoxlayın:
Facebook Object Debugger Tool.

Bununla tanış olun:
Twitter-in metadata formatı.

Əgər mövcud saytınız dəstəkləyirsə, bu formatları daxil etməyi unutmayın.


Çoxsaylı Brauzerlərlə Test Edin

Niyə? İstifadəçi baxımından bir veb saytın bütün brauzerlərdə eyni şəkildə davranması vacibdir. Təcrübə fərqli ekran ölçüləri üçün uyğunlaşa bilsə də, biz hamımız mobil saytın iPhone və ya Android mobil telefonu olmasından asılı olmayaraq, oxşar ölçülü cihazlarda eyni şəkildə işləməsini gözləyirik.

Dünyada istifadə olunan brauzerlərin sayına görə veb parçalanmış kimi görünsə də, bu müxtəliflik və rəqabət vebi innovativ platforma edən amillərdəndir. Xoşbəxtlikdən, veb standartları heç vaxt indiki qədər yetkin olmayıb və müasir alətlər tərtibatçılara zəngin, brauzerlərarası uyğun veb saytları inamla qurmağa imkan verir.

Ən yaxşı təcrübələr:

Brauzerlərarası test alətlərindən istifadə edin, məsələn:
BrowserStack.com,
Browserling.com və ya
BrowserShots.org PWA-nızın brauzerlərarası uyğun olduğundan əmin olmaq üçün.


Səhifə Yüklənmə Performansını Ölçün

Niyə? Veb sayt istifadəçi üçün nə qədər sürətli yüklənərsə, istifadəçi təcrübəsi bir o qədər yaxşı olar. Səhifə sürəti üçün optimallaşdırma veb inkişafında artıq yaxşı məlum olan bir diqqət mərkəzidir, lakin bəzən saytın yeni versiyasını hazırlayarkən lazımi optimallaşdırmalar yüksək prioritet hesab edilmir.

Progressive web application hazırlayarkən, ən yaxşı nəticələr üçün səhifə yüklənmə sürətinizin performansını ölçməyi və saytı işə salmazdan əvvəl optimallaşdırmağı tövsiyə edirik.

Ən yaxşı təcrübələr:

Alətlərdən istifadə edin, məsələn:
Page Speed Insights və
Web Page Test
saytınızın səhifə yüklənmə performansını ölçmək üçün. Googlebot render etməkdə bir az daha səbrli olsa da,
araşdırmalar göstərir ki,
istehlakçıların 40%-i yüklənməsi üç saniyədən çox vaxt aparan səhifəni tərk edəcək.

Veb səhifə performansı tövsiyələrimiz və kritik render yolu haqqında daha çox oxuyun
burada.

Optimallaşdırmanı işə salındıqdan sonrakı mərhələ kimi saxlamaqdan çəkinin. Əgər veb saytınızın məzmunu yeni progressive web application-a keçməzdən əvvəl sürətlə yüklənirsə, optimallaşdırmalarınızda geriləməmək vacibdir.


Ümid edirik ki, yuxarıdakı yoxlama siyahısı faydalıdır və Progressive Web Applications-larınızı indekslənməni nəzərə alaraq hazırlamağınıza kömək edəcək düzgün rəhbərliyi təmin edir.

Başlayarkən, server tərəfi, müştəri tərəfi və hibrid renderi nümayiş etdirən
Progressive Web App indekslənmə nümunələrimizə
baxmağı unutmayın. Həmişə olduğu kimi, hər hansı bir sualınız olarsa, lütfən bizimlə əlaqə saxlayın
Webmaster Forums.

Alien Road

Bunu necə tətbiq edirik

We archive Search Central announcements because client questions often trace back to a change that was announced years ago. Reading the original is faster than reconstructing it from second-hand summaries.

Əlaqəli xidmətlər

Paylaş