Mga taktika sa paglago ng publisher para sa panahon ng eleksyon | WEBINAR
Mga taktika sa paglago ng publisher para sa panahon ng eleksyon | WEBINAR
Sa pagtatapos ng modyul na ito, dapat ay malinaw mo nang naunawaan ang iba't ibang bahagi na nakakatulong sa Page Experience, kung bakit mahalaga ang mga ito, at kung paano maaaring i-optimize ang bawat isa upang mapabuti ang karanasan ng gumagamit ng iyong site at ang SEO nito.
Tagal ng Video
17:09
Pagsagot sa Pagsusulit
Sagutan ang kasalukuyang pagsusulit sa modyul
Mga Materyales
Mga template na handa nang gamitin
Mga Mapagkukunan
Mga Ulat at Mapagkukunan
2.3.1 Ano ang Karanasan sa Pahina?
Ang karanasan sa pahina ay isang hanay ng mga signal — kabilang ang Core Web Vitals (CWV), mobile-friendly, HTTPS at mga intrusive interstitial guidelines — na ginagamit ng Google para i-extrapolate ang karanasan ng user sa isang website.
Ang karanasan sa pahina ay isang pagsusuri sa pagganap ng isang site sa halip na sa nilalaman nito. Bagama't inuuna pa rin ng Google ang kaugnayan ng nilalaman kapag sinasagot ang mga tanong ng user, ang karanasan sa pahina ay epektibong isang tie breaker kapag maraming site ang nag-aalok ng parehong antas ng saklaw.
Ang apat na senyales ng karanasan sa pahina ay:
Sinusukat ng mga CWV ang karanasan ng gumagamit sa pamamagitan ng pagtuon sa kung gaano kabilis naglo-load ang isang pahina, ang pagtugon nito sa input ng gumagamit, at gayundin ang visual stability nito. May tatlong sukatan para dito:
Ipinakilala ng update ng Google noong Abril 2015 ang mobile-friendly metric ng higanteng search engine na ito, na nagpapataas ng ranggo ng mga mobile-friendly na pahina sa mga mobile SERP.
Sa katunayan, uunahin ng Google ang mga site na nagsisigurong madaling basahin ang kanilang nilalaman sa mga mobile device — ibig sabihin, hindi na kailangang mag-zoom, ang mga touch target tulad ng mga button sa pag-login ay hindi masyadong magkakalapit, walang pahalang na pag-scroll, at maiiwasan ang hindi mape-play na nilalaman.
Ang update ay naaangkop sa mga indibidwal na pahina, hindi sa buong website, at hindi rin nito maaapektuhan ang nilalamang tinitingnan sa mga desktop/laptop browser.
Ang HTTPS, o hypertext transfer protocol secure, ay isang ligtas na bersyon ng HTTP internet communication protocol.
Ang HTTPS, o HTTP, ang bumubuo sa unang bahagi ng bawat URL na kilala bilang "scheme". Nauuna ito sa domain name, na siyang segment ng URL na kilala bilang "authority".
Ang pagkakaiba ng HTTPS at HTTP ay ang una ay ligtas habang ang huli ay hindi. Ang ibig sabihin nito sa pagsasagawa ay ang mga user na nagla-log in sa isang site sa pamamagitan ng isang koneksyon sa HTTP ay nagpapadala ng kanilang mga personal na detalye sa hindi naka-encrypt na plain text.
Sinisiguro ng HTTPS ang koneksyong iyon, ibig sabihin, ang anumang data na ipinapadala sa pagitan ng browser ng user at ng server ng website ay naka-encrypt habang isinasagawa ang proseso. Ang mga site na nagnanais ng mga ligtas na koneksyon ay nangangailangan ng SSL certificate, na sinusuri at bineberipika ng browser ng user.
Ang mga interstitial ay isang format ng ad na para lamang sa mobile na lumalabas lamang sa mga natural na break sa nilalaman — tulad ng kapag ang isang user ay lumipat mula sa isang artikulo patungo sa susunod — na sumasakop sa screen sa proseso.
Ang mga interstitial ay itinuturing na nakakaabala kapag hinaharangan o bahagyang natatakpan nito ang pagtingin ng mga user sa nilalaman. Ang mga dialog box sa mga mobile website na may katulad na paggana ay nabibilang din sa kategoryang ito.
Karamihan sa mga pinakamahuhusay na kasanayan ng mga publisher ay kadalasang sa paggawa ng nilalaman, paglalathala, at pagmemerkado, kaya maliit na espasyo ang natitira para maunawaan at ma-optimize ang iba't ibang haligi ng karanasan sa pahina.
Dahil limitado ang mga mapagkukunan, mahihirapan ang mga publisher na bigyang-katwiran ang oras at perang kailangan para masuri ang backend ng mga indibidwal na web page, lalo na ang isang buong website.
Kahit na makapaglaan ng oras ang mga publisher upang harapin ang problema, gaya ng makikita natin sa itaas, ang karanasan sa pahina ay isang maraming aspeto na isyu na nangangailangan ng isang holistic na diskarte upang makapaghatid ng makabuluhang mga nadagdag sa pagganap.
Ang pag-alam kung alin sa apat na pahinang senyales ng karanasan ang dapat simulan ay maaaring maging sakit ng ulo sa ganang sarili nito.
Napakahalaga ng karanasan sa pahina para sa SEO ng publisher, dahil hindi sapat ang mahusay na nilalaman para garantiyahan ang pinakamataas na posisyon sa loob ng mga SERP.
Pinahahalagahan pa rin ng Google ang pinakamahusay na impormasyon bago ang anumang bagay, ibig sabihin, ang natatanging nilalaman o mga "scoop" ng balita ay magiging mahusay kahit na ang karanasan sa pahina ay "hindi gaanong mahusay" . Gayunpaman, sa mga kaso kung saan ang ilang mga publisher ay nagbibigay ng mahusay na saklaw sa paksa, ang karanasan sa pahina ay nagiging isang mahalagang salik sa pagpapasya na nakakaimpluwensya sa mga ranggo sa SERP.
Ang bawat isa sa apat na haligi ng karanasan sa pahina ay may iba't ibang epekto sa SEO ng isang website. Ang pinakakaagad na epekto ay nagmumula sa pagtuon sa mga CWV, na isasalin sa isang website na mas mabilis na naglo-load.
Maraming pag-aaral ang nagpakita na habang tumatagal ang paglo-load ng isang website, mas mabilis nawawalan ng interes ang mga manonood at mas tumataas ang bounce rate.
Halimbawa, natuklasan sa isang pag-aaral ng Google noong 2018 na ang posibilidad ng bounce ay tumaas ng 32% nang tumaas ang oras ng pag-load ng pahina mula 1 segundo patungong 3 segundo.
Isa pang pag-aaral ng Google mula noong 2020 ang natuklasan na ang mga site ng balita na nakapasa sa CWV test ay nakakita ng 22% na mas mababang abandonment rate kaysa sa mga bumagsak. Samantala, pinabuti ng Yahoo! JAPAN ang CLS score nito ng 0.2 at nakakita ng 15.1% na pagtaas sa mga page view bawat session at 13.3% na pagtaas sa tagal ng session.
Bagama't tahasang sinabi ng Google na hindi nito ginagamit ang mga bounce rate bilang signal ng ranking , ang mataas na bounce rate ay nagpapahiwatig ng mga salik na pinapahalagahan ng Google — katulad ng load speed, responsiveness, at visual stability ng isang pahina.
Kailangang tiyakin ng mga publisher na nagta-target ng mga audience sa mga mobile device na ang kanilang site ay nagpapadala ng mga mobile friendly na signal na maaaring mapansin ng Google at Bing. Parehong uunahin ng mga search engine ang mga website na madaling gamitin kapag naghahatid ng mga resulta ng paghahanap sa mga mobile user.
Kung ikukumpara sa mga CWV at mobile friendly, ang pagpapatupad ng HTTPS ay magkakaroon ng mas maliit na epekto sa SEO ng isang publisher. Sinabi ng Google noong 2014 na gagamitin nila ito bilang isang ranking signal at sinimulang markahan ang lahat ng HTTP site bilang "hindi ligtas" sa Chrome noong 2018. Gayunpaman, ang pinakamalaking benepisyo rito ay ang pinahusay na seguridad ng data, lalo na kung ang iyong business module ay nakabatay sa kita mula sa subscription.
Samantala, ang mga nakakaabala na interstitial ad o dialogue box ay maaaring limitahan ang kakayahan ng mga web crawler na mag-crawl at mag-index ng isang pahina, na pumipigil sa mga search engine na mai-rank ito, lalo na ang mga mataas na resulta ng paghahanap.
Ang unang hakbang tungo sa pagpapabuti ng karanasan sa pahina ay nagsisimula sa pagsusuri ng kasalukuyang bisa ng iyong website.
Mayroong malawak na hanay ng mga first at third-party na tool para makamit ito ngunit, para sa gabay na ito, titingnan natin ang mga first-party na tool ng Google.
Alam na natin ngayon na ang mga CWV ay isang mahalagang salik sa pagraranggo. Ngunit paano ito sinusukat? Inililista ng talahanayan sa ibaba ang mga parameter kung saan dapat mahulog ang pinakamainam na mga numero ng CWV para sa pinakamahusay na karanasan sa pahina.
Ngayong alam na natin kung ano ang kailangan nating sukatin at kung gaano kalaki, maaari na nating tingnan kung paano sukatin ang karanasan sa pahina.
Nasa ibaba ang isang listahan ng ilan sa mga pinakakaraniwang ginagamit na pamamaraan.
Ang unang opsyon na bukas para sa mga publisher ay sa ngayon ang pinakamahirap sa teknikal na aspeto at hindi namin ito irerekomenda maliban na lang kung mayroon kang mahusay na developer na tutulong sa pagpapatupad nito.
Pinag-uusapan natin ang pangangalap ng datos ng user mula sa iyong site, isang prosesong kilala bilang real user monitoring (RUM), at pagkatapos ay pagsusuri ng mga resulta sa loob ng Google Analytics 4 (GA4). May iba pang mga tool ang Google, tulad ng PageSpeed Insights (PSI), na gumagamit ng data sampling upang suriin ang iyong site. Ngunit kung ang layunin ay magkaroon ng kumpletong larawan ng karanasan ng user para sa iyong website, kailangan mo ng totoong datos na nakalap mula sa iyong site.
Iminumungkahi namin ang paggamit ng GA4 para sa gawaing ito dahil balak ng Google na simulan ang "pagtigil" sa paggamit ng nakaraang henerasyon ng Google Analytics, ang Universal Analytics (UA), simula kalagitnaan ng 2023.
Bilang isang publisher, dapat ay nakapag-set up ka na ng GA4 account bilang paghahanda sa paglipat. Kung hindi mo pa ito nagagawa, sundin lamang ang mga gabay ng Google kung paano ito i-set up sa unang pagkakataon o kung paano ito idagdag sa isang site na mayroon nang UA .
Kapag tapos na iyan, ang susunod na hakbang ay i-link ang BigQuery data warehouse ng Google sa GA4 mula sa Analytics Admin. Ang pag-link ng BigQuery ay magbibigay-daan sa iyong mag-query sa iyong data gamit ang SQL. Narito ang isang gabay kung paano i-link ang dalawa .
Matapos ang mga hakbang na iyan, maaari na nating idagdag ang web-vitals library sa iyong site.
Ang library, na isang napakaliit na modular na JavaScript library para sa pangongolekta ng datos, ay makukuha sa GitHub.
Maaaring i-install ang library mula sa open-source npm online repository sa pamamagitan ng pagpapatakbo ng “npm install web-vitals” sa iyong command terminal o sa pamamagitan ng<script> tags on a content distribution network (CDN).
Narito ang isang halimbawa ng ganitong script:
Kapag na-install na ang web-vitals library, maaaring ipadala ang data ng user sa Google Tag Manager (GTM), gamit ang isang custom template tag na inirerekomenda ng Google na ginawa at pinapanatili ni Simo Ahava.
Kapag na-install na ang tag, maaari na itong ipasa sa GA4 kaugnay na data ng attribution
Kapag na-set up mo na ang analytics para subaybayan ang GTM data, makikita mo na ang event data sa BigQuery interface. Maaaring i-query ang data na ito tulad nito:
Kapag naibalik na ang query, dapat ganito ang hitsura ng ulat:
Kailangan talaga nating bigyang-diin muli na ito ay isang solusyon ng developer at, sa katunayan, ay mas kumplikado kaysa rito. Gayunpaman, ang paggamit ng solusyong ito ay magbibigay sa iyo ng pinakatumpak na pagbasa sa pagganap ng iyong website.
Para sa mas detalyadong paliwanag ng prosesong ito, tingnan ang gabay ng Google sa pagtingin ng mga CWV sa GA4 .
Bagama't ito ang pinakatumpak na paraan sa pagsubaybay sa mga CWV, may mga mas simpleng paraan upang matugunan ang problemang ito.
Ang PSI ay hindi gaanong tumpak kumpara sa paggamit ng GA/RUM na pamamaraan, gayunpaman, madalas itong binabanggit bilang isa sa pinakamahalagang kagamitan sa pagsukat ng mga CWV — salamat sa kadalian ng paggamit nito.
Bagama't maaaring gumamit lamang ito ng mga halimbawa ng mga totoong karanasan ng user na kinuha mula sa Chrome User Experience Report (CrUX) sa nakalipas na 28 araw, ang PSI ay nagbibigay ng simple at madaling maunawaang user interface . Nangangahulugan ito na ang pagbibigay-kahulugan sa data ay isang mas simpleng proseso.
Gaya ng makikita mo sa aming halimbawa sa ibaba, ang pagsusuri sa site ng Forbes ay agad na nagbibigay ng maraming impormasyon tungkol sa desktop at mobile website ng publisher.
Ginagamit ng PSI ang berde, kulay amber, at pulang kategorya mula sa itaas kapag nagtatalaga ng Mahusay, Nangangailangan ng Pagpapabuti, at Mahinang Marka sa Pagganap.
Ang pamamaraan ng pagkuha ng mga sample ng CrUX ay nangangahulugan na bagama't kinuha ng nabanggit na pagtatasa ng Forbes ang ilang totoong karanasan ng mga gumagamit sa site, hindi nito maaaring isaalang-alang ang lahat ng datos ng gumagamit ng site.
Ang pamamaraang ito ng pagkuha ng sampling ay nagiging problematiko para sa mas maliliit na lugar, na marami sa mga ito ay hindi makikita sa datos ng field ng CrUX.
Gayunpaman, maaari pa ring mag-alok ang PSI ng virtual na diagnosis ng iyong website gamit ang data ng laboratoryo na kinuha mula sa open-source na Lighthouse tool . Tingnan ang halimbawa sa ibaba:
Ang problema sa pamamaraang ito ay kinokolekta ng Lighthouse ang data nito gamit ang mga paunang natukoy na setting ng device at network, na hindi magpapakita ng mga setting ng iyong mga user. Nangangahulugan ito na hindi ito isang magandang pamalit sa totoong data.
Ang GSC ay isang tool na idinisenyo upang magbigay sa mga publisher ng pangkalahatang pananaw sa mga isyu ng CWV ng kanilang website, na nagbubukas ng pinto sa isang holistic na diskarte sa pagpapabuti ng performance ng site.
Ginagawa nito ito sa pamamagitan ng pagpapangkat-pangkat ng mga ulat ng pagganap ng URL nito batay sa katayuan, uri ng sukatan, o pagkakatulad ng paksa. Hindi nito tinutukoy ang mga isyu sa mga indibidwal na pahina, na nagtatanggi sa pagkakataong magpatupad ng mga pag-aayos sa isang detalyadong antas.
Dito pumapasok ang PSI. Gayunpaman, mahalagang tandaan na ang ulat ng indibidwal na pahina ng PSI ay maaaring ibang-iba nang malaki sa mga resulta ng grupo ng GSC. Ito ay dahil ang indibidwal na pahina ay isa lamang bahagi ng pinagsama-samang mga resulta ng grupo ng GSC.
Kapag nagla-log in sa dashboard ng GSC, makikita ng mga user ang tab na Core Web Vitals sa kaliwang bahagi. Ang pag-click sa tab na ito ay magpapakita ng magkahiwalay na ulat ng CWV sa mobile at desktop para sa mga grupo ng URL.
Sa kabila ng pagkakaroon ng tatlong sukatan ng CWV — LCP, FID, at CLS — makakatanggap ang mga URL ng pangkalahatang grado batay sa kanilang pinakamasamang performance metric para sa isang partikular na device na makakaapekto rin sa mga ulat ng grupo.
Halimbawa, kung ang isang URL sa mobile ay nakatanggap ng Mahinang FID at Magandang LCP, ito ay mamarkahan bilang Mahina sa mobile.
Muli, mahalagang tandaan na ang GSC ay hindi para sa mga detalyadong pag-aayos. Gayunpaman, mainam ito para sa mga publisher na may maraming magkakatulad na pahina. Halimbawa, ang mga site ng balita ay maaaring may medyo karaniwang disenyo at layout para sa kanilang mga pahina ng artikulo na gumagamit ng isang imahe bilang pinakamalaking elemento sa itaas ng fold. Sa kasong ito, mabilis na makakatulong ang GSC na matukoy ang mga problema sa LCP sa iba't ibang URL.
Ang panghuling tool sa toolkit ng pagsukat ng pagganap ng Google ay ang Lighthouse . Ang tool na ito ay ibang-iba sa mga nauna dahil ginagaya nito ang pagganap ng user batay sa isang itinakdang hanay ng mga parameter.
Hindi ito gumagamit ng datos mula sa field kaya mas limitado sa mga praktikal na gamit. Halimbawa, ang datos mula sa field ay naiimpluwensyahan ng koneksyon sa network ng isang user at ang kanilang distansya sa mga server ng site, samantalang ginagaya ng Lighthouse ang isang mid-range device upang mangolekta ng datos sa loob ng isang kontroladong kapaligiran.
Mahalaga ring maunawaan na ang iskor ng Lighthouse ay hindi lamang pagsasama-sama ng mga iskor ng CWV. Hindi nito isinasama ang FID, dahil ang datos ng laboratoryo ay likas na hindi isinasama ang mga interaksyon ng end-user, habang idinaragdag ang kabuuang oras ng pagharang (TBT), bilis ng indeks (SI) at oras sa mga interactive (TTI) na sukatan. Para sa mga gustong gayahin ang isang karanasan sa FID sa laboratoryo, maaaring gamitin ang TBT bilang isang proxy.
Gayunpaman, hindi namin inirerekomenda ang paggamit ng Lighthouse bilang pangunahing mapagkukunan ng pagsukat. Sa halip, dapat itong gamitin bilang kasamang tool kasama ng PSI upang makatulong sa pag-troubleshoot ng mga partikular na isyu sa pahina.
Ang mga publisher na gustong gumamit ng Lighthouse sa kanilang pagsubok ay maaaring gawin ito sa pamamagitan ng Chrome Devtools na direktang naka-bake sa Chrome browser, isang extension para sa nasabing browser o sa web.dev/measure .
Susuriin ng Lighthouse ang iyong webpage at magbibigay ng mga marka na 100 sa apat na aspeto:
Ganito ang hitsura kapag inilagay natin ang ating homepage sa opsyong web.dev.
Naiiba ang mobile web design sa tradisyonal na desktop web design dahil mas maliliit ang screen ng mga mobile device, karaniwang may hindi gaanong makapangyarihang hardware, at umaasa lamang sa mga touch input.
Inuuna ng mga mobile-friendly na site ang karanasan ng user sa pamamagitan ng pagsunod sa isang hanay ng mga pinakamahusay na kasanayan na ating tatalakayin mamaya. Sa ngayon, ang pinakamahusay na paraan upang suriin kung ang iyong mga pahina ay mobile-friendly ay sa pamamagitan ng Mobile-Friendly Test .
Ang paglalagay ng URL ng isang mobile-friendly na web page ay magbabalik ng sumusunod na resulta:
Ang mga pahinang hindi papasa sa pagsusulit na ito ay lalabas na may ilang mga opsyon sa pag-aayos na maaaring gawin. Tatalakayin natin ang mga iyon mamaya.
Ang pagsuri kung ang iyong website ay may ligtas na koneksyon ay isang napakasimpleng proseso, na kinabibilangan ng pagbubukas ng iyong browser at pagtingin sa simbolo sa kaliwa ng URL sa address bar.
Sa Chrome, ang isang ligtas na koneksyon ay ipapakita sa pamamagitan ng isang simbolo ng saradong padlock tulad nito:
Ang isang hindi ligtas na koneksyon ay magkakaroon ng simbolo ng Impormasyon tulad nito:
Ang pagtukoy kung ang iyong mga interstitial ad ay nakakaabala o hindi ay hindi kasing simple ng paglalagay ng iyong website sa isang online tool at paghihintay na magbalik ito ng tsek o hindi.
Kinakailangan nito ang pag-aaral ng mga interstitial ad at mga kahon ng diyalogo sa iyong site at pagpapasya kung pumasa ang mga ito sa ilang partikular na parameter.
Isipin ang mga parametrong ito bilang mga tanong, halimbawa:
Kung oo ang sagot mo sa alinman sa mga tanong na ito, malamang na indikasyon ito na nakakaabala ang ad o dialogue box.
Ngayong lubos na nating nauunawaan ang iba't ibang bahagi ng apat na bahagi na binibilang sa karanasan sa pahina, pati na rin ang mga paraan upang masubaybayan ang kanilang pagganap, magpatuloy tayo sa pag-aaral kung paano natin eksaktong mapapahusay ang mga signal ng ranggo ng ating mga site
Titingnan muna natin ang mga CWV, dahil ang pag-debug at pag-optimize ng LCP, CLS, at FID ang magkakaroon ng pinakamalaking epekto sa iyong kakayahang makipagkumpitensya para sa mga nangungunang puwesto sa mga pinagtatalunang ranggo sa SERP.
Bagama't napakahalaga ng pagiging mobile-friendly para sa mga site na nagta-target sa mga mobile user, ang pagpapabuti ng mga CWV ay magpapalakas sa performance ng page para sa mga site kahit na tinitingnan ang mga ito sa mga mobile device o desktop.
Ang pagtugon sa HTTPS at mga intrusive interstitial ay hinayaan na lang hanggang sa huli dahil mas madali ang mga ito at hindi gaanong kapaki-pakinabang ang mga panalo.
Mayroong ilang mga opsyon pagdating sa pagpapabuti ng performance ng CWV, na aming pinaghiwa-hiwalay ayon sa kahalagahan na sa tingin namin ay nararapat para sa mga ito.
Ang pag-optimize sa Core Web Vitals ng anumang pahina ay isang hanay ng mga aksyon at mahalagang malaman kung saan magsisimula upang ma-maximize ang iyong mga mapagkukunan.
Gaya ng nabanggit na natin sa itaas, sinusukat ng largest contentful paint (LCP) kung gaano katagal bago ganap na ma-load ang pinakamalaking text o image asset na nakikita sa itaas ng fold.
Gamitin ang PSI upang matukoy kung aling nilalaman ng pahina ang nagti-trigger sa LCP test, sa pamamagitan ng pagpunta sa seksyon ng diagnosis ng ulat at pag-click sa “Pinakamalaking Contentful Paint element”. Narito ang nakita namin sa homepage ng SODP:
Ang isang mababang marka ng LCP ay karaniwang maaaring mabawasan sa mabagal na oras ng pagtugon ng server, pagharang sa render ng JavaScript at CSS, oras ng pagkarga ng resource o client-side rendering, o kahit na kombinasyon ng lahat ng apat.
Ang pag-optimize ng iyong pahina ay talagang nagsasangkot ng pag-optimize ng apat na magkakaibang bahagi ng proseso ng pag-load ng LCP:
Dapat i-optimize ang lahat ng mga hakbang na ito para makita mo ang pagbuti sa iyong marka sa LCP. Gayunpaman, hindi ibig sabihin nito na pantay ang kahalagahan ng lahat ng mga sub-bahagi.
Iminungkahi ng Google na ang kabuuang oras ng LCP ay dapat hatiin gamit ang TTFB at oras ng pagkarga ng mapagkukunan na nagkakahalaga ng humigit-kumulang 40% habang ang mga pagkaantala sa pagkarga ng mapagkukunan at pag-render ng elemento ay dapat na nagkakahalaga ng mas mababa sa 10%.
Sa isip, ang huling dalawa na ito ay dapat na malapit sa zero hangga't maaari at unahin kaysa sa iba pang dalawang yugto.
May dalawang paraan para makatulong na mabawasan ang pagkaantala ng pagkarga ng mapagkukunan nang malapit sa zero hangga't maaari:
Sasabihin namin ito kaagad, inirerekomenda namin na kumonsulta ka muna sa iyong web developer bago pag-usapan ang mga pag-aayos na ito. Ito ay isang backend operation at nangangailangan ng isang bihasang kamay upang mapagana ito ayon sa ninanais.
Pagtuklas ng mapagkukunan
Ang bawat web browser ay may kasamang preload scanner, na ang trabaho ay tulungan ang pangunahing HTML parser ng browser sa pagtukoy ng nilalaman ng pahina.
Bagama't pinoproseso ng pangunahing HTML parser ang raw markup hanggang sa tumakbo ito sa isang blocking resource — tulad ng isang script na walang async o defer attribute, ang preload scanner ay may mas speculative na papel.
Sa madaling salita, ang preload scanner ay naghahanap ng mga resources na kukunin bago pa man makarating ang pangunahing HTML parser sa kanila at patuloy na gagana kahit na naharang ang parser. Maaaring gamitin ang preload scanner upang mahanap at mai-load ang LCP nang malapit hangga't maaari sa unang kahilingan ng pahina.
Para matiyak na matutuklasan ang LCP resource mula sa HTML source, may mga opsyon na partikular sa asset ang mga developer.
Halimbawa, kung ang LCP ay isang imahe, ang mga katangian nito na src o srcset ay kailangang nasa source code. Samantala, ang mga imahe sa background ng CSS ay maaaring i-preload sa pamamagitan ng pagsasama ng sa HTML markup o sa header. Panghuli, ang mga font ay maaaring i-load sa parehong paraan sa pamamagitan ng .
Gayunpaman, mahalagang tandaan na ang paggamit ng preloading upang mabawasan ang oras ng pag-load ng LCP ay maaaring magdulot ng mga bagong problema, tulad ng pag-aalis ng prayoridad sa mga async element. May dahilan kung bakit iminumungkahi naming makipag-usap sa iyong developer tungkol dito.
Para sa karagdagang impormasyon tungkol sa paksang ito, tingnan ang malalimang pagsusuri ng Google sa parehong LCP optimization at preload scanner .
Prayoridad ng mapagkukunan
Sinusubukan ng mga browser na i-download ang mga CSS, font, script, image, at iframe asset nang pinakamahusay hangga't maaari sa pamamagitan ng pagtatalaga ng prayoridad. Mahusay ang mga browser sa pagtukoy ng mga prayoridad ng asset, ngunit hindi ibig sabihin nito ay perpekto ang mga ito.
Para ma-optimize ang pagbibigay-priyoridad sa asset, maaaring gumamit ang mga developer ng markup-based Priority Hints para magbigay ng senyales sa mga browser kung aling mga asset ang may mas mataas na priyoridad. Halimbawa, maaaring gamitin ng isang developer ang JavaScript at ang Fetch API para i-tag ang LCP image gamit ang fetchpriority=”high” HTML attribute, na nagpapabilis sa partikular na CWV metric na iyon.
Mahalagang tandaan na ang Priority Hints ay gumagana lamang sa mga browser na nakabase sa Chromium , tulad ng Google Chrome at Microsoft Edge.
Maaaring naipatupad na ng iyong developer ang lazy loading para sa mga asset na nasa ilalim ng fold, kaya makipag-ugnayan sa kanila para makasiguro, ngunit sulit din na ipagamit sa kanila ang Priority Hints para sa mga asset na nasa itaas ng fold.
Para sa karagdagang impormasyon tungkol sa priority loading, lubos naming inirerekomenda na tingnan ang gabay ng Google sa resource loading .
Nagamit ng dev team ng higanteng search engine ang Priority Hints upang mapabuti ang LCP mula 2.6 segundo patungong 1.9 segundo sa isang pagsubok sa Google Flights.
Sinusubaybayan ng FID kung gaano katagal bago masimulan ng browser ng user ang pagproseso ng unang input — hindi kasama ang pag-scroll at pag-zoom.
Ang hakbang na ito ay tungkol sa pagkuha ng karanasan ng gumagamit sa pakikipag-ugnayan sa isang web page, ibig sabihin ay mababa ang magiging marka ng mga mabagal na web page. Ang target ay panatilihing mababa sa 100 milliseconds ang markang FID na iyon.
Ang mahinang pagtugon ay karaniwang dahil sa labis na paggamit ng JavaScript, na pinoproseso ng mga browser bago ang mga input.
Ang code na kumukunsumo ng pokus ng browser sa loob ng 50 milliseconds o higit pa ay tinatawag na Long Task at itinuturing na senyales ng paglobo ng JavaScript. Ang paghahati-hati sa mga Long Task na ito sa mas maliliit na bahagi ng code ay maaaring makatulong sa paglutas ng mabagal na performance at pagbutihin ang FID.
Ngunit hindi lamang iyan ang dapat pag-usapan sa iyong developer. Mahalagang talakayin kung paano maaaring mapabagal ng pagpapatupad ng first-party at third-party script ang iyong site. Ang progresibong paglo-load ng code at mga feature ay makakatulong sa pagtugon sa mga hamon ng nauna, habang ang on-demand loading at load prioritization ay makakatulong sa huli.
Ang isa pang pagpipilian ay ang paggamit ng mga web worker upang patakbuhin ang JavaScript sa background at maiwasan ang pagkabara ng iyong browser sa pagproseso ng mga script.
Ang CLS ay karaniwang isang sukatan ng visual stability ng iyong website. Kung mawawala ang pwesto ng iyong mga bisita sa isang pahina dahil sa paglilipat ng nilalaman upang magbigay-daan sa paglo-load ng mga ad at larawan, mababa ang magiging marka ng iyong site.
Mas mababa ang pagtalbog-talbog ng layout ng iyong pahina, mas mataas ang iyong CLS score. Hinuhusgahan ng Google ang mga website sa pamamagitan ng pagsasaalang-alang sa pagkagambala sa loob ng viewport pati na rin kung gaano kalayo ang narating ng mga asset kumpara dito.
Ang pagbabawas ng mga hindi inaasahang pagbabago sa layout ay karaniwang umiikot sa pagtatalaga ng espasyo para sa mga ad, larawan, at naka-embed na video.
Natatandaan mo pa ba ang src o srcset na tiningnan natin noong pinag-uusapan natin ang tungkol sa resource discovery? Napakahalaga nito sa pagpapabuti ng mga marka ng CLS.
Para sa mga static na imahe, itakda ang lapad at taas gamit ang mga src attribute upang sabihin sa browser na magreserba ng espasyo para sa mas mabagal na paglo-load ng mga asset, sa gayon ay maiiwasan ang mga pagbabago sa layout.
Tingnan ang halimbawang code mula sa Google sa ibaba:
Ang mga responsive na imahe ay nangangailangan ng isang srcset upang tukuyin ang pinakamataas na limitasyon sa lapad at taas na maaaring piliin ng browser. Tiyaking gumagamit ka ng mga imaheng may parehong aspect ratio.
Narito ang isa pang halimbawa:
Kapag nakikitungo sa mga ad, may ilang hakbang na maaari mong gawin:
Ipinapayo rin ang pagreserba ng static space kung balak mong ipatupad ang mga iFrame, embedded content, at dynamic content, tulad ng mga call to action (CTA).
Kapag nagda-download at nagre-render ang mga browser ng mga web font, may posibilidad na magkaroon ng alinman sa isang flash ng unstyled text (FOUT) o isang flash ng invisible text (FOIT). Nangyayari ang una kapag ang isang fallback font ay pinapalitan ng isang bagong font, habang ang huli ay resulta ng isang pagkaantala sa pag-render ng isang bagong font.
Maaari mong malutas ang parehong problema gamit ang para sabihin sa preload scanner na kunin nang mas maaga ang mga web font. Mas malaki ang tsansa ng mga preloaded na font na matugunan ang unang pintura.
May iba pang mga solusyon sa gabay sa pag-troubleshoot ng CLS pati na rin ang malalimang pagtalakay nito sa paggamit ng preload upang maiwasan ang FOIT .
Kung naghahanap ka ng mga paraan para mapabilis ang site at gumagamit pa rin ng tradisyonal na opsyon sa single-server hosting, malamang na panahon na para isaalang-alang ang paglipat sa content delivery network (CDN).
Ang isang CDN ay binubuo ng isang network ng mga server na matatagpuan sa iba't ibang data center sa buong mundo na namamahagi ng nilalaman ng website upang mapabuti ang pagganap. Bagama't ang isang opsyon sa server — na kilala rin bilang local hosting — at CDN ay naghahatid ng nilalaman ng website sa mga bisita, tanging ang CDN lamang ang maaaring isaalang-alang ang lokasyon ng gumagamit at pagkatapos ay pumili ng pinakamalapit na server upang mabawasan ang oras ng pagkarga.
Gayunpaman, hindi lamang ang heograpiya ang bentahe, dahil ang mga CDN ay mas mahusay din sa kagamitan upang pamahalaan ang mga biglaang pagtaas ng trapiko pati na rin ang mga mapagkukunan ng root server tulad ng bandwidth.
Sa huli, ang mas mabilis na karanasan sa pag-browse ay nagpapadala ng malakas na signal ng CWV sa Google. Bagama't ang Cloudflare ay isa sa mga pinakakilalang provider ng CDN sa merkado, mayroong ilang seryosong kakumpitensya na dapat isaalang-alang .
Anuman ang hosting provider na iyong ginagamit, ang kanilang mga server ay sasailalim sa ilang mga limitasyon sa hardware.
Ang mga server ay kadalasang naglalaman ng parehong mahahalagang bahagi na nagpapahintulot sa iyong laptop/desktop na gumana — katulad ng CPU at RAM — na siyang humahawak sa lahat ng gawain ng iyong account. Dapat mong magamit ang dashboard ng iyong hosting provider upang suriin ang CPU at RAM na naka-install sa iyong server at maaari ka ring humiling ng karagdagang mga mapagkukunan upang mapalakas ang pagganap ng iyong site.
Kung titingnan mo ang CPU ng iyong server, mahalagang maunawaan na iisang core lamang ang ginagamit upang matugunan ang kahilingan ng isang bisita para sa isang web page. Nangangahulugan ito na ang mas mabilis na single-core clock speed ay palaging isang mahalagang bahagi. Ang mga multi-core CPU ay kayang magproseso ng maraming page view at iba pang serbisyo ng server.
Isa pa ito para sa iyong developer.
Suriin ang iyong database nang medyo madalas upang matiyak na hindi ito napuno ng mga hindi nagamit na larawan at file. Ang pagbura ng mga hindi kinakailangang file ay mag-aalis ng kalat dito, na magpapabilis sa karaniwang oras ng pagkarga ng pahina.
Ang paggamit ng napakalalaking larawan ay maaaring magpabagal at magpapabagal sa iyong website. Gaano kalaki? Anumang bagay na higit sa 1MB ay sadyang napakalaki.
At gaya ng alam na natin, ang mas mabagal na oras ng pag-load ay hahantong sa mas mataas na bounce rate at magpapadala ng mga hindi gustong signal sa Google.
Para sa mga gumagamit ng WordPress, mayroong ilang mga plugin sa pag-optimize ng imahe na mapagpipilian na maaaring magpadali sa isang nakakapagod na manu-manong gawain. Bukod dito, marami rin ang may kasamang iba pang mga tampok tulad ng lazy loading at auto-resizing.
Ang pagiging mobile friendly ng isang site o hindi ay nakasalalay sa kung pinasimple at pinahusay mo ba ang iyong site para sa karanasan sa mobile browsing.
Iba-iba ang interaksyon ng mga gumagamit ng mobile sa mga pahina at mas kaunti ang kanilang pasensya sa mabagal na oras ng pag-load at mga site na mahirap i-navigate. Kung bumagsak ang iyong site sa mobile friendly test na inilarawan sa itaas, o kahit na pumasa ito ngunit interesado ka pa sa karagdagang pag-optimize, pag-usapan natin ang ilan sa mga pinakamahusay na kasanayan.
Ito ang dapat na pangunahing alalahanin ng bawat tagapaglathala. Ang isang simpleng paraan upang matugunan ang kadalian ng paggamit ay ang magtanong sa iyong sarili ng mga bagay tulad ng:
Malaki ang maitutulong ng mga sagot na ito sa pagtukoy ng mga problema ng user. Halimbawa, hindi mo gugustuhing i-adjust ng iyong mga user ang kanilang mga screen para makita ang iyong content. Makikita mo ang ibig naming sabihin sa halimbawa sa ibaba.
Para ma-optimize ang iyong nilalaman para sa mga mobile device, mayroong tatlong opsyon sa pagbuo:
Inorder namin ang mga ito para sa kadalian ng pagpapatupad at inirerekomenda namin ang paggamit ng responsive na disenyo, dahil ito ang pinakasimple sa tatlong opsyon.
Idinaragdag lang ng mga developer ang meta name=”viewport” tag sa umiiral na code ng isang web page
Ang bentahe rito ay kailangan mo lang magpanatili ng isang website, na madaling maipakita sa anumang uri ng screen.
Sa kabaligtaran, ang mga dynamic na disenyo ay gumagana sa pamamagitan ng paghahatid ng iba't ibang HTML code batay sa device ng user. Kailangang gamitin ng mga page ang Vary HTTP header upang maiwasan ang maling code na maihatid sa maling device.
Panghuli, may mga mobile subdomain, na hindi namin ipinapayo dahil sa dami ng mga resources na kinakailangan upang maipatupad nang epektibo. Ang mga mobile subdomain ay ganap na magkakahiwalay na mga site na naghihiwalay sa mga pangangailangan sa hosting. Upang matiyak na nauunawaan ng mga crawler ang ugnayan sa pagitan ng domain at subdomain, kakailanganin mong isama ang rel=”canonical” tag.
Dahil ang mga responsive na disenyo ang pinakasimpleng opsyon, ito ang aming inirerekomenda para sa mga publisher. Para sa mas masusing pagtingin sa responsive na disenyo, tingnan ang gabay sa pagpapatupad ng Google .
Narito ang isang mabilis na listahan ng mga teknikal na konsiderasyon para sa anumang disenyo:
Ang huling hakbang na ito ang pinakasimpleng paraan upang mapabuti ang karanasan sa pahina, ngunit malaki rin ang maitutulong nito sa pagpapabuti ng kapanatagan ng loob ng iyong user.
Ang paglipat sa HTTPS ay nagpoprotekta at nag-e-encrypt ng impormasyon ng iyong mga user, at nakakatulong din ito upang maiwasan ang mga pag-atake ng Man in the Middle (MitM). Bukod pa rito, ang pagkakaroon ng SSL certificate ay nag-aalis ng mga babala sa browser tungkol sa kakulangan ng seguridad.
Dapat talaga ay kaya ng iyong hosting provider na magbigay sa iyo ng seguridad sa HTTPS, kung hindi pa nito kaya, maaaring sulit na isaalang-alang ang paglipat sa isa na nagbibigay nito. Mayroon nang ilang kilalang hosting provider na nagbibigay ng libreng HTTPS . Bukod dito, ang mga hosting provider na nagbibigay ng mga SSL certificate ay gumagamit ng sarili nilang serbisyo sa halip na ang panlabas na serbisyo, na ginagawang mas madali at mas mabilis ipatupad ang proseso.
Kung gusto mong humiling at mag-install ng SSL certificate mula sa mga Certificate Authorities (CA), may apat na hakbang na kailangan mong sundin. Ito ang mga sumusunod:
Mahalagang tiyakin na kapag inililipat ang iyong site sa HTTPS ay hindi nito maaapektuhan ang iyong diskarte sa kita ng ad. Ang isyu ay ang isang HTTPhindi gagana sa isang site na gumagamit ng HTTPS.
Pinapayuhan namin kayo na kumonsulta sa inyong mga ad tech partner bago gumawa ng anumang pagbabago sa inyong site.
Para sa karagdagang detalye, tingnan ang komprehensibong gabay ng Google tungkol sa paksang ito.
Ang mga nakakaabala na interstitial ad at dialog box ay nagpapahirap sa mga search engine na maunawaan ang nilalaman ng isang web page, na maaaring makaapekto sa performance ng SERP.
Maganda sana kung may paraan para lumikha ng mga interstitial na hindi makakaabala sa karanasan ng user, pero iyon ang buong punto ng mga ganitong ad. Sinasakop nila ang buong screen kapag may mga pahinga sa content para makuha ang atensyon ng user.
Dahil dito, mas makabubuti sa mga publisher na gumamit ng mga banner ad sa halip na mga interstitial ad, dahil maliit na bahagi lamang ng espasyo sa screen ang sakop ng mga ito. Mas mainam na ipagsapalaran ang pagkabinala sa banner kaysa sa pagkadismaya ng mga user.
Maaaring gumamit ang mga publisher ng mga banner na sinusuportahan ng browser o mga simpleng HTML banner na naka-link sa destination page ng CTA.
Maaari ring gamitin ang mga dialog box para sa mga promotional campaign, ngunit maaaring idisenyo ang mga ito upang maging hindi nakakaabala. Kailangan mong tiyakin na maa-access ng mga user ang nilalaman nang walang pagkaantala.
Walang tunay na mga shortcut sa pag-optimize ng karanasan sa iyong pahina at mahalagang ayusin mo ang mga puntong nasa itaas. Gayunpaman, mahalagang ituro na habang ang WordPress ang pinakasikat na platform ng pag-publish sa mundo, hindi ito nangangahulugang ito ang pinakamahusay na CMS pagdating sa pagpapahusay ng pagganap ng CWV.
Kung titingnan ang CWVs Technology Report, makikita na nasa 29% lamang ng mga website ng WordPress ang may magagandang CWV, habang 41% naman ng mga site ng Wix ang may berdeng tsek.
Mahalagang pag-isipan kung ang paglipat sa isang espesyalisadong CMS ay maaaring makatulong sa pagpapabuti ng iyong mga CWV nang natural.
Maraming kailangang gawin pagdating sa pag-optimize ng karanasan sa pahina at maaaring medyo mahirap magsimula. Gayunpaman, mahalagang tandaan na makakatakas ka sa puntong ito sa pamamagitan ng isang kagat lang.
Hindi kinakailangan ang pagpuntirya ng isang "Magandang" marka sa lahat ng iyong mga sukatan ng CWV upang matulungan ang iyong site na umakyat sa mga SERP. Gayunpaman, higit pa riyan, ang pagtatakda ng gayong matataas na layunin ay maaaring maging kontra-produktibo dahil maaari itong maging isang nakapanghihina ng loob na hangarin.
Sa halip, sikaping makamit ang maliliit na tagumpay pagdating sa iyong mga CWV, tumuon sa pagtugon sa mga resultang "Hindi maganda" nang hindi masyadong nababahala tungkol sa "Kailangan ng pagpapabuti". Maaari itong mangyari sa ibang pagkakataon, kapag mayroon ka nang mas maraming oras at mapagkukunan na mailalaan sa proseso.
Napag-usapan na natin ang tungkol sa pinabuting CLS score ng Yahoo! JAPAN, tingnan natin ang ilan pang mga site na maaari nating matutunan.
Ang pahayagang Indian na The Economic Times, na nagsisilbi sa mahigit 45 milyong aktibong gumagamit kada buwan, ay nagbawas ng CLS score nito ng 250% mula 0.25 patungong 0.09 at ng LCP time nito ng 80% mula 4.5 segundo patungong 2.5 segundo.
Sa pagitan ng Oktubre 2020 at Hulyo 2021, binawasan ng publisher ang mga marka ng LCP sa hanay na "Mahina" ng 33%, habang ang mga halaga ng CLS sa hanay na "Mahina" ay bumaba ng 65%. Ang mga pagtaas na ito ay nagbigay-daan sa The Economic Times na malampasan ang mga threshold ng CWV sa buong pinagmulan nito habang binabawasan ang pangkalahatang bounce rate ng 43%.
Nakamit ito ng publisher sa iba't ibang paraan, kung saan ang una sa mga ito ay ang pagbibigay-priyoridad sa pag-download ng asset gamit ang Priority Hints. Tinalakay din nito ang Mahahabang Gawain, na pinaghiwa-hiwalay ang mga piraso ng code upang matiyak na ang mga mahahalagang resources para sa above the fold page rendering ang unang nalo-load.
ng website ng balita sa UK ang CLS score nito mula 0.25 patungong 0.1 , habang pinapataas ang bilang ng mga URL na nakatanggap ng passing grade mula 57% patungong 72%.
Ginamit ng Telegraph ang Chrome DevTools upang tukuyin ang mga indibidwal na pagkakataon ng paglilipat ng layout.
Bago noon, gamitin ang WebPageTest upang malaman kung saan sa timeline naganap ang pagbabago ng layout.
Gamit ang datos na ito, sinimulan ng pangkat na ituon ang pansin sa pagbabawas ng mga pagbabago sa layout sa pamamagitan ng pagtugon sa mga aspetong ito
Para sa mga patalastas, sinimulan ng The Telegraphed na maglaan ng espasyo para sa mga ito at ginamit ang pinakakaraniwang laki ng patalastas upang tukuyin ang mga dimensyon. Nakatulong din ito upang mapigilan ang pagguho ng mga patalastas kapag tiningnan sa isang tablet.
Hinarap ng pangkat ang katulad na isyu sa mga inline na larawan sa itaas ng mga artikulo, na walang tinukoy na mga sukat.
Gumawa ang Telegraph ng iba pang mga pagsasaayos, tulad ng paglipat ng header sa itaas ng markup at paggamit ng mga placeholder para sa mga naka-embed na video, ngunit sa huli ay inilarawan ang proseso bilang "medyo madali" habang mayroon pa ring malaking epekto.
Hindi kailangang maging napakalaki ng problema sa pagpapabuti ng karanasan sa pahina. Sukatin ang apat na haligi ng karanasan sa pahina at pagkatapos ay magpasya kung anong mga mapagkukunan ang maaari mong ilaan upang mapabuti ang iyong mga resulta.
Kung ikaw ay isang maliit na publisher, ang pagbabalanse ng mga mapagkukunan ay magiging mahalaga at inirerekomenda namin ang pagtukoy ng medyo madaling gamiting solusyon para sa iyong unang proyekto.
Kung titingnan ang pamamaraan ng Telegraph, nakatuon sila sa isang aspeto ng mga CWV sa halip na sa lahat ng tatlo at nakagawa ng mga makabuluhang pagpapabuti. Nakatuon ang Economic Times sa dalawa sa tatlo upang maghatid ng ilang kahanga-hangang resulta.
Aktibo ngayon
Tingnan ang higit pa
