Pēdējo gadu laikā esam vērojuši, kā mārketinga speciālisti ielādes ātrumu izvirza katra optimizācijas procesa priekšgalā. 2017. gadā Google sāka uzsvērt ielādes ātruma nozīmi un tā nākotnes ietekmi uz ranžēšanu, taču tikai 2018. gada vasarā Google oficiāli to apstiprināja.
Ar šo rakstu vēlamies palīdzēt jums patstāvīgi sākt optimizēt un uzlabot savas vietnes ielādes ātrumu. Tāpat kā jebkuram optimizācijas procesam, arī šim ir tehniskā puse, kas var kļūt sarežģīta. Rakstot šāda veida rakstu, mēs komandā "SEO Alive" vēlamies, lai jūs to varētu īstenot paši, lai gan dažas darbības prasa augstāku tehnisko zināšanu līmeni. Tomēr, godīgi sakot, netrakosim, dzenoties pēc punktiem rīkos, kurus izmantosim savas vietnes WPO auditam.
Optimizācija lielā mērā ir atkarīga no tā, kā tika veidota veidne, un ne katra veidne ļauj sasniegt vienādu veiktspēju. To ir svarīgi paturēt prātā.
Sāksim!
Kas ir WPO?
Tīmekļa veiktspējas optimizācija (angļu val. Web Performance Optimization), ko saucam par WPO, vienkārši ir dažādu procesu optimizēšana, kas ietekmē vietnes ielādi.
Kā izmērīt vietnes ielādes ātrumu?
Ielādes ātruma mērīšanai ir daudz rīku. Populārākie no tiem:
Pirms sākt auditu, ir svarīgi paturēt prātā, ka ielādes ātrums katram lietotājam atšķiras. Dažādi mainīgie lielumi var ietekmēt to, kā ātrumu izjūt lietotājs Kvenkā salīdzinājumā ar lietotāju Otavā.
Tāpēc, tā vietā, lai strādātu ar ielādes laiku sekundēs, iesakām koncentrēties uz šo lietu optimizēšanu:
›
Vietnes svars (MB)
›
Pieprasījumi
›
Servera atbildes laiks
Ja uzlabosim šīs 3 jomas, ielādes ātrums uzlabosies neatkarīgi no tā, kur atrodas lietotājs.
Iedziļināsimies katrā jomā un ar dažādu rīku palīdzību redzēsim, kā ar tām strādāt, lai uzlabotu katra URL veiktspēju. Kāpēc saku "katra URL"? Tāpēc, ka, lai gan tas var šķist pašsaprotami, esmu saskāries ar daudziem gadījumiem, kad tika izvērtēti tikai sākumlapas dati, un, protams, ne katra vietnes lapa ielādē vienus un tos pašus resursus.
Google izstrādātāju rīki
Pirms sākam, vēlos paskaidrot dažas iespējas, ko Google piedāvā ar saviem izstrādātāju rīkiem. Šis rīks ir viens no svarīgākajiem, analizējot, kā darbojas vietne. Ar peles labo pogu noklikšķiniet uz pārlūkā atvērtās lapas, un parādīsies panelis ar dažādām iespējām. Dosimies uz "Inspect" (Ctrl + Shift + I).
Kad šis rīks ir atvērts, dosimies uz NETWORK iespēju, kuru atradīsiet augšā. Ja pārlūkā vēlreiz nospiedīsim ENTER, rīks parādīs dažādo resursu ielādi.
ielādes laiks Google izstrādātāju rīkos
Attēla apakšā redzam datus, kas mūs interesē, lai gūtu vispārēju priekšstatu par to, kā vietne ielādējas.
Iedziļinoties šajā panelī no augšas un aplūkojot kolonnu struktūru, mums ir:
›
Name: resursa nosaukums.
›
Status: resursa atbildes kods (200, 301, 404...)
›
Type: resursa veids (script, font, png, jpg, stylesheet...)
›
Initiator: kurš resurss izraisa pieprasījumu.
›
Time: cik ilgi ilga pieprasījums.
›
Waterfall: grafisks resursa ielādes laiku attēlojums.
Ja augšā noklikšķinām ar peles labo pogu, varam pievienot un noņemt kolonnas ar šo informāciju.
informatīvo elementu pievienošana un noņemšana sadaļā "network"
Papildu informatīvo elementu, piemēram, Domain, Scheme vai Cookies, iespējošana atsevišķos gadījumos var palīdzēt atrast resursus, kas mums varētu radīt kāda veida problēmas, taču pagaidām iztiksim ar tiem, kas ir iepriekš noteikti.
Ir viens aspekts, kuru, lai gan ļoti interesantu, šeit pieskaršos tikai virspusēji, lai to paturētu prātā. Savienojuma ātrums, īpaši mobilajās ierīcēs, ir svarīga vietnes ielādes daļa. No šī rīka varam imitēt lēnāku ātrumu, piemēram, 3G mobilajā ierīcē.
lēna pārsūtīšanas ātruma imitēšana
Kā uzzināt URL svaru un kā to samazināt?
Svars, vai tas būtu megabaitos vai kilobaitos, ir viens no galvenajiem iemesliem, kāpēc URL ielāde aizņem laiku. Tāpēc sākam, iedziļinoties šajā aspektā, jo tas iezīmēs ceļu labas mūsu vietnes optimizācijas sasniegšanai.
Turpmāk minētie dati ir no iepriekš minētā rīka GTMETRIX un atbilst vietnei, kuru drīzumā sākšu optimizēt.
vietnes svara rādītāji
Koncentrēsimies uz labās kolonnas datiem, tiem, kas attiecas uz (Page Details), konkrēti Total Page Size.
No pirmā acu uzmetiena šīs vietnes svars ir krietni virs vidējā, taču paturiet prātā, ka svarīgs ir nevis vietnes kopējais svars, bet gan cik ilgi šis svars aizņem ielādei, jo pastāv kaut kas, ko sauc par Lazy Load – funkcija, kas atliek ielādi, līdz lietotājam resurss ir vajadzīgs. Par to runāsim vēlāk.
Šo informāciju varam atrast arī izstrādātāju rīkos, tajā panelī, ko aplūkojām iepriekš un kuru jums vēlreiz atgādināšu.
ielādes laiks Google izstrādātāju rīkos
Ja paskatīsieties uz apakšu, gan 7,5 MB, gan 215 pieprasījumi ir ļoti tuvi GTMETRIX uzrādītajiem skaitļiem. Jums ir svarīgi zināt, no kurienes GTMETRIX iegūst savu informāciju, gadījumam, ja kādreiz vēlēsieties izmantot citu rīku.
Tagad paskatīsimies, kas sver tik daudz un kā to varam labot.
Waterfall iespēja ļauj vizuāli redzēt, kā ielādējas resursi, parādot resursa URL, statusu, domēnu un Size kolonnu. Ja noklikšķinām uz pēdējās kolonnas, tā sakārto svarus no lielākā uz mazāko un no mazākā uz lielāko.
ielādes analīze ar "waterfall"
Aplūkojot svarus, redzam, kā tas notiek vairumā gadījumu, ka attēli lielā mērā ir atbildīgi par URL pārmērīgo svaru.
Nav oficiālas specifikācijas par to, kāds ir maksimālais svars, kādam vajadzētu būt attēlam, taču iesakām ne vairāk par 100 KB un, ja jums ir tāda iespēja (ja izmantojat Photoshop, tā jums ir), iestatiet, lai attēli ielādētos progresīvi kā JPG, un izvairieties no PNG vienmēr, kad jums nav vajadzīgs Alfa kanāls (caurspīdīgums).
Samazinot attēlu svaru, būtiski uzlabosim vietnes ielādi, un tam varat izmantot vairākus rīkus. Es personīgi optimizēju ar Photoshop, taču ir interesanti tiešsaistes varianti:
Gan GTMetrix, gan Google rīks ļauj apskatīt resursus pēc veida, tas ir, tikai attēlus, skriptus, CSS...
Tas ir noderīgi plašākai perspektīvai par to, kur strādāt. Šajā URL attēli veido 4 MB no 7,2 MB, tātad liela svara problēmas daļa ir tur. Tomēr ir arī citi resursi, kas savam veidam izceļas kā ārkārtīgi smagi, piemēram, CSS fails, kas pārsniedz 700 KB, un skripts, kas pārsniedz 300 KB.
Šajā brīdī vēlos precizēt, ka, veicot ielādes ātruma optimizāciju (WPO), mums jāsaskaras ar noteiktām problēmām, kuras, lai gan tām ir risinājumi, nav mūsu spēkos ietekmēt.
Šajā gadījumā redzam ļoti lielu CSS failu. Ja dizainers izveidoja CSS, kas pārsniedz 700 KB, optimizēt tieši šo failu būs grūti.
Ko varam darīt, lai samazinātu šo failu svaru?
Minificēšana (CSS, JS un HTML)
Minificēšana ir process, kas tiecas samazināt faila svaru, noņemot nevajadzīgus datus, piemēram, komentārus, atstarpes, atkārtotu kodu un neizmantotu kodu. Šī procesa veikšanai ir daudz rīku, izņemot neizmantotā koda daļu, kuru ir grūtāk optimizēt un kurai būtu nepieciešams manuāli iedziļināties failā (ko neiesaku).
Par laimi, runa ir par WordPress, un, kā mēs visi zinām, WordPress ir ļoti reti, kad neatrodam spraudni, kas veic šo darbību.
Personīgi man patīk izmantot pilnīgi bezmaksas Autoptimize un maksas WP Rocket.
Šajā rakstā nevēlos tik daudz skaidrot, kā šie spraudņi darbojas, cik to, kā veikt optimizācijas uzdevumus. Jo, ja izmantosim citus spraudņus, arī tiem ir šīs iespējas, un vislabāk ir saprast, ko darām.
Minificēšana ar WP Rocket
Šī daļa nav sarežģīta. Vienkārši dodamies uz failu optimizācijas cilni un atzīmējam "minify HTML" izvēles rūtiņu. WP Rocket šī iespēja atkārtojas zemāk CSS un JS failiem. Tomēr iesaku iespējot šo rūtiņu un izmēģināt. Atkārtojiet šo iespēju pa vienai, jo, ja kaut kas neizdodas, būs vieglāk noteikt problēmu.
HTML minificēšana ar WP Rocket
Pirms pārbaudām minificēšanas efektu, mums jāiztīra kešatmiņa, citādi neredzēsim atjauninātā HTML rezultātu.
Kā iztīrīt pārlūka kešatmiņu?
Šāda veida spraudņiem ir iespējas kešatmiņas tīrīšanai, ko redzam augšā.
kešatmiņas tīrīšana ar WP Rocket
Cits veids ir caur pārlūku, kad iespējoti Google izstrādātāju rīki (Ctrl + Shift + I).
Ar peles labo pogu noklikšķiniet uz "reload page" bultiņas un izvēlieties "empty cache and hard reload".
kešatmiņas tīrīšana no "Chrome" pārlūka
Minificēšana ar Autoptimize
Ar Autoptimize minificēšanu veic optimizācijas darbība, ar to īpatnību, ka tiek piedāvāta iespēja saglabāt HTML komentārus. Šos komentārus parasti pievieno izstrādātāji, lai saglabātu informāciju, kas nākotnē varētu būt noderīga.
HTML minificēšana ar Autoptimize
Lai pārbaudītu, vai šī optimizācija ir stājusies spēkā, dotos uz URL pirmkodu un vajadzētu ieraudzīt kaut ko līdzīgu:
minificēta HTML piemērs
Kods kļūst nesalasāms, bet tā funkcionalitāte paliek nemainīga.
Šīs iespējas WP Rocket un Autoptimize atkārtojas tāpat CSS un JS failiem. Kā minēju iepriekš, neiesaku optimizēt visu uzreiz, bet pa vienam. Šie spraudņi saglabā minificēto failu kopijas, tāpēc atgriezties pie oriģināla ir iespējams, noņemot atzīmi no attiecīgās rūtiņas.
Lai turpinātu samazināt lapas svaru, mums ir vēl 2 iespējas:
›
Noņemt vai samazināt spraudņus, kas ielādei pievieno CSS vai JS.
›
Noņemt vai apgriezt neizmantoto kodu CSS failā.
Šīs 2 iespējas ir sarežģītākas un prasa vairāk zināšanu, jo jābūt uzmanīgam un jāpārliecinās, ka no citām lapām nav izsaukumu uz daļu, kuru noņemat.
Lai gan spraudņu noņemšana ne vienmēr ir iespējama sniegtā resursa dēļ, ir spraudņi, kas ir labāk optimizēti nekā citi, tas ir, mazāk pieprasījumu un vieglāks JS. Tātad brīnišķīgajā WordPress ekosistēmā gandrīz vienmēr ir alternatīva.
Ielādes laiks pret atbildes laiku
Tagad ir laiks parunāt par pieprasījumiem, atbildes laiku un ielādes laiku. Šajā brīdī mums jāpiemin būtiska procesa daļa – serveris. Servera optimizācija parasti nav mūsu ziņā, tāpēc ir svarīgi izvēlēties efektīvu risinājumu.
Bet ejam soli pa solim.
Kas ir pieprasījums?
Pieprasījums jeb HTTP Request ir izsaukums, ko klients nosūta serverim, lai lūgtu noteiktu resursu. Pieprasījumi var sasniegt dažādus serverus.
Pieprasījumi var būt vai nu HTTP, vai HTTPS. Ja aplūkojam pieprasījuma struktūru, varam analizēt, kur rodas laika aizkave.
HTTP pieprasījuma laika analīze
HTTP pieprasījuma struktūra
Sadalīsim to, ko redzam šajā laika diagrammā.
›
Pieprasījums ir sākts, bet bloķēts vai rindā: ja bloķēšana ilgst ilgi, tas var būt vairāku iemeslu dēļ: augstākas prioritātes pieprasījumi vai daudz pieprasījumu uz šo avotu.
›
DNS Lookup: pārlūks atrisina (resolve) pieprasījuma IP adresi.
›
Connecting: laiks, kas nepieciešams, lai pieslēgtos serverim un atrisinātu pieprasījumu. Ja šis laiks ir liels, tas varētu norādīt uz tīkla problēmām, savienojuma kļūdām vai pārslogotu serveri.
›
Sending: tiek nosūtīts resursa pieprasījums.
›
Waiting: tas ir laiks, ko serveris patērē, lai atrisinātu pieprasījumu un nosūtītu atbildi; ja tas ir ilgs, serverī ir problēma.
›
Receiving: resursa saņemšana.
HTTPS pieprasījums pievieno vēl vienu soli, kas parādīts šeit.
HTTPS pieprasījuma analīze
Šie divi ekrānuzņēmumi pieder divām dažādām vietnēm – vienai neoptimizētai (HTTP Request) un otrai optimizētai (HTTPS Request).
Ja rūpīgi paskatīsieties un salīdzināsiet, lielākā atšķirība ir gaidīšanas laikā. Šādos gadījumos būtu detalizētāk jāanalizē serveris.
Servera pieprasījumi: kā varam tos samazināt?
Kā redzējām, pieprasījumu skaits ir cieši saistīts ar ielādes laiku, tāpēc pieprasījumu skaita samazināšana uzlabotu URL ielādes laikus. Veselais saprāts spēlē lomu optimizācijas procesā, kā arī zināšanas par to, vai resurss patiešām ir noderīgs lietotājam vai mūsu biznesam. Šis ir brīdis atvadīties no noteiktiem resursiem, kas neko nedod, taču ne man to izlemt.
Tomēr mums ir iespējas uzlabot pieprasījumus, pat ja šīs darbības nesniedz milzīgas pārmaiņas vietnes ielādei. Atkārtošos: vislabāk ir noņemt resursus, kas neko nedod.
CSS un JS apvienošana
Vēl viena populāra darbība, optimizējot tīmekļa lapu, ir CSS un JS resursu apvienošana, bet ko tas nozīmē?
Apvienošanas mērķis ir samazināt pieprasījumus uz faila svara pieauguma rēķina. Apvienošana nozīmē dažādu CSS vai JS resursu apvienošanu vienā.
Ja atbildes laiki ir gari, apvienošana var būt izdevīga. Ja nosūtīšanas laiki ir ļoti lēni, varbūt labāk noder cita tehnika.
Ideāli ir apvienot, ja ir labs serveris, tā mēs uzvaram abās pusēs.
Resursu apvienošana ar WP Rocket un Autoptimize
Apvienošanas darbība ar šiem spraudņiem ir tikpat vienkārša kā iepriekš. Vienkārši atzīmējam attiecīgo rūtiņu.
CSS apvienošana ar WP Rocket
WP Rocket iespējas CSS un JS apvienošanai ir vienādas; paneļi ir praktiski identiski. Kā redzam attēlā, ir rūtiņa, kurā ievadīt to failu ceļu, kurus nevēlamies apvienot.
Zem izvēles rūtiņas redzam arī piezīmi par to, ka nevajadzētu izmantot apvienošanas iespēju, ja izmantojam HTTP/2. Šis raksts sīkāk skaidro par HTTP/2.
CSS apvienošana ar Autoptimize
Autoptimize piedāvā vairāk iespēju darbam ar CSS un pieprasījumu samazināšanai. Iespējā, kuru atzīmēju, tas apvieno un brīdina par iespējamo efektu, taču galu galā tas vienmēr ir relatīvi.
Šajā pirmajā raksta daļā vēlējos paskaidrot, ko sevī ietver noteiktas pamatdarbības, tās, ko parasti redzam praktiski visos WPO optimizācijas spraudņos, taču vēl aizvien ir daudz, ko varam darīt, lai uzlabotu gan pieprasījumus, gan ielādes laikus.
Kešatmiņas konfigurēšana
Bez šaubām, kešatmiņas optimizēšana ir viena no darbībām, kurās pamanīsim vislielāko vietnes ielādes uzlabojumu. Šajā rakstā par SEO WordPress platformai paskaidroju, kā darbojas kešatmiņa. Aicinu ielūkoties, lai saprastu, kā tā darbojas.
Autoptimize un WP Rocket veic kešatmiņas darbības, taču WP Rocket sniedz pāris papildu iespējas. Vērts atzīmēt, ka spraudņi ir padarījuši šo optimizāciju par kaut ko vienkāršāku: jums ir tikai pāris iespēju, un process ir ātrs un nesāpīgs.
WP Rocket konfigurēšana
Kā redzat, WP Rocket ļauj strādāt ar 4 lietām:
›
Iespējot kešatmiņu mobilajām ierīcēm.
›
Saglabāt failus atsevišķi mobilajām ierīcēm.
›
Iespējot kešatmiņu pieteikušamies lietotājiem.
›
Norādīt laiku kešatmiņas tīrīšanai.
Atkarībā no katra projekta izvēlas, kuru iespēju atlasīt, taču, ņemot vērā to visu, mans padoms ir:
›
Mobilo kešatmiņu vienmēr, jo, lai gan lielākā daļa vietņu ir pielāgojamas (responsive), ir saturs, kas jums var būt mobilajā, bet ne datora versijā.
›
Failus atsevišķi.
›
Nekādas kešatmiņas pieteikušamies lietotājiem, galvenokārt tāpēc, ka, ja veicu labojumus, nevēlos kešatmiņu.
›
Kešatmiņas laiks, kas atkarīgs no tā, cik daudz izmaiņu veicat savā vietnē. Ja tā ir ikdienas ziņu vietne – īss; ja tas ir saturs, kas neatjaunojas bieži – garāks.
Lazyload
Lazyload funkcija palīdz rādīt resursus (attēlus un Iframe), kad lietotājam tie ir vajadzīgi; tas ir, pārlūks neielādē šos resursus, līdz lietotājs līdz tiem aizritina (scroll). Šī funkcija ir ieviesta daudzos spraudņos un dažās WordPress tēmās pat ir iepriekš konfigurēta. Sākot ar "Chrome" 76. versiju, tā pat nāk pārlūkā natīvi.
Tas nozīmē, ka, pievienojot atribūtu loading="lazy", pārlūks jau interpretē attēla atlikto ielādi, taču, protams, ne katrs pārlūks to interpretēs, tāpēc iesaku turpināt izmantot spraudni. Lūk, video no web.dev, kas parāda piemēru, par ko ir attēlu atliktā ielāde.
Iframe optimizēšana
Ja izmantojam iframe, lai iegultu saturu no citām vietnēm, mums ir divas darbības, ko varam izmantot savas ielādes uzlabošanai.
›
Atliktā ielāde ar lazyload funkciju
›
Vai iframe aizstāšana ar attēlu, līdz lietotājs uz tā noklikšķina.
Gan pirmo, gan otro iespēju var iespējot, atkal, ar mūsu iecienīto spraudni WP Rocket.
JS faili ir viens no vaininiekiem tam, ko ātruma auditi sauc par lapas renderēšanas bloķēšanu (angļu val. render blocking). Tas notiek tad, kad, renderējot, pārlūks apstājas, lai lejupielādētu JS failu un to izpildītu. WPO optimizācijas mērķis ir pēc iespējas ātrāk sniegt informāciju lietotājam, tāpēc tas tiek uzskatīts par bloķējošu, jo nekas netiek renderēts, līdz izpildās lejupielādētais JS.
Tāpēc šāda veida darbības auditā parasti tiek atzīmētas. Izmantojot trešo pušu spraudņus vai tēmas, kas nav labi optimizētas, mums var būt JS, kas bloķē renderēšanu, jo tas atrodas, piemēram, galvenē (header).
Šādos gadījumos mums vajadzētu izmantot divus atribūtus, kas tiek pievienoti JS izsaukuma kodā – Defer un Async. Lai šie atribūti darbotos, skriptiem jābūt ārējiem.
Komandā "SEO Alive" izmantojam spraudni Pre Party Resource Hints, kas ļauj izvēlēties, kurus failus un kuru ielādes metodi vēlaties piemērot. Brīnišķīgi!
Kāda ir atšķirība starp Defer un Async?
Lai gan abiem atribūtiem ir līdzīgs mērķis – nepieļaut, ka DOM HTML interpretāciju aptur JS – starp tiem ir ievērojama atšķirība.
Ar Async atribūtu resurss tiek lejupielādēts, neapturot HTML ielādi, taču pēc lejupielādes HTML ielāde tiek apturēta, lai izpildītu JS; ar defer atribūtu resurss arī tiek lejupielādēts paralēli HTML ielādei, bet tas tiek palaists, kad ielāde beidzas, tāpēc skripts nerada bloķēšanu.
Šajā ziņā starp WP Rocket un Autoptimize ir atšķirības. WP Rocket pieņem lēmumus jūsu vietā daudz vieglāk un darbojas puslīdz automātiski, lai JS nebloķētu renderēšanu; Autoptimize savukārt varat pārslēgt tikai Async iespēju.
Autoptimize, zem extra cilnes, mums ir šī iespēja pievienot JS failus, kurus vēlamies ielādēt ar Async, taču lielākai elastībai tie iesaka citu papildu spraudni "Async Javascript".
async ielāde ar Autoptimize
Ar šo spraudni varam strādāt gan ar Defer, gan ar Async, un tas pat piedāvā viena klikšķa iespējas, lai viss būtu vieglāk. Šī spraudņa priekšrocība ir tā, ka varam strādāt ar skriptiem un izslēgt tos, kurus uzskatām par nepieciešamiem. WP Rocket savukārt mums jāuzticas tam, ko dara spraudnis, lai gan tas to dara labi.
Šī iespēja atrodas tajā pašā failu optimizācijas cilnē.
defer atribūts ar WP Rocket
Kas ir CDN un kā tas var mums palīdzēt?
CDN ir tas, ko dēvē par satura piegādes tīklu (angļu val. content delivery network). CDN ir atbildīgs par daļas informācijas un resursu saglabāšanu, lai atvieglotu servera slodzi šiem resursiem un labāk reaģētu uz slodzi. CDN ir arī ģeogrāfiskās kopēšanas funkcija, lai resurss būtu pieejams dažādos punktos un tiktu piegādāts lietotājam neatkarīgi no tā, no kurienes viņš pieslēdzas. Parasti šāds pakalpojums tiek izmantots smagiem failiem, piemēram, attēliem un video.
Reģistrēšanās šim pakalpojumam ir svarīga, kad mums ir vietnes ar lielu apmeklējumu, lai gan to nevajadzētu izslēgt arī vietnēm ar nelielu apmeklējumu.
Citas darbības, kas mums sniegs nedaudz vairāk uzlabojuma
Nobeidzot rakstu, mums ir vēl 3 uzlabojumi, kas, lai gan neradīs milzīgas izmaiņas ielādes laikos, palīdzēs mums samazināt pieprasījumus, un galu galā tieši to mēs vēlamies.
Fontu optimizēšana
Fontu optimizēšanu var veikt ar spraudņiem vai manuāli, rediģējot un optimizējot CSS. Ideāli būtu izsaukt tikai to fontu, kuru gatavojaties izmantot, nevis, kā notiek daudzos gadījumos, lejupielādēt failu ar visiem Google Fonts.
Autoptimize ir iespēja darbam ar fontiem.
fontu optimizēšana ar Autoptimize
Grūti pateikt, kuru iespēju izvēlēties, neredzot projektu, jo nezinu, kuru fontu izmanto jūsu veidne un kad tas ielādējas, tāpēc vislabāk ir izmēģināt un redzēt rezultātu.
Kā redzat, tūlīt pēc Google Fonts iespējām mums ir "Remove Emoji", kas ietaupīs mums vienu pieprasījumu serverim. Tā funkcija ir vienkārši pārvērst emocijzīmes (emoji) attēlojošos simbolus par ikonu.
emocijzīmes ar WP Rocket
WP Rocket arī ļauj mums atspējot šīs emocijzīmes un piedāvā arī iespēju novērst satura iegulšanu trešo pušu vietnēs.
Galu galā ir daudz darbību vietnes ielādes ātruma uzlabošanai. Ne vienmēr ir iespējams strādāt padziļināti, lai optimizētu katru resursu, jo tas ir atkarīgs no biznesa veida un tā, kas tam nepieciešams.
Ceru, ka šis WPO optimizācijas ceļvedis būs noderīgs un ka jūs varēsiet to pielietot savos projektos vai saviem klientiem.
Pēdējos 10+ gadus esmu pavadījis, pilnībā aizrāvies ar SEO — un, godīgi sakot, es to nevēlētos citādi.
Mana karjera sasniedza jaunu līmeni, kad strādāju par vecāko SEO speciālistu Chess.com — vienā no 100 visapmeklētākajām vietnēm visā internetā. Darbs šādā mērogā, aptverot miljoniem lapu, desmitiem valodu un vienu no konkurētspējīgākajām SERPs, iemācīja man to, ko neviens kurss vai sertifikāts nekad nespētu. Šī pieredze mainīja manu skatījumu uz to, kā patiesībā izskatās izcils SEO — un kļuva par pamatu visam, ko esmu izveidojis kopš tā laika.
No šīs pieredzes es nodibināju SEO Alive — aģentūru zīmoliem, kas nopietni domā par organisko izaugsmi. Mēs neesam šeit, lai pārdotu dashboards un ikmēneša atskaites. Mēs esam šeit, lai veidotu stratēģijas, kas patiešām rada rezultātus, apvienojot labāko no klasiskā SEO ar aizraujošo jauno Generative Engine Optimization (GEO) pasauli — nodrošinot, ka jūsu zīmols parādās ne tikai Google zilajās saitēs, bet arī AI ģenerētajās atbildēs, ko ChatGPT, Perplexity un Google AI Overviews katru dienu piegādā miljoniem cilvēku.
Un tā kā es nevarēju atrast rīku, kas pareizi apstrādātu abas šīs pasaules, es izveidoju to pats — SEOcrawl, enterprise SEO intelligence platformu, kas vienuviet apvieno rankings, tehniskos auditus, backlinks uzraudzību, crawl veselību un AI zīmola redzamības izsekošanu. Tā ir platforma, par kuras esamību es vienmēr biju vēlējies.
