Pastaraisiais metais stebime, kaip rinkodaros specialistai įkėlimo greitį iškelia į kiekvieno optimizavimo proceso viršūnę. 2017 m. Google pradėjo pabrėžti įkėlimo greičio svarbą ir jo būsimą įtaką reitingavimui, tačiau tik 2018 m. vasarą Google oficialiai tai patvirtino.
Šiuo straipsniu siekiame padėti jums savarankiškai pradėti optimizuoti ir gerinti svetainės įkėlimo greitį. Kaip ir bet kuris optimizavimo procesas, jis turi techninę pusę, kuri gali tapti sudėtinga. Rašydami tokio pobūdžio straipsnį „SEO Alive" komandoje norime, kad galėtumėte jį įgyvendinti patys, nors kai kurie veiksmai reikalauja aukštesnio techninio žinių lygio. Tačiau, atvirai kalbant, neišprotėkime besivaikydami įrankių, kuriuos naudosime savo svetainės WPO auditui, balų.
Optimizavimas labai priklauso nuo to, kaip buvo suprojektuotas šablonas, ir ne kiekvienas šablonas leidžia pasiekti tokį patį našumą. Svarbu tai turėti omenyje.
Pradėkime!
Kas yra WPO?
Žiniatinklio našumo optimizavimas (angl. Web Performance Optimization), kurį vadiname WPO, tiesiog yra įvairių procesų, lemiančių, kaip įkeliama svetainė, optimizavimas.
Kaip išmatuoti svetainės įkėlimo greitį?
Įkėlimo greičiui matuoti yra daugybė įrankių. Populiariausi iš jų:
Prieš pradedant auditą, svarbu turėti omenyje, kad įkėlimo greitis skiriasi kiekvienam naudotojui. Įvairūs kintamieji gali paveikti tai, kaip greitis jaučiamas naudotojui Kuenkoje, palyginti su naudotoju Otavoje.
Todėl, užuot dirbę su įkėlimo laiku sekundėmis, rekomenduojame sutelkti dėmesį į šių dalykų optimizavimą:
›
Svetainės svoris (MB)
›
Užklausos
›
Serverio atsako laikas
Pagerinę šias 3 sritis, įkėlimo greitis pagerės nepriklausomai nuo to, kur yra naudotojas.
Gilinsimės į kiekvieną sritį ir per įvairius įrankius pamatysime, kaip su jomis dirbti, kad pagerintume kiekvieno URL našumą. Kodėl sakau „kiekvieno URL"? Nes, nors tai gali atrodyti akivaizdu, esu susidūręs su daugybe atvejų, kai buvo vertinami tik pradžios puslapio duomenys, o juk ne kiekvienas svetainės puslapis įkelia tuos pačius išteklius.
„Google" kūrėjų įrankiai
Prieš pradedant noriu paaiškinti kai kurias parinktis, kurias „Google" siūlo per savo kūrėjų įrankius. Šis įrankis yra vienas svarbiausių analizuojant, kaip veikia svetainė. Dešiniuoju pelės klavišu spustelėkite naršyklėje atidarytą puslapį ir pasirodys skydelis su įvairiomis parinktimis. Eisime į „Inspect" (Ctrl + Shift + I).
Kai šis įrankis atidarytas, pereisime prie NETWORK parinkties, kurią rasite viršuje. Jei naršyklėje dar kartą paspausime ENTER, įrankis parodys įvairių išteklių įkėlimą.
įkėlimo laikas „Google" kūrėjų įrankiuose
Paveikslėlio apačioje matome duomenis, kurie mums įdomūs norint susidaryti bendrą vaizdą, kaip įkeliama svetainė.
Gilindamiesi į šį skydelį nuo viršaus ir žiūrėdami į stulpelių struktūrą, turime:
›
Name: ištekliaus pavadinimas.
›
Status: ištekliaus atsako kodas (200, 301, 404...)
Waterfall: grafinis ištekliaus įkėlimo laikų atvaizdavimas.
Jei spustelėsime dešiniuoju klavišu viršuje, galime pridėti ir pašalinti stulpelius su šia informacija.
informacinių elementų pridėjimas ir pašalinimas skiltyje „network"
Papildomų informacinių elementų, tokių kaip Domain, Scheme ar Cookies, įjungimas tam tikrais atvejais gali padėti aptikti išteklius, galinčius kelti mums kokių nors problemų, tačiau šiuo metu apsiribosime tais, kurie yra iš anksto apibrėžti.
Yra vienas aspektas, kuris, nors ir labai įdomus, čia paliesiu tik paviršutiniškai, kad turėtume jį omenyje. Ryšio greitis, ypač mobiliuosiuose įrenginiuose, yra svarbi svetainės įkėlimo dalis. Iš šio įrankio galime imituoti lėtesnį greitį, pavyzdžiui, 3G mobiliajame.
lėto perdavimo greičio imitavimas
Kaip sužinoti URL svorį ir kaip jį sumažinti?
Svoris, ar tai būtų megabaitais, ar kilobaitais, yra viena pagrindinių priežasčių, kodėl URL užtrunka įkelti. Todėl pradedame gilindamiesi į šį aspektą, nes jis nubrėš kelią gerai mūsų svetainės optimizacijai pasiekti.
Toliau pateikti duomenys yra iš aukščiau minėto įrankio GTMETRIX ir atitinka svetainę, kurią netrukus pradėsiu optimizuoti.
svetainės svorio metrika
Sutelksime dėmesį į dešiniojo stulpelio duomenis, tuos, kurie susiję su (Page Details), konkrečiai Total Page Size.
Iš pirmo žvilgsnio šios svetainės svoris gerokai viršija vidurkį, tačiau turėkite omenyje, kad svarbu ne bendras svetainės svoris, o kiek laiko tas svoris užtrunka įkelti, nes egzistuoja kažkas, vadinama Lazy Load – funkcija, atidedanti įkėlimą, kol naudotojui prireikia ištekliaus. Apie tai pakalbėsime vėliau.
Šią informaciją taip pat galime rasti kūrėjų įrankiuose, tame skydelyje, į kurį žiūrėjome aukščiau ir kurį jums vėl priminsiu.
įkėlimo laikas „Google" kūrėjų įrankiuose
Jei pažvelgsite į apačią, tiek 7,5 MB, tiek 215 užklausų labai artimi GTMETRIX pateiktiems skaičiams. Svarbu, kad žinotumėte, iš kur GTMETRIX gauna savo informaciją, jei kada nors norėtumėte naudoti kitą įrankį.
Dabar pažiūrėkime, kas taip daug sveria ir kaip galime tai sutvarkyti.
Waterfall parinktis leidžia vizualiai pamatyti, kaip įkeliami ištekliai, parodydama ištekliaus URL, būseną, domeną ir Size stulpelį. Spustelėję pastarąjį stulpelį, jis surūšiuoja svorius nuo didžiausio iki mažiausio ir nuo mažiausio iki didžiausio.
įkėlimo analizė per „waterfall"
Žiūrėdami į svorius matome, kaip nutinka daugeliu atvejų, kad paveikslėliai daugiausia atsakingi už perteklinį URL svorį.
Nėra oficialios specifikacijos, koks turėtų būti didžiausias paveikslėlio svoris, tačiau rekomenduojame ne daugiau kaip 100 KB ir, jei turite tokią galimybę (jei naudojate Photoshop, ją turite), nustatykite, kad paveikslėliai kirtųsi progresyviai kaip JPG, ir venkite PNG visada, kai jums nereikia Alfa kanalo (skaidrumo).
Sumažinę paveikslėlių svorį, gerokai pagerinsime svetainės įkėlimą, ir tam galite naudoti kelis įrankius. Aš asmeniškai optimizuoju su Photoshop, tačiau yra įdomių internetinių variantų:
Tiek GTMetrix, tiek „Google" įrankis leidžia peržiūrėti išteklius pagal tipą, tai yra tik paveikslėlius, skriptus, CSS...
Tai naudinga norint susidaryti platesnę perspektyvą, kur dirbti. Šiame URL paveikslėliai sudaro 4 MB iš 7,2 MB, tad didelė svorio problemos dalis yra ten. Vis dėlto yra ir kitų išteklių, kurie savo tipui išsiskiria kaip itin sunkūs, pavyzdžiui, CSS failas, viršijantis 700 KB, ir skriptas, viršijantis 300 KB.
Šiuo metu norėčiau paaiškinti, kad vykdydami įkėlimo greičio optimizavimą (WPO) susiduriame su tam tikromis problemomis, kurios, nors ir turi sprendimų, nėra mūsų galioje pakeisti.
Šiuo atveju matome labai didelį CSS failą. Jei dizaineris sukūrė CSS, viršijantį 700 KB, optimizuoti tą konkretų failą bus sunku.
Ką galime padaryti, kad sumažintume šių failų svorį?
Suglaudinimas (CSS, JS ir HTML)
Suglaudinimas (angl. minification) – tai procesas, kuriuo siekiama sumažinti failo svorį pašalinant nereikalingus duomenis, tokius kaip komentarai, tarpai, pasikartojantis kodas ir nenaudojamas kodas. Šiam procesui atlikti yra daug įrankių, išskyrus nenaudojamo kodo dalį, kurią optimizuoti sunkiau ir kuriai reikėtų rankiniu būdu lįsti į failą (ko nerekomenduoju).
Laimei, kalbame apie WordPress, o, kaip visi žinome, WordPress labai retai nerandame įskiepio, kuris atliktų šią operaciją.
Asmeniškai mėgstu naudoti visiškai nemokamą Autoptimize ir mokamą WP Rocket.
Šiame straipsnyje nenoriu tiek aiškinti, kaip veikia šie įskiepiai, kiek kaip atlikti optimizavimo užduotis. Nes jei naudosime kitus įskiepius, jie taip pat turi šias parinktis, ir geriausia yra suprasti, ką darome.
Suglaudinimas su WP Rocket
Ši dalis nesudėtinga. Tiesiog einame į failų optimizavimo skirtuką ir pažymime „minify HTML" langelį. WP Rocket ši parinktis kartojasi žemiau CSS ir JS failams. Vis tiek rekomenduoju įjungti šį langelį ir išbandyti. Kartokite šią parinktį po vieną, nes jei kas nors sugestų, bus lengviau nustatyti problemą.
HTML suglaudinimas su WP Rocket
Prieš tikrindami suglaudinimo poveikį, turime išvalyti talpyklą, kitaip nepamatysime atnaujinto HTML rezultato.
Kaip išvalyti naršyklės talpyklą?
Tokio tipo įskiepiai turi parinktis talpyklai išvalyti, kurias matome viršuje.
talpyklos valymas su WP Rocket
Kitas būdas – per naršyklę, kai įjungti „Google" kūrėjų įrankiai (Ctrl + Shift + I).
Dešiniuoju klavišu spustelėkite „reload page" rodyklę ir pasirinkite „empty cache and hard reload".
talpyklos valymas iš „Chrome" naršyklės
Suglaudinimas su Autoptimize
Su Autoptimize suglaudinimą atlieka optimizavimo veiksmas, su ta ypatybe, kad siūloma parinktis išsaugoti HTML komentarus. Šiuos komentarus paprastai prideda kūrėjai, kad išsaugotų informaciją, kuri gali būti naudinga ateityje.
HTML suglaudinimas su Autoptimize
Norėdami patikrinti, ar šis optimizavimas įsigaliojo, eitume į URL pirminį kodą ir turėtume pamatyti kažką panašaus:
suglaudinto HTML pavyzdys
Kodas tampa neįskaitomas, tačiau jo funkcionalumas nesikeičia.
Šios parinktys WP Rocket ir Autoptimize kartojasi taip pat CSS ir JS failams. Kaip minėjau anksčiau, nerekomenduoju optimizuoti visko iš karto, o po vieną. Šie įskiepiai saugo suglaudintų failų kopijas, tad grįžti prie originalo įmanoma atžymėjus atitinkamą langelį.
Kad toliau mažintume puslapio svorį, turime dar 2 parinktis:
›
Pašalinti arba sumažinti įskiepius, kurie prideda CSS arba JS prie įkėlimo.
›
Pašalinti arba apkarpyti nenaudojamą kodą CSS faile.
Šios 2 parinktys sudėtingesnės ir reikalauja daugiau žinių, nes reikia būti atsargiam ir įsitikinti, kad iš kitų puslapių nėra kreipinių į dalį, kurią šalinate.
Nors įskiepių šalinimas ne visada įmanomas dėl teikiamo ištekliaus, yra įskiepių, kurie geriau optimizuoti nei kiti, tai yra mažiau užklausų ir lengvesnis JS. Tad nuostabioje WordPress ekosistemoje beveik visada yra alternatyva.
Įkėlimo laikas ir atsako laikas
Dabar metas pakalbėti apie užklausas, atsako laiką ir įkėlimo laiką. Šiuo metu turime paminėti esminę proceso dalį – serverį. Serverio optimizavimas paprastai yra ne mūsų rankose, tad svarbu pasirinkti efektyvų sprendimą.
Bet eikime žingsnis po žingsnio.
Kas yra užklausa?
Užklausa, arba HTTP Request, – tai kreipinys, kurį klientas siunčia serveriui prašydamas tam tikro ištekliaus. Užklausos gali pasiekti skirtingus serverius.
Užklausos gali būti HTTP arba HTTPS. Jei pažvelgsime į užklausos struktūrą, galime išanalizuoti, kur atsiranda laiko delsa.
HTTP užklausos laiko analizė
HTTP užklausos struktūra
Išskaidykime tai, ką matome šioje laiko diagramoje.
›
Užklausa pradėta, bet užblokuota arba eilėje: jei blokavimas trunka ilgai, tai gali būti dėl kelių priežasčių: aukštesnio prioriteto užklausų arba daug užklausų į šį šaltinį.
›
DNS Lookup: naršyklė sprendžia (resolve) užklausos IP adresą.
›
Connecting: laikas, per kurį prisijungiama prie serverio užklausai išspręsti. Jei šis laikas didelis, tai gali reikšti tinklo problemas, ryšio klaidas arba perkrautą serverį.
›
Sending: siunčiama ištekliaus užklausa.
›
Waiting: tai laikas, per kurį serveris išsprendžia užklausą ir siunčia atsakymą; jei jis ilgas, serveryje yra problema.
›
Receiving: ištekliaus gavimas.
HTTPS užklausa prideda dar vieną žingsnį, parodytą čia.
HTTPS užklausos analizė
Šios dvi ekrano nuotraukos priklauso dviem skirtingoms svetainėms – vienai neoptimizuotai (HTTP Request) ir kitai optimizuotai (HTTPS Request).
Jei atidžiai pažvelgsite ir palyginsite, didžiausias skirtumas yra laukimo laike. Tokiais atvejais reikėtų detaliau išanalizuoti serverį.
Serverio užklausos: kaip galime jas sumažinti?
Kaip matėme, užklausų skaičius glaudžiai susijęs su įkėlimo laiku, tad užklausų skaičiaus mažinimas pagerintų URL įkėlimo laikus. Sveikas protas atlieka svarbų vaidmenį optimizavimo procese, taip pat žinojimas, ar išteklius tikrai naudingas naudotojui arba mūsų verslui. Tai metas atsisveikinti su tam tikrais ištekliais, kurie nieko neprideda, tačiau ne man tai spręsti.
Vis dėlto turime galimybių gerinti užklausas, net jei šie veiksmai neatneša didžiulio pokyčio svetainės įkėlimui. Pakartosiu: geriausia yra pašalinti išteklius, kurie nieko neprideda.
CSS ir JS sujungimas
Kitas populiarus veiksmas optimizuojant tinklalapį – CSS ir JS išteklių sujungimas, bet ką tai reiškia?
Sujungimo tikslas – sumažinti užklausas failo svorio didėjimo sąskaita. Sujungimas reiškia įvairių CSS ar JS išteklių suvienijimą į vieną.
Jei atsako laikas ilgas, sujungimas gali būti naudingas. Jei siuntimo laikas labai lėtas, galbūt geriau tinka kita technika.
Idealu yra sujungti turint gerą serverį, tad laimime abiem pusėmis.
Išteklių sujungimas su WP Rocket ir Autoptimize
Sujungimo operacija su šiais įskiepiais tokia pat paprasta kaip ir anksčiau. Tiesiog pažymime atitinkamą langelį.
CSS sujungimas su WP Rocket
WP Rocket parinktys CSS ir JS sujungti yra tokios pat; skydeliai praktiškai identiški. Kaip matome paveikslėlyje, yra langelis, į kurį įrašomas failų, kurių nenorime sujungti, kelias.
Autoptimize siūlo daugiau parinkčių darbui su CSS ir užklausų mažinimui. Parinktyje, kurią pažymiu, jis sujungia ir įspėja apie galimą poveikį, tačiau galiausiai tai visada yra santykinis dalykas.
Šioje pirmoje straipsnio dalyje norėjau paaiškinti, ką sudaro tam tikri baziniai veiksmai, kuriuos paprastai matome praktiškai visuose WPO optimizavimo įskiepiuose, tačiau vis dar yra daug ką galime padaryti, kad pagerintume tiek užklausas, tiek įkėlimo laiką.
Talpyklos konfigūravimas
Be jokios abejonės, talpyklos optimizavimas yra vienas iš veiksmų, kuriuose pastebėsime didžiausią svetainės įkėlimo pagerėjimą. Šiame straipsnyje apie SEO WordPress platformai paaiškinau, kaip veikia talpykla. Raginu užmesti akį, kad suprastumėte, kaip ji veikia.
Autoptimize ir WP Rocket atlieka talpinimo veiksmus, tačiau WP Rocket suteikia porą papildomų parinkčių. Verta paminėti, kad įskiepiai pavertė šį optimizavimą kažkuo paprastesniu: vos turite porą parinkčių, o procesas greitas ir neskausmingas.
WP Rocket konfigūravimas
Kaip matote, WP Rocket leidžia dirbti su 4 dalykais:
›
Įjungti talpinimą mobiliesiems įrenginiams.
›
Išsaugoti failus atskirai mobiliesiems įrenginiams.
›
Įjungti talpinimą prisijungusiems naudotojams.
›
Nurodyti laiką talpyklai išvalyti.
Nuo kiekvieno projekto priklauso, kurią parinktį pasirinkti, tačiau atsižvelgdamas į visa tai patariu:
›
Mobiliojo talpyklą visada, nes nors dauguma svetainių yra prisitaikančios (responsive), yra turinio, kurį galite turėti mobiliajame, bet neturėti darbalaukyje.
›
Failus atskirai.
›
Jokio talpinimo prisijungusiems naudotojams, visų pirma todėl, kad jei darau pakeitimus, nenoriu talpinimo.
›
Talpyklos laikas, kuris priklauso nuo to, kiek pakeitimų atliekate svetainėje. Jei tai kasdienių naujienų svetainė – trumpas; jei tai turinys, kuris atnaujinamas nedažnai – ilgesnis.
Lazyload
Lazyload funkcija padeda rodyti išteklius (paveikslėlius ir Iframe), kai naudotojui jų reikia; tai yra, naršyklė neįkelia šių išteklių, kol naudotojas iki jų neatslenka (scroll). Ši funkcija įdiegta daugelyje įskiepių ir netgi būna iš anksto sukonfigūruota kai kuriuose WordPress temose. Nuo „Chrome" 76 versijos ji netgi ateina natyviai naršyklėje.
Tai reiškia, kad pridedant atributą loading="lazy", naršyklė jau interpretuoja paveikslėlio uždelstą įkėlimą, bet, žinoma, ne kiekviena naršyklė tai interpretuos, tad rekomenduoju toliau naudoti įskiepį. Štai vaizdo įrašas iš web.dev, rodantis pavyzdį, apie ką yra paveikslėlių uždelstas įkėlimas.
Iframe optimizavimas
Jei naudojame iframe kitų svetainių turiniui įterpti, turime du veiksmus, kuriuos galime naudoti savo įkėlimui pagerinti.
›
Uždelstas įkėlimas per lazyload funkciją
›
Arba iframe pakeitimas paveikslėliu, kol naudotojas ant jo nespustelėja.
Tiek pirmąją, tiek antrąją parinktį galima įjungti, vėlgi, per mūsų mėgstamą įskiepį WP Rocket.
JS failai yra vienas iš kaltininkų to, ką greičio auditai vadina puslapio atvaizdavimo blokavimu (angl. render blocking). Tai nutinka tada, kai atvaizduodama naršyklė sustoja atsisiųsti JS failo ir jį įvykdyti. WPO optimizavimo tikslas – kuo greičiau pateikti informaciją naudotojui, todėl tai laikoma blokuojančiu, nes niekas neatvaizduojama, kol įvykdomas atsisiųstas JS.
Todėl šio tipo veiksmai audite dažniausiai pažymimi. Naudojant trečiųjų šalių įskiepius ar temas, kurios nėra gerai optimizuotos, galime turėti JS, kuris blokuoja atvaizdavimą, nes jis yra, pavyzdžiui, antraštėje (header).
Tokiais atvejais turėtume naudoti du atributus, kurie pridedami JS kreipinio kode – Defer ir Async. Kad šie atributai veiktų, skriptai turi būti išoriniai.
„SEO Alive" komandoje naudojame įskiepį Pre Party Resource Hints, kuris leidžia pasirinkti, kuriuos failus ir kokį įkėlimo metodą norite taikyti. Nuostabu!
Kuo skiriasi Defer ir Async?
Nors abu atributai turi panašų tikslą – neleisti, kad DOM HTML interpretaciją sustabdytų JS – tarp jų yra pastebimas skirtumas.
Su Async atributu išteklius atsisiunčiamas nesustabdant HTML įkėlimo, tačiau atsisiuntus HTML įkėlimas sustabdomas, kad būtų įvykdytas JS; su defer atributu išteklius taip pat atsisiunčiamas lygiagrečiai su HTML įkėlimu, bet jis paleidžiamas, kai įkėlimas baigiasi, tad skriptas nesukelia blokavimo.
Šiuo atžvilgiu tarp WP Rocket ir Autoptimize yra skirtumų. WP Rocket priima sprendimus už jus daug lengviau ir veikia pusiau automatiškai, kad JS neblokuotų atvaizdavimo; Autoptimize, priešingai, galite perjungti tik Async parinktį.
Autoptimize, po extra skirtuku, turime šią parinktį pridėti JS failus, kuriuos norime įkelti su Async, tačiau didesniam lankstumui rekomenduoja kitą papildomą įskiepį „Async Javascript".
async įkėlimas su Autoptimize
Su šiuo įskiepiu galime dirbti tiek su Defer, tiek su Async, ir jis netgi siūlo vieno paspaudimo parinktis, kad viskas būtų lengviau. Šio įskiepio privalumas – galime dirbti su skriptais ir išskirti tuos, kuriuos laikome būtinais. WP Rocket atveju, priešingai, tenka pasitikėti tuo, ką daro įskiepis, nors jis tai daro gerai.
Ši parinktis yra tame pačiame failų optimizavimo skirtuke.
defer atributas su WP Rocket
Kas yra CDN ir kaip jis gali mums padėti?
CDN – tai, kas žinoma kaip turinio pristatymo tinklas (angl. content delivery network). CDN atsakingas už dalies informacijos ir išteklių saugojimą, kad palengvintų serverio apkrovą tiems ištekliams ir geriau reaguotų į apkrovą. CDN taip pat turi geografinio kopijavimo funkciją, kad išteklius būtų prieinamas skirtinguose taškuose ir būtų pateikiamas naudotojui nepriklausomai nuo to, iš kur jis jungiasi. Paprastai tokia paslauga naudojama sunkiems failams, tokiems kaip paveikslėliai ir vaizdo įrašai.
Registracija šiai paslaugai svarbi, kai turime svetaines su dideliu srautu, nors jos nereikėtų atmesti ir svetainėms su mažu srautu.
Kiti veiksmai, kurie mums duos šiek tiek daugiau pagerėjimo
Baigdami straipsnį turime dar 3 patobulinimus, kurie, nors ir nesukels didžiulių pokyčių įkėlimo laike, padės mums sumažinti užklausas, o galiausiai to ir norime.
Šriftų optimizavimas
Šriftų optimizavimas gali būti atliekamas per įskiepius arba rankiniu būdu redaguojant ir optimizuojant CSS. Idealu būtų iškviesti tik tą šriftą, kurį ketinate naudoti, o ne, kaip nutinka daugeliu atvejų, atsisiųsti failą su visais Google Fonts.
Autoptimize turi parinktį darbui su šriftais.
šriftų optimizavimas su Autoptimize
Sunku pasakyti, kurią parinktį pasirinkti nemačius projekto, nes nežinau, kurį šriftą naudoja jūsų šablonas ir kada jis įkeliamas, tad geriausia yra išbandyti ir pamatyti rezultatą.
Kaip matote, iškart po Google Fonts parinkčių turime „Remove Emoji", kuris sutaupys mums vieną užklausą serveriui. Jo funkcija tiesiog paversti emocijas (emoji) vaizduojančius simbolius į piktogramą.
emocijos su WP Rocket
WP Rocket taip pat leidžia mums išjungti šias emocijas ir taip pat siūlo parinktį neleisti įterpti turinio trečiųjų šalių svetainėse.
Galiausiai yra daug veiksmų svetainės įkėlimo greičiui gerinti. Ne visada įmanoma dirbti nuodugniai optimizuojant kiekvieną išteklių, nes tai priklauso nuo verslo tipo ir to, ko jam reikia.
Tikiuosi, kad šis WPO optimizavimo vadovas bus naudingas ir kad galėsite jį pritaikyti savo projektuose ar savo klientams.
Pastaruosius 10+ metų praleidau visiškai apsėstas SEO — ir, tiesą sakant, nenorėčiau, kad būtų kitaip.
Mano karjera pakilo į naują lygį, kai dirbau vyresniuoju SEO specialistu Chess.com — vienoje iš 100 lankomiausių svetainių visame internete. Darbas tokiu mastu, apimant milijonus puslapių, dešimtis kalbų ir vieną konkurencingiausių SERPs, išmokė mane to, ko joks kursas ar sertifikatas niekada nebūtų galėjęs. Ta patirtis pakeitė mano supratimą apie tai, kaip iš tikrųjų atrodo puikus SEO — ir tapo pagrindu viskam, ką nuo tada sukūriau.
Iš tos patirties įkūriau SEO Alive — agentūrą prekės ženklams, kurie rimtai žiūri į organinį augimą. Mes čia ne tam, kad pardavinėtume dashboards ir mėnesines ataskaitas. Mes čia tam, kad kurtume strategijas, kurios iš tikrųjų daro poveikį, sujungdami tai, kas geriausia klasikiniame SEO, su jaudinančiu nauju Generative Engine Optimization (GEO) pasauliu — užtikrindami, kad jūsų prekės ženklas pasirodytų ne tik Google mėlynosiose nuorodose, bet ir AI sugeneruotuose atsakymuose, kuriuos ChatGPT, Perplexity ir Google AI Overviews kasdien pateikia milijonams žmonių.
Ir kadangi neradau įrankio, kuris tinkamai valdytų abu šiuos pasaulius, sukūriau jį pats — SEOcrawl, enterprise SEO intelligence platformą, kuri vienoje vietoje sujungia rankings, techninius auditus, backlinks stebėseną, crawl būklę ir AI prekės ženklo matomumo sekimą. Tai platforma, apie kurios egzistavimą visada svajojau.
