Pag-aayos ng Mabagal na LCP Image

Ayusin ang mabagal na Largest Contentful Paint (LCP) na larawan sa 4 na hakbang: baguhin ang sukat sa laki ng display nito, i-convert sa WebP o AVIF, i-preload ito, at itakda ang fetchpriority sa high. Ang unang 2 hakbang ang nagbibigay ng pinakamalaking pagpapabuti nang hindi binabago ang markup ng iyong page.

Sa karamihan ng mga page, ang element ng largest contentful paint ay iisang hero image, ibig sabihin ang LCP ay tungkol talaga sa isang file kaysa sa buong site mo. Ang pag-aayos sa iisang file na iyon ay karaniwang nagpapabuti sa sukatan nang higit kaysa sa anumang iba pang available na pag-optimize.

Ano ang sinusukat ng LCP

Itinatala ng LCP kung gaano katagal bago mag-render ang pinakamalaking nakikitang element, sinusukat mula sa pagsisimula ng pag-load ng page. Itinuturing ng Google ang 2.5 segundo o mas mabilis bilang mahusay, 2.5 hanggang 4 na segundo bilang nangangailangan ng pagpapabuti, at higit sa 4 na segundo bilang mahina.

Ang sinusukat na element ay karaniwang larawan, kung minsan ay isang block ng heading text, at palaging isang bagay na nakikita nang hindi nag-i-scroll. Maaaring magbago ang element depende sa device, dahil ang hero image na nangingibabaw sa layout ng desktop ay maaaring mapunta sa ibaba ng fold sa isang telepono.

Pagtukoy sa may pananagutang element

Ipatakbo ang Lighthouse at basahin ang entry ng Largest Contentful Paint element, na tumutukoy sa eksaktong sinusukat na element. Sayang sa oras ang panghuhula, dahil madalas na hindi ito ang inaakala ng marami.

Suriin sa mobile pati na rin sa desktop, dahil magkaiba ang mga layout at gayundin ang sagot. Mas maaasahan ang field data mula sa mga totoong bisita kaysa sa iisang takbo sa laboratoryo, dahil mas nag-iiba ang mga kondisyon ng network sa totoong paggamit kaysa sa pagsubok. Kung hindi magkatugma ang 2, pagkatiwalaan ang field data at gamitin ang pagsusuri sa laboratoryo para sa diagnosis.

Ayusin ang larawan ayon sa antas ng epekto

Upang mapabuti ang LCP sa isang larawan, sundin ang 6 na hakbang na ito ayon sa pagkakasunod-sunod.

1. Baguhin ang sukat ng larawan sa pinakamalaking laki na ipapakita nito, dinoble para sa mga high density screen.
2. I-convert ito sa WebP, o sa AVIF kung malaki ang larawan at isang litrato.
3. I-compress sa target na mas mababa sa 200 KB para sa isang hero image, na kayang makamit sa buong lapad sa karamihan ng mga disenyo.
4. Magdagdag ng mga attribute na width at height upang magreserba ng espasyo ang browser at maiwasan ang layout shift.
5. I-preload ang larawan sa page head upang simulan agad ng browser ang pag-fetch nito.
6. Itakda ang fetchpriority sa high sa element ng larawan, na nagpapahiwatig sa browser na ang file na ito ang pinakamahalaga.

Karaniwang naghahatid ang mga hakbang 1 at 2 ng pinakamalaking pagpapabuti, at ang 2 ito ay hindi nangangailangan ng pagbago sa mismong markup ng page.

Bakit mas epektibo ang pagbabago ng sukat kaysa pag-compress

Sukat ang kumokontrol sa halos buong laki ng file, kaya mas maraming binabawas na bigat ang pagbabago ng sukat kaysa sa anumang setting ng kalidad. Ang 4000 pixel na litrato na ipinapakita sa 1200 pixels ay naglalaman ng 11 beses na mas maraming pixel data kaysa sa kayang ipakita ng page.

Ipinapakita ng ikatlong hilera kung bakit unang dapat gawin ang pagbabago ng sukat. Mas maganda ang resulta ng pagbabago lamang ng sukat kaysa sa pag-compress lamang, at mas mahusay ang pinagsamang dalawa. Nag-iiba ang mga numero ayon sa larawan at koneksyon, habang nananatiling pareho ang pagkakasunod-sunod.

Preload at fetchpriority

Sinasabihan ng preloading ang browser na i-fetch ang hero image bago pa matapos ang pag-parse sa page, na karaniwang nakakatipid ng 200 hanggang 500 milliseconds. Mahalaga ang setting dahil huli nang natutuklasan ng mga browser ang mga larawan sa proseso ng pag-parse.

Mag-preload ng isang larawan lamang. Nawawala ang benepisyo kung magpe-preload ng marami, dahil paghahati-hatian lang din ng browser ang pansin nito. Ang pagtakda ng fetchpriority sa high ay nagbibigay ng katulad na resulta nang may mas kaunting markup at kadalasang sapat na mag-isa para sa larawang nasa orihinal na HTML na.

Mga pagkakamaling nagpapalala sa LCP

• Pag-lazy load sa hero image. Inaantala ng lazy loading ang mismong file na kailangan mo nang una. Ilapat lamang ito sa ibaba ng fold.
• Pag-load ng hero sa pamamagitan ng JavaScript. Ang larawang isiningit gamit ang script ay hindi makakapagsimulang mag-download hanggang sa tumakbo ang script.
• Paggamit ng CSS background image. Mas huling natutuklasan ang mga background image kaysa sa mga img element at hindi gaanong mabibigyan ng prayoridad.
• Pag-preload ng maraming larawan. Nawawalan ng silbi ang bentaha dahil sa nagtatalong mga prayoridad.
• Pagtanggal ng width at height. Sinisira ng layout shift ang isa pang hiwalay na sukatan habang bumubuti naman ito.

Kapag text ang LCP element

Karaniwang naaantala ang LCP na nakabatay sa text dahil sa mga web font sa halip na sa mismong teksto. Hawak na agad ng browser ang mga salita at naghihintay lang ito ng font file bago i-paint ang mga ito.

Itakda ang font-display sa swap upang mag-render ang teksto gamit ang isang fallback font at lilipat kapag dumating na ang web font. I-preload ang nag-iisang pinakamahalagang font file, at i-subset ang font sa mga character lamang na talagang ginagamit ng iyong mga page, na madalas nagpapaliit sa font mula 200 KB tungong mas mababa sa 30 KB. Ang pag-serve ng mga font mula sa sarili mong domain ay nag-aalis ng karagdagang koneksyon sa third party.

Ang response time ng server ang nagtatakda ng limitasyon

Hindi maaaring maging mas mabilis ang LCP kaysa sa oras na inaabot ng iyong server upang ibalik ang unang byte, kaya nililimitahan ng mabagal na server ang bawat iba pang pagpapabuti. Targetin ang mas mababa sa 600 milliseconds para sa unang byte.

Suriin ang numerong iyon bago mag-optimize ng mga larawan, dahil ang 2 segundong tugon ng server ay nagiging dahilan upang maging imposible ang 2.5 segundong target ng LCP anuman ang gawin mo sa mga file. Tinutugunan ng caching, mas mabilis na host, o content delivery network ang bahaging iyon. Pagkatapos nito, pinapabuti ng pag-aayos sa larawan ang natitira sa halip na labanan ang limitasyong naitakda sa ibang lugar.

Inaantala rin ng mga third party script ang larawan

Nakikipag-agawan sa bandwidth at processing time ng iyong hero image ang analytics, mga consent banner, chat widget, at advertising script. Ang isang larawang ganap na na-optimize ay mahuhuli pa ring mag-render kapag may 12 script na unang naglo-load bago ito.

Ang mga consent banner ang pinakamapaminsala, dahil marami sa mga ito ang humaharang sa pag-render hanggang sa pumili ang bisita. I-load ang mga third party script gamit ang defer o async attribute upang hindi maantala ang page, at suriin kung ilan ang talagang kailangan. Ang pag-alis sa 3 hindi ginagamit na tracking script ay kadalasang nagpapabuti sa LCP nang higit kaysa sa karagdagang pag-compress ng larawan.

Wastong pagsubok sa pagbabago

Subukan sa isang private window na naka-disable ang mga extension, at patakbuhin ang pagsukat nang 3 beses sa halip na magtiwala sa iisang resulta. Kapansin-pansin ang pagkakaiba ng mga score sa bawat pagtakbo.

Tiyaking natanggap talaga ng browser ang mas maliit na file. Buksan ang developer tools, pumunta sa Network tab, i-filter ayon sa images, at i-reload. Makikita sa listahan ang inilipat na laki at ang format. Kapag inihahatid pa rin ng page ang lumang file, kadalasang nangangahulugan ito na hawak pa ng caching layer ang nakaraang bersyon at hindi dahil nabigo ang pag-optimize.

Pagpapanatiling mabilis ng LCP pagkatapos ng pag-aayos

Magtakda ng panuntunan para sa mga hero image sa halip na isa-isahing ayusin ang mga ito, dahil ibinabalik ng mga bagong page ang problema. Babagal muli sa loob ng ilang buwan ang isang site na naayos na kung mag-a-upload ang mga editor nang direkta mula sa camera.

Magkasundo sa pinakamalaking lapad at pinakamalaking laki ng file para sa mga hero image, isulat ito, at ilapat sa bawat bagong page. Ang panuntunang tulad ng 1920 pixels ang lapad at mas mababa sa 200 KB ay madaling suriin at sumasaklaw sa halos bawat disenyo. Kung maraming tao ang nagpa-publish, mas mahalaga ang nakasulat na panuntunan kaysa sa mismong paraan, dahil sinasalamin ng sukatan ang pinakamalalang page sa halip na ang pinakamahusay.

Paghahanda ng mga hero image sa isang bagsakan

Iproseso nang sabay-sabay ang bawat hero image sa site, dahil magkakapareho ang mga ito ng espesipikasyon at target na laki. Karamihan sa mga site ay may 10 hanggang 100 sa mga ito sa mga landing page, category page, at artikulo.

Itakda ang lapad at ang target na KB nang isang beses, i-drop ang mga larawan, at babalik ang bawat file na tugma na. Hanggang 500 larawan ang kayang iproseso bawat batch, buong tumatakbo sa loob ng iyong browser sa sarili mong processor. Walang ina-upload, kaya ang mga staging asset, hindi pa nai-publish na campaign page, at gawaing pangkliyente ay nananatili sa iyong computer habang inihahanda ang buong library.