Kas iš tikrųjų daro svetainę greitą
Dauguma žmonių „greitą svetainę” atpažįsta ne pagal skaičių, o pagal jausmą: puslapis pasirodo iškart, paspaudus mygtuką niekas „nekimba”, o turinys nesusimuša, kai užsikrauna vaizdai ar šriftai. Tai yra pirmas įspūdis, reakcija ir stabilumas. Todėl greitis nėra vienas rodiklis, ir jis neatsiranda kaip pabaigiamasis optimizavimo darbas, kai viskas jau sukurta. Dažniausiai jis prasideda anksčiau – nuo architektūros: kaip suplanuotas puslapių šablonas, kiek ir kokių funkcijų įdedama, kaip organizuojamas turinys, kas kraunama iš karto, o kas vėliau. Kai sprendimų grandinė tvarkinga nuo pradžios, vėliau nereikia „gelbėti” svetainės vienu įrankiu ar vaikytis PageSpeed balo.
Greitis nėra vienas skaičius: ką iš tikrųjų jaučia vartotojas
Žmogus vertina ne „įvertinimą”, o tai, ar puslapis greitai parodo esmę, reaguoja į veiksmus ir išlieka stabilus kraunantis
„Svetainė užsikrovė” ir „svetaine galima naudotis” nėra tas pats. Puslapis gali rodyti foną, antraštę ar net visą dizainą, bet jeigu mygtukai dar nereaguoja, forma neleidžia įvesti, o meniu atsidaro su vėlavimu, vartotojui tai vis tiek yra lėtumas.
Praktiškai tai matosi taip: atsidarai puslapį iš paieškos, nori paspausti „Kontaktai”, o paspaudimas nieko neduoda, nes dar kraunasi skriptai. Technologiškai failai jau parsisiuntė. Patirtyje puslapis dar „negyvas”. Šito nemaskuoja jokie gražūs skaičiai.
Pirmas įspūdis susiformuoja per pirmas akimirkas. Todėl pirmiausia turi atsirasti tai, kas atsako į klausimą „kur aš patekau ir ką čia galiu padaryti”. Dažniausiai tai yra aiški pagrindinė žinutė (headline), navigacija ir pradinis turinio blokas. Tekstas čia svarbesnis už dekorą. Hero video ar sudėtinga animacija pirmame ekrane dažnai kainuoja daugiau, nei duoda, ypač mobiliuose.
Dar vienas dalykas, kuris tiesiogiai kuria lėtumo jausmą, yra stabilumas. Jei kraunantis vaizdams ir šriftams maketas šokinėja, akys turi nuolat persiorientuoti. Net jeigu failai maži, tai atrodo kaip netvarka. Ir žmogus pradeda nepasitikėti puslapiu, nes jis „nesilaiko”.
Dėl to kalbant apie greitį verta galvoti kaip apie tris dalis: ką pamatau pirmiausia, kada galiu veikti, ir ar vaizdas lieka stabilus. Šitą požiūrį gana gerai apibrėžia Core Web Vitals koncepcija. Tai Google naudojama patirties metrikų grupė, kuri vertina įkrovimo pojūtį, reakciją ir stabilumą, o ne vien failų dydžius.
Praktinis patarimas: peržiūrėkite savo pagrindinius puslapius mobiliame telefone su lėtesniu ryšiu ir atlikite vieną veiksmą per pirmas 3-5 sekundes. Pavyzdžiui, atsidarykite meniu, paspauskite CTA, pabandykite įvesti į formą. Jei jaučiate, kad reikia laukti, problema dažnai yra ne „internetą paspartinti”, o per daug anksti užkraunamos funkcijos ir per sunkus pirmas ekranas.
Kodėl greitis prasideda nuo architektūros, o ne nuo optimizavimo pabaigoje
Didžiausias pagreitis atsiranda tada, kai anksti nusprendžiate, kas išvis turi būti puslapyje, kaip tai kartosis per visą svetainę ir ko geriau nedaryti
Praktikoje greitis dažniausiai nukenčia ne todėl, kad „blogai suspaudėme”, o todėl, kad per daug prikrovėme. Kitaip tariant, „Ką krauname” svarbiau už „kaip suspaudžiame”. Jei puslapis privalo užkrauti kelis šriftus, video, animacijas, formų logiką, filtrus, sekiklius ir dar kelis „smulkius” skriptus, tada kompresija padės tik kosmetiškai. Pagrindinė problema lieka.
Architektūra čia reiškia paprastą dalyką: kaip suprojektuota svetainė iš vidaus. Kokie yra puslapių tipai, kaip sudėlioti šablonai, kaip kartojami blokai, kaip leidžiate turiniui augti po metų. Jei tai suplanuota tvarkingai, našumas tampa natūrali savybė, o ne gelbėjimo operacija kiekvieną kartą ką nors pridedant.
Informacijos architektūra: mažiau šablonų, aiškūs puslapių tipai
Daug lėtumo atsiranda, kai kiekvienam puslapiui sukuriamas „unikalus” šablonas, o realiai jis skiriasi tik keliomis detalėmis. Tada kiekvienas puslapis ima turėti savo taisykles, savo blokų kombinacijas, savo stilius, savo skriptus. Ir viskas plečiasi į šonus.
Geresnis kelias yra susitarti dėl aiškių puslapių tipų. Pavyzdžiui: paslaugos puslapis, atvejo analizė, straipsnis, kontaktai, landing page. Kiekvienam tipui turėti nuoseklią struktūrą ir tuos pačius komponentus. Komponentas yra pakartotinai naudojamas turinio blokas, pvz., „hero”, „privalumų sąrašas”, „FAQ”, „CTA”.
Kai komponentai tie patys, jie gali būti optimizuojami vieną kartą ir tarnauti visur. Dizainas lieka tvarkingas. Redagavimas tampa paprastesnis. O svarbiausia, puslapiai nepradeda krauti vis naujų dalykų vien dėl to, kad kažkas „šiame puslapyje norėjo kitaip”.
Funkcionalumo ribos: kada verta kurti, o kada atsisakyti
WordPress leidžia pridėti beveik bet ką. Bet kiekviena funkcija turi kainą: papildomi failai, papildomas apdorojimas serveryje, daugiau galimų konfliktų. Todėl geras klausimas anksti projekte yra paprastas: ar tai tiesiogiai padės parduoti, sumažins užklausų trintį, ar sutaupys komandai laiko?
Jei atsakymas miglotas, funkcija dažnai nėra verta. Tipinis pavyzdys – sunkūs filtrai ir „protingos” paieškos mažam katalogui. Jei turite 20 paslaugų ar 30 projektų, dažnai pakanka aiškios kategorijų struktūros ir geros vidinės navigacijos. Tai greičiau, pigiau prižiūrėti ir mažiau lūžta.
Mano praktinis vertinimas toks: animacijos ir efektai pirmame ekrane retai atsiperka. Jie gražūs, bet dažnai trukdo svarbiausiam tikslui – greitai parodyti esmę ir leisti atlikti veiksmą. Jei norisi judesio, geriau naudoti lengvus, subtilius perėjimus ir palikti video ten, kur jis tikrai paaiškina produktą.
Kaip bloga architektūra sukuria priklausomybę nuo „lopymų”
Kai architektūra chaotiška, optimizavimas tampa nuolatiniu lopymu. Pradedama nuo cache (tai yra laikinas puslapio ar jo dalių „išsaugojimas”, kad kitą kartą būtų pateikta greičiau). Tada atsiranda minify (failų sumažinimas pašalinant tarpus ir komentarus). Tada dar vienas papildinys, nes „šitas sutvarko CSS”, dar vienas, nes „anas tvarko JS”.
Problema ta, kad tokie lopai dažnai maskuoja simptomus, bet ne priežastį. Jei puslapis kiekvieną kartą privalo užkrauti per daug funkcijų, cache tik paslepia dalį skausmo, kol kažkas pasikeičia ir vėl viskas ima lėtėti. O kuo daugiau optimizavimo papildinių, tuo daugiau vietų, kur gali atsirasti konfliktas po atnaujinimo.
Praktinis patarimas: prieš „greitinant” susirašykite 5-10 elementų, kurie kraunasi pirmame ekrane, ir paklauskite savęs, ar kiekvienas jų būtinas. Jei kyla abejonė, pradėkite nuo turinio ir struktūros supaprastinimo. Architektūriniai sprendimai duoda stabilesnį rezultatą nei bandymas vėliau viską kompensuoti cache ir minify sluoksniais.
Puslapio svoris ir kritinis kelias: kas realiai stabdo įkėlimą
Tikrasis stabdys dažniausiai yra per daug failų, kuriuos reikia atsisiųsti, ir neteisingas krovimo eiliškumas – ypač viršutinėje puslapio dalyje.
Kai žmonės sako, kad svetainė „lėta”, paprastai turi omeny vieną dalyką: puslapis per ilgai atrodo tuščias, arba pirmas ekranas pasirodo, bet jaučiasi „įstrigęs”. Tą tarpą beveik visada sukuria kritinis kelias.
Kritinis kelias – tai minimalus rinkinys failų, kuriuos naršyklė turi atsisiųsti ir apdoroti, kad galėtų parodyti pirmą ekraną. Jei tas rinkinys sunkus arba netvarkingai sudėliotas, visa kita, ką darote vėliau, tėra žalos mažinimas.
Yra trys pagrindiniai kaltininkai: per daug resursų, blogas krovimo eiliškumas ir perkrautas „virš lenkimo” plotas. „Virš lenkimo” tiesiog reiškia tai, ką vartotojas mato dar neslinkęs žemyn.
HTTP užklausos: skaičius svarbus mažiau nei kaina
HTTP užklausa – tai vienas atsisiuntimas iš serverio: vaizdas, CSS failas, JavaScript failas, šriftas. Žmonės dažnai sutelkia dėmesį į skaičių. Praktikoje labiausiai skaudina kaina.
Keli maži failai dažniausiai netrukdo. Naršyklė juos parsisiunčia efektyviai, o šiuolaikiniai serveriai gerai tvarko lygiagrečias užklausas. Tikra bėda yra dideli failai, failai blokuojantys atvaizdavimą ir trečių šalių užklausos, priklausomos nuo kažkieno kito infrastruktūros.
Taigi, mažinti skaičių gali padėti. Bet tai ne pirmas klausimas. Pirmas klausimas yra: kurios užklausos turi baigtis prieš pirmą ekrano atvaizdavimą, ir ar tos užklausos yra lengvos bei nuspėjamos?
CSS ir JavaScript – dažniausi kritinio kelio kaltininkai
CSS valdo, kaip turinys atrodo. JavaScript prideda elgseną. Abu gali užblokuoti puslapio pasirodymą, jei naršyklė turi juos pilnai atsisiųsti ir apdoroti prieš piešdama pirmą vaizdą.
Būtent čia netvarkingi WordPress projektai tampa brangūs. Tema, puslapių kūrėjas, trys funkciniai papildiniai, slaideris, analitikos skriptas, pokalbių langas – kiekvienas prideda CSS ir JS. Dažnai globaliai, net puslapiuose, kuriems to nereikia.
Praktinis patarimas: pasirūpinkite, kad pirmam ekranui atvaizduoti būtų reikalingas tik tas CSS, kuris tam ekranui reikalingas. Visa kita gali pasikrauti vėliau. Tas pats su JavaScript. Jei skriptas nėra būtinas pradiniam vaizdui, jis neturėtų jo blokuoti.
Vertinimas iš praktikos: kai kurias funkcijas neverta „gelbėti” gudriu optimizavimu. Jei papildinys atsineša daug kodo dėl mažo vizualinio efekto, paprastesnis sprendimas vietoj jo paprastai yra geresnis ilgalaikis kelias.
Didelis hero vaizdas – dažnai didžiausia pavienė problema
Tas viso pločio hero vaizdas atrodo nekaltai. Bet jis dažniausiai yra didžiausias resursas puslapyje, ir stovi būtent ten, kur vartotojas tikisi kažką pamatyti akimirksniu.
Jei hero sunkus, naršyklė sugaišta laiką jį siųsdama, kol pirmas ekranas atrodo baigtas. Jei dar uždėsite dideles antraštes, pasirinktinius šriftus, perdangas ir kelis skriptus viršuje, pirmas vaizdas virsta eile, o ne greitu atvaizdu.
Praktinis patarimas: traktuokite hero kaip našumo biudžeto elementą. Naudokite tinkamą vaizdo formatą ir dydį pagal tai, kaip jis rodomas. Venkite naudoti milžinišką desktop vaizdą visur. Ir būkite atsargūs su fono video hero zonoje, ypač mobiliuose. Jie dažnai atrodo prabangiai, bet elgiasi kaip plyta.
Paprasta taisyklė: pirmiausia krauk tai, ko reikia pirmam ekranui
Jei iš šios dalies pasiimsite tik vieną taisyklę, tebus ši: pirmenybę duokite pirmam ekranui. Pirmiausia kraukite maketą, pagrindinį tekstą ir pagrindinį raginimo veikti mygtuką. Visa kita yra antrinė.
Realiuose projektuose dažnai darau greitą pirmo ekrano inventorizaciją: viena antraštė, viena trumpa pastraipa, vienas mygtukas, gal nedidelis palaikantis vaizdas. Tada tikriname, kokių failų reikia vien tam. Jei sąrašas ilgas, problema paprastai yra architektūroje, o ne minifikacijos trūkume.
Kai pirmas ekranas švarus, likusią puslapio dalį optimizuoti tampa paprasčiau. Ir svarbiausia – puslapis išlieka greitas, kai vėliau pridedate naujo turinio, nes kritinis kelias lieka kontroliuojamas.
Turinys ir media: greitis dažnai žūva ne kode, o turinyje
Daug lėtumo ateina iš redakcinių sprendimų: ką įdedate į puslapį ir kaip tai įkeliama.
Net tvarkingas kodas nepadės, jei puslapis neša per didelius vaizdus, kelis vaizdo įrašus, keturias šriftų šeimas ir dar kelis trečių šalių įterpinius. Tai nėra „optimizavimo po to” tema. Tai yra architektūros dalis, nes turinio taisyklės nulemia, kiek ir kokių resursų naršyklė turės atsisiųsti kiekvieną kartą.
Gera žinia ta, kad čia dažnai užtenka disciplinos. Ne triukų. Sutvarkai turinio higieną ir svetainė iš karto tampa stabilesnė, o greitis mažiau priklauso nuo to, kiek vėliau prisidės papildomų funkcijų.
Vaizdai: formatas, dydis ir reali rezoliucija
Dažniausia problema nėra „blogas formatas”, o per didelis vaizdas. Įkeltas 4000 px pločio failas, o rodomas 900 px pločio bloke. Tokiu atveju naršyklė vis tiek parsisiunčia didelį failą, tik vėliau jį sumažina ekrane.
Praktika paprasta: ruošti vaizdus pagal realų panaudojimą. Hero tipo vaizdui reikia vieno sprendimo, paslaugų ikonoms kito, galerijai dar kito. Formatas irgi svarbus, bet jis neturi prasmės, jei failas tiesiog per didelis. Jei jūsų turinys dažnai keičiasi, verta turėti aiškias taisykles: maksimalūs plotiai dažniausiems blokams ir prioritetas vaizdams, kurie matomi pirmame ekrane.
Tingus krovimas (lazy loading) reiškia, kad vaizdas kraunamas tik tada, kai jis artėja prie matomos ekrano dalies. Tai tinka daugumai vaizdų žemiau pirmo ekrano. Bet pirmam ekrano vaizdui lazy loading dažnai kenkia, nes vartotojas laukia būtent jo. Čia verta sąmoningai pasirinkti: kas turi atsirasti iš karto, o kas gali palaukti.
Video: kada geriau „per paspaudimą”
Video embed dažnai atrodo kaip vienas elementas puslapyje. Realiai jis atsineša papildomų skriptų, užklausų ir kartais net trečių šalių slapukų logiką. Tai ypač jaučiasi mobiliajame ryšyje.
Jei video nėra kritinis pirmam ekrane, dažnai geriau naudoti įkėlimą per paspaudimą. Rodote lengvą peržiūros paveikslėlį su mygtuku, o tik paspaudus įkeliate tikrą grotuvą. Vartotojui aišku, kas vyksta, o puslapis nepaverčiamas laukimo eile vien dėl to, kad kažkur viduryje yra įterptas filmukas.
Sprendimas priklauso nuo konteksto. Jei video yra pagrindinė konversijos dalis ir jis yra pirmame ekrane, tuomet embed gali būti pagrįstas. Bet tada verta atitinkamai „apkarpyti” kitus elementus tame pačiame vaizde, kad pirmas įspūdis nebūtų sunkus.
Šriftai: kiek šeimų ir stilių tikrai reikia
Šriftai atrodo kaip dizaino detalė, bet jie turi kainą. Kiekviena šeima ir kiekvienas stilius (pvz., regular, medium, bold, italic) yra atskiras failas. Naršyklė turi jį parsisiųsti ir pritaikyti, kol tekstas atrodo taip, kaip suplanavote.
Praktinis patarimas: pradėkite nuo dviejų šeimų arba net vienos, ir kuo mažiau stilių. Dažnai realiai naudojami tik 2-3 svoriai. Visa kita lieka „gal prireiks”, bet mokate greičiu kiekviename puslapyje. Jei dizainas reikalauja daugiau, gerai. Tiesiog tai turi būti sąmoningas sprendimas, o ne atsitiktinumas, atsiradęs dėl šablono.
Trečių šalių įterpiniai: chat, tracking, žemėlapiai
Trečių šalių skriptai dažnai kainuoja daugiau nei atrodo, nes jūs nebekontroliuojate nei jų dydžio, nei greičio, nei to, kada jie nusprendžia užsikrauti papildomus resursus. Vienas chat widget, vienas analitikos įrankis, vienas žemėlapis ir staiga puslapis tampa priklausomas nuo kelių išorinių sistemų.
Čia nereikia moralizuoti. Verslui dažnai reikia analitikos, remarketingo ar gyvo pokalbio. Bet verta nuspręsti, kur tai tikrai duoda vertę. Praktinis kompromisas: krauti chat tik po kelių sekundžių arba tik po vartotojo veiksmo, žemėlapį rodyti kaip statinį vaizdą su nuoroda „Atidaryti Google Maps”, o tracking skriptus laikyti tvarkingai su aiškia taisykle, kurie puslapiai juos tikrai naudoja.
Mažas vertinimas iš praktikos: jei papildomas įterpinys neduoda aiškios naudos pardavimams ar klientų aptarnavimui, jo „kaina” dažniausiai per didelė. Ypač pradiniame etape, kai svarbiausia yra greitas pirmas ekraninis vaizdas ir aiškus turinys. Mažiau triukšmo, daugiau kontrolės.
WordPress tema ir komponentai: lengvumas yra disciplina, ne šablono pavadinimas
Svetainė tampa greita tada, kai tema suprojektuota kaip aiški sistema: mažai priklausomybių, apibrėžti blokai ir kuo mažiau „vienas sprendimas viskam”.
Čia dažnai suklystama ne dėl „neteisingų” įrankių, o dėl pasirinkimo pradžioje. Tema nėra tik dizainas. Tema yra tai, ką naršyklė turi atsisiųsti ir vykdyti kiekviename puslapyje: CSS (stiliai), JS (interaktyvumas) ir šablonų logika.
Universali tema paprastai bando įtikti visiems: dešimtys šablonų, efektų, sliderių, integracijų, „importuok demo” paketų. Tai patogu startui. Bet dažnai atneša per daug kodo, kurio jūsų projektas niekada nenaudos, o vis tiek turės jį nešiotis. Net jei dalis funkcijų „išjungta” administracijoje, resursai dažnai lieka kraunami.
Projekto tema yra priešingas požiūris. Ji kuriama konkrečiai jūsų struktūrai: keliems puslapių tipams, konkretiems blokams, realiam turiniui. Mažiau variantų. Mažiau „gal prireiks”. Daugiau kontrolės. Greitis čia atsiranda ne iš magiško šablono pavadinimo, o iš to, kad nėra pertekliaus.
Praktikoje gerai veikia blokų ir komponentų principas. Vietoje to, kad kiekvienas puslapis būtų „sukonstruotas nuo nulio”, turite aiškų rinkinį kartojamų blokų: hero, paslaugų kortelės, atsiliepimai, DUK, kontaktų juosta, CTA. Tie patys blokai kartojasi visoje svetainėje. Dėl to mažėja ir techninė kaina.
Kodėl tai greičiau ir tvarkingiau? Nes vienam blokui parašytas CSS ir JS gali būti minimalus ir tikslus. Nereikia globalių taisyklių „viskam”, kurios vėliau konfliktuoja tarpusavyje. Ir nereikia nuolat pridėti naujų „mikro sprendimų”, kurie išsipučia per kelis mėnesius. Tai mažiau netikėtumų, kai svetainę reikia plėsti.
Dabar apie page builderius. Jie nėra blogis. Bet jie turi kainą. Page builderis paprastai atsineša savo renderinimo sluoksnį, papildomą CSS, daug JS ir kartais net savo „globalius” efektus. Net kai puslapyje jų nenaudojate pilnai, dalis resursų vis tiek būna įkraunama, nes taip veikia jų architektūra.
Kada tai pateisinama? Kai projektui svarbiausia greitai paleisti ir dažnai redaguoti sudėtingus išdėstymus be developerio. Pavyzdžiui, marketingo komanda nuolat kuria kampanijų puslapius, testuoja struktūras, keičia blokus kas savaitę. Tokiu atveju galima sąmoningai susimokėti našumu. Bet verta tada apriboti „laisvę”: sutarti dėl kelių šablonų, nenaudoti visų animacijų ir laikytis vieno dizaino sistemos.
Jei svetainė yra paslaugų įmonės reprezentacija su keliolika puslapių, o turinys keičiasi retai, page builderis dažnai yra per brangus sprendimas. Mano vertinimas paprastas: jei už lankstumą mokate kiekvieno lankytojo krovimo laiku, verta paklausti, ar jums to lankstumo tikrai reikia kasdien.
Vienas praktiškas kriterijus, kurį galima aptarti net be techninių detalių: kiek kodo kraunama puslapiui, net jei funkcija nenaudojama. Pavyzdžiui, jei puslapyje nėra formos, ar vis tiek kraunamas formų JS? Jei nėra sliderio, ar vis tiek kraunamas sliderio kodas? Jei nėra galerijos, ar vis tiek įkeliami jos stiliai?
Gera architektūra daro taip, kad puslapis įsikrauna tai, ko jam reikia. Ir tik tai. Tai disciplina: aiškūs komponentai, aiškios priklausomybės, mažiau globalių „paketų”. Tada optimizavimas tampa ne gelbėjimo operacija, o natūrali projekto būsena.
Duomenys ir dinamika: lėtumas dažnai slepiasi užklausose
Kai puslapis atrodo „lengvas”, bet serveris ilgai galvoja: užklausos, filtrai, paieška ir šablonų logika
Kalbant apie greitį, daug kas galvoja tik apie tai, kas atsisiunčiama naršyklėje. Bet nemaža dalis laukimo įvyksta dar prieš tai, kai naršyklė apskritai gauna pirmą HTML eilutę.
Lėtas TTFB praktikoje reiškia paprastą dalyką: paspaudžiate nuorodą ir „tyla” užtrunka. Antraštė dar neatsirado, turinys nepradeda krautis, o serveris tuo metu renka duomenis ir lipdo puslapį. TTFB yra laikas iki pirmo atsakymo baito – tai serverio pusės darbas, ne dizainas.
WordPress šioje vietoje yra labai lankstus, bet lankstumas kainuoja, jei viskas daroma dinamiškai kiekvieno lankytojo užklausos metu. Problema dažniausiai ne viena „sunki” užklausa, o daug mažų veiksmų, kurie sumuojasi.
Tipinės vietos, kur užklausų pradeda daugėti:
- Archyvai ir kategorijų puslapiai – kai viename puslapyje norima rodyti daug kortelių, o kiekvienai dar traukiama papildoma informacija.
- Filtrai ir katalogai – kai filtruojama pagal kelis kriterijus, skaičiuojami kiekiai, sudedami keli rūšiavimai, o dar norima viską daryti realiu laiku.
- Paieška – ypač jei tikimasi „protingos” paieškos per visą turinį, laukus, sinonimus, be aiškių ribų.
- Susiję įrašai – kai kiekvieno įrašo apačioje dinamiškai ieškoma „panašių” pagal kelias taisykles.
- Sudėtingi ACF laukai – daug kartų pasikartojantys (repeater), lankstūs blokai, daug ryšių į kitus objektus. Patogu redagavimui, bet gali būti brangu atvaizdavimui, jei šablonas viską renkasi po truputį.
Čia dažnai matosi dar viena tendencija: „viską darykime per papildinius”. Iš pradžių tai greita. Po pusmečio ar metų atsiranda keli filtravimo papildiniai, paieškos papildinys, susijusių įrašų papildinys, dar kažkas analitikai ar personalizacijai. Kiekvienas jų prideda savo logiką, savo užklausas, savo kabliukus. Ir svarbiausia – jie dažnai veikia kiekviename puslapyje, net jei funkcija realiai reikalinga tik viename skyriuje.
Nėra taisyklės „papildiniai blogai”. Bet jeigu funkcija tampa kritinė verslui, verta ją laikyti sistemos dalimi, o ne atsitiktiniu priedu. Nes kitaip mokate našumo kainą kiekvieną kartą, kai puslapis generuojamas, ir ta kaina linkusi augti kartu su turiniu.
Kada verta keisti logiką, o ne „dar optimizuoti” tą patį?
- Jei katalogas ar filtrai tapo pagrindiniu srauto šaltiniu, verta riboti filtrų kombinacijas ir aiškiai nuspręsti, kas tikrai reikalinga. „Filtruok viską pagal viską” dažnai skamba geriau nei veikia.
- Jei susiję įrašai ar rekomendacijos rodomi visur, dažnai apsimoka iš anksto sugeneruoti ryšius ir saugoti rezultatą, o ne ieškoti jų kiekvieno atidarymo metu.
- Jei paieška lėta, verta supaprastinti, ką ji ieško (pavyzdžiui, tik pavadinimuose ir santraukose) arba atskirti paiešką skirtingiems turinio tipams.
- Jei ACF struktūra išaugo, verta peržiūrėti, ar tikrai reikia tiek daug dinaminių laukų viename šablone, ir ar dalies informacijos negalima sutvarkyti į aiškesnius, paprastesnius objektus.
Mano praktinis vertinimas toks: kai projektas pereina į „katalogo” režimą (daug objektų, filtrai, rūšiavimai, paieška), frontendo tvarkymas duoda vis mažiau naudos, jei serveris kiekvieną kartą daro per daug darbo. Tokiu atveju laimi ne gudresni efektai, o paprastesnės taisyklės, aiškesnė duomenų struktūra ir vietomis mažiau dinamikos.
Geras greitis čia prasideda nuo architektūros sprendimo: ką skaičiuojame realiu laiku, o ką paruošiame iš anksto. Ką leidžiame filtruoti, o ką geriau nukreipti per aiškias kategorijas ar landing puslapius. Tai kompromisai, bet protingi kompromisai, kurie apsaugo projektą nuo lėto augimo.
Cache ir pristatymas: kaip architektūra leidžia cache veikti gerai
Cache nėra stebuklas – jis veikia tik tada, kai puslapių logika nuspėjama ir ją galima saugiai pakartoti kitiems lankytojams
Cache paprastai suprantamas kaip „padarom greičiau”. Praktikoje tai yra pasekmė. Jei architektūra tvarkinga, cache turi ką išsaugoti ir gali tai atiduoti daug kartų be rizikos parodyti neteisingą turinį.
Cache terminas reiškia paprastą dalyką: išsaugome jau paruoštą rezultatą, kad kitą kartą nereikėtų visko skaičiuoti nuo nulio. Skirtumas atsiranda tame, ką tiksliai saugome.
Puslapio cache saugo galutinį puslapio atsakymą. Dažniausiai tai HTML, kurį naršyklė gali rodyti iš karto. Tai didžiausias laimėjimas, kai daug lankytojų mato tą patį puslapį: paslaugų puslapį, straipsnį, kategoriją, landing puslapį.
Objektų cache saugo mažesnes dalis, kurias sistema skaičiuoja viduje. Pavyzdžiui, duomenų užklausų rezultatus ar sudėtingų skaičiavimų išvestį. Tai padeda net tada, kai puslapio cache negalimas, bet efektas dažniausiai mažesnis ir labiau priklausomas nuo to, kaip parašyta logika.
Kur cache „nustoja veikti”? Ne todėl, kad cache blogas. O todėl, kad puslapis kiekvienam vartotojui tampa kitoks, arba keičiasi per dažnai.
- Personalizacija. Jei puslapis rodo kainas, turinį ar pasiūlymus pagal konkretų žmogų, puslapio cache turi daug išimčių. Išimtys yra brangios.
- Krepšelis ir checkout. Tai tipinė zona, kur puslapio cache dažnai neturi prasmės. Turite sesijas, kuponus, likučius, pristatymą. Čia svarbiau stabili, paprasta logika ir greitos vidinės užklausos.
- Daug dinamikos viename puslapyje. Kai puslapis surenkamas iš daugybės blokų, kurie kiekvienas traukia duomenis atskirai, cache sudėtingėja. Ypač jei dalis blokų „priklauso nuo konteksto”.
- Dažni invalidavimai. Invalidavimas reiškia, kad cache reikia išmesti, nes duomenys pasikeitė. Jei turinys keičiasi nuolat, arba vienas pakeitimas paliečia daug puslapių, jūs nuolat gyvenate „be cache” režimu.
Čia architektūra matosi labai aiškiai. Svetainė, kur visi puslapiai yra „šiek tiek personalizuoti”, realiai nebeturi aiškios ribos tarp viešo turinio ir individualios zonos. Tada cache tampa loterija, o ne sistema.
Geras modelis paprastas: turite kelis aiškius puslapių tipus ir žinote, kurie iš jų turi būti vienodi visiems. Pavyzdžiui: straipsniai ir paslaugų puslapiai – cache’able. Kliento paskyra, krepšelis, užsakymo forma – ne. Kai šios ribos aiškios, sprendimai tampa techniniai, o ne kompromisų kratinys.
Dar viena dalis yra pristatymas per CDN. CDN logika paprasta: statinis turinys (failai) laikomas arčiau vartotojo, kad jis greičiau atsisiųstų. Statika čia yra vaizdai, CSS, JavaScript, šriftai, PDF.
CDN dažniausiai padeda būtent šiai statinei daliai, nes ją saugu kopijuoti ir dalinti daugeliui lankytojų. Dinaminį HTML jis gali padėti tik tada, jei jūsų puslapiai iš tiesų yra vienodi ir nuspėjami. Jei ne, CDN turi arba apeiti dinamiką, arba rizikuoti neteisingu turiniu. Normaliai pasirenkamas pirmas variantas, ir tada „CDN nepadėjo” nėra problema su CDN. Tai signalas apie architektūrą.
Praktinis patarimas: prieš „įjungiant cache” verta susidėlioti puslapių žemėlapį pagal tipus. Kur yra grynai viešas turinys. Kur prasideda individualumas. Kur yra funkcijos, kurios keičia puslapį kiekvieną kartą. Tą patį verta padaryti ir su turinio atnaujinimais: kas keičiasi kartą per mėnesį, o kas kasdien.
Mano vertinimas toks: jei verslas nėra e-commerce, per didelė personalizacija dažnai tiesiog neatsiperka. Ji kainuoja greitį, testavimą ir priežiūrą, o realios naudos būna mažiau nei tikėtasi. Daugeliu atvejų geriau turėti labai aiškius landing puslapius pagal auditorijas, nei bandyti vieną puslapį priversti būti „viskuo visiems”.
Galiausiai, cache gerai veikia ten, kur turinys nuspėjamas, o puslapio generavimas stabilus. Tai nėra apie vieną nustatymą. Tai apie tai, kaip nuo pradžių suprojektuota svetainė: kokie puslapiai egzistuoja, ką jie rodo, ir kiek dažnai tai turi keistis.
Stabilumas per laiką: kaip greitą svetainę padaryti ilgalaikiai greitą
Greitis yra procesas: laikykite atnaujinimus kontroliuojamus, traktuokite naujas funkcijas kaip kainą ir planuokite turinio augimą, kad svetainė liktų nuspėjama.
Svetainė retai sulėtėja per naktį. Paprastai tai vyksta mažais žingsneliais. Keletas naujų puslapių. Keletas naujų papildinių. Dar vienas sekimo skriptas. „Greitas” dizaino pataisymas, kuris prideda dar vieną šriftą, dar vieną sliderį, dar vieną animaciją.
Kiekvienas pokytis atskirai atrodo nekaltai. Sudėjus kartu, jie keičia, kiek naršyklė turi atsisiųsti ir kiek serveris turi surinkti kiekvieno apsilankymo metu. Naršyklė reiškia vartotojo įrenginį. Serveris – vietą, kur veikia jūsų WordPress.
Todėl greitis prasideda nuo architektūros, bet išlieka su disciplina. Reikia paprastų taisyklių ir reikia jų laikytis, kai svetainė auga.
Kodėl svetainės lėtėja laikui bėgant
Turinys auga. Daugiau vaizdų, daugiau sekcijų puslapyje, daugiau vidinių nuorodų, daugiau kategorijų. Ilgesni puslapiai savaime nėra blogai, bet paprastai tai reiškia daugiau medijų ir daugiau veikiančių skriptų.
Papildiniai kaupiasi. Papildinys dažnai prideda savo CSS, JavaScript ir duomenų bazės užklausas. Net „maži” papildiniai gali pridėti globalų kodą, kuris vykdomas kiekviename puslapyje.
Sekimas plečiasi. Marketingo žymos, pokalbių langai, šilumos žemėlapiai, slapukų įrankiai. Dauguma jų krauna papildomus skriptus iš kitų įmonių serverių. Tai prideda laukimo laiko, kurio jūs negalite visiškai kontroliuoti.
Dizainas „užauga” ant svetainės. Papildomi šriftai, keletas mygtukų stilių, sunkūs slideriai, video fonai, daug subtilių efektų. Būtent čia greitis paprastai tyliai miršta, nes visa tai ateina kaip „tik mažas patobulinimas”.
Nustatykite aiškias taisykles visiems, kas skelbia ar keičia turinį
Nereikia techninių žmonių, kad būtų laikomasi našumo taisyklių. Reikia taisyklių, kurias lengva patikrinti.
- Medijų įkėlimo standartas. Visada kelkite vaizdus jau paruoštus pagal realų dydį, kuriame jie bus naudojami. Nekelkite 6000 px nuotraukos 1200 px antraštei. Naudokite šiuolaikinius formatus, kai įmanoma. Dekoratyvinius vaizdus laikykite lengvesnius nei produktų nuotraukas.
- Video taisyklė. Neįterpkite didelių vaizdo įrašų automatiškai ilguose puslapiuose. Naudokite peržiūros paveikslėlį ir kraukite grotuvą tik paspaudus, arba dėkite video atskirame puslapyje.
- Šriftų limitas. Naudokite ne daugiau dviejų šriftų šeimų. Laikykitės minimalaus svorių kiekio. Paprastai pakanka 2-3 svorių. Kiekvienas papildomas svoris yra dar vienas failas.
- Įterpinių politika. Traktuokite įterpinius (žemėlapius, socialinius įrašus, rezervavimo valdiklius) kaip neprivalomas funkcijas. Įterpkite tik tai, ką galite pagrįsti. Pirmenybę teikite nuorodoms ar statiniams vaizdams, kai to pakanka.
- Sekimo politika. Pridėkite sekimą tik su aiškiu tikslu ir atsakingu žmogumi. Jei niekas nenaudoja įrankio per 60-90 dienų, pašalinkite jį.
- Page builder disciplina. Venkite krautis vieną ant kito kelis „protingus” blokus, kurie kiekvienas krauna savo resursus. Geriau naudokite nedidelį patvirtintų sekcijų rinkinį pakartotinai.
Mažas vertinimas iš patirties: dauguma verslo svetainių geriau veikia su mažiau, bet nuosekliomis sekcijomis, nei su begaliniais individualiais išdėstymais. Tai lengviau palaikyti greita. Ir lengviau prižiūrėti.
Principas: kiekvienas naujas elementas turi kainą
Tai paprasčiausia sprendimų taisyklė, kurią žinau. Kiekvienas naujas elementas prideda kainos bent vienoje iš šių sričių: atsisiuntimo dydis, vykdomi skriptai, serverio darbas arba ilgalaikė priežiūra.
Kai kažkas prašo „dar vieno dalyko”, paklauskite atgal:
- Kokią problemą tai sprendžia?
- Ar tai reikalinga kiekviename puslapyje, ar tik viename?
- Ar tai prideda trečiosios šalies skriptą?
- Ar galime pasiekti tą patį rezultatą paprastesniu būdu?
- Kas tai prižiūrės ir peržiūrės vėliau?
Jei vertė neaiški, atidėkite. Ne amžinai. Tiesiog kol atsiras aiškus savininkas ir aiški priežastis.
Darykite periodinį techninį auditą, net jei viskas „atrodo gerai”
Greitis yra ir higiena. Trumpa peržiūra kartą per ketvirtį paprastai pakanka tipinei verslo svetainei. Dažniau, jei aktyviai skelbiate turinį ar leidžiate kampanijas.
Ką tikrinti ir kodėl:
- Papildinių sąrašas. Pašalinkite tai, ko nenaudojate. Pakeiskite „daugiafunkcius” papildinius, kurie kraunami visur, siauresniais sprendimais, kai tai prasminga.
- Trečių šalių skriptai. Peržiūrėkite, kas kraunama pradiniame puslapyje ir svarbiuose landing puslapiuose. Pašalinkite dublikatus. Perkelkite nekritinius įrankius nuo pagrindinių puslapių.
- Puslapių šablonai ir globalios sekcijos. Antraštės, poraštės, mega meniu, iššokantys langai. Jie veikia kiekviename puslapyje, todėl net maži pakeitimai čia turi didelį poveikį.
- Vaizdų biblioteka. Ieškokite per didelių įkėlimų ir pasikartojančių variantų. Nustatykite taisyklę hero vaizdams ir jos laikykitės.
- Duomenų bazės priežiūra. Tikrinkite augančius žurnalus, pasibaigusius laikinus duomenis, senas revizijas ir nenaudojamas lenteles, likusias po pašalintų papildinių. Duomenų bazė – tai vieta, kur WordPress laiko turinį ir nustatymus.
- Atnaujinimų kontrolė. Laikykite WordPress branduolį, temą ir papildinius atnaujintus, bet darykite tai su pokyčių kontrole. Atnaujinimai gali atnešti naujų resursų ar naujos elgsenos, todėl pravartu turėti paprastą būdą pastebėti, kas pasikeitė.
- Kritiniai keliai. Testuokite puslapius, kurie uždirba pinigus: pagrindinius landing puslapius, kontaktų formas, rezervavimo žingsnius, checkout. Tai puslapiai, kur „pakankamai greitas” greitis nėra pakankamai geras.
Čia esmė ne balo vaikymasis. Esmė – palaikyti svetainę nuspėjamą. Nuspėjamos svetainės geriau veikia su cache, rečiau lūžta ir jas lengviau plėsti, nemokant našumo kainos kiekvieną kartą.
Kaip vertinti sprendimus: praktinis klausimų sąrašas prieš „optimizuojant”
Tai rėmai pokalbiui su rangovu ar komanda, kad sprendimai būtų pagrįsti, o ne „patobulinti dėl patobulinimo”.
Optimizavimas dažnai prasideda per vėlai. Pirma atsiranda sunkus puslapis, tada ieškoma, kaip jį „pagreitinti”. Praktikoje daug geresnis kelias yra prieš priimant sprendimą paklausti kelių teisingų klausimų. Jie greitai parodo, ar problema architektūroje, ar tik smulkmenose.
Žemiau pateikti klausimai nėra pažadas, kad viskas bus greita. Jie padeda susitarti dėl prioritetų ir atsakomybės. Ir padeda išvengti situacijos, kai pageriname vieną vietą, bet pasunkiname tris kitas.
Ką krausim pirmame ekrane ir kodėl?
Pirmas ekranas yra tai, ką žmogus pamato dar neslinkdamas. Tai ne tik dizainas, tai ir tai, kas turi būti atsisiųsta ir paleista naršyklėje, kad vaizdas būtų stabilus.
Klauskite: kas čia privaloma, kad lankytojas suprastų pasiūlymą ir galėtų veikti? Paprastai pakanka aiškaus teksto, vieno vizualo ir vieno veiksmo mygtuko. Jei pirmame ekrane dedame video foną, animacijas, kelias karuseles ir dar pokalbių langą, tai jau ne „gražiau”. Tai sąmoningas pasirinkimas už greitį mokėti funkcijomis.
Ką galim išmesti, o ne optimizuoti?
Dažnas klaidingas instinktas yra optimizuoti viską, ką turime. Bet pigiausias kilobaitas yra tas, kurio išvis nesiunčiame. Tas pats su skriptais. Geriausias JavaScript yra tas, kurio nereikia vykdyti.
Klauskite tiesiai: ar ši dalis realiai padeda parduoti, aiškinti ar sutaupo laiką? Jei atsakymas miglotas, verta ją pašalinti arba bent jau perkelti į antrinį puslapį. Mano praktinis vertinimas: daugelyje verslo svetainių karuselės ir sudėtingi „feature” blokai duoda mažai, bet kainuoja daug. Vienas geras argumentuotas blokas dažnai laimi prieš tris efektingus.
Kas yra dinamiška ir ar to reikia kiekvienam?
Dinamiškas turinys yra tai, kas generuojama ar keičiasi kiekvieną kartą, kai puslapis atidaromas. Pavyzdžiui, personalizuotos rekomendacijos, realaus laiko kainos, filtrai, paieška, kalendoriai.
Klauskite: ar dinamiškumas būtinas visiems lankytojams, ar tik daliai? Ar tai turi būti pagrindiniame puslapyje, ar gali atsirasti tik tada, kai žmogus paspaudžia? Kartais geras kompromisas yra paprastas statinis vaizdas ir aiški nuoroda į vietą, kur dinamika tikrai reikalinga. Taip išlaikomas greitis ten, kur jis svarbiausias.
Kokia trečių šalių skriptų nauda ir ar ji didesnė už kainą?
Trečių šalių skriptai yra kodas, kurį įkeliame iš išorinių sistemų, pavyzdžiui, analitikos, reklamos, live chat, žemėlapių, A/B testų, booking platformų. Jie dažnai būna nematomi, bet daro didelę įtaką, nes naršyklė turi atsisiųsti, paleisti ir palaikyti ryšį su kitais serveriais.
Klauskite: kokį konkretų sprendimą šis skriptas leidžia priimti arba kokią užduotį jis išsprendžia? Kas jį naudos kas savaitę, ne kartą per metus? Kas bus atsakingas už jo peržiūrą ir pašalinimą, jei jis nepasiteisins? Jei atsakymas yra „gal pravers”, dažniausiai tai ženklas, kad dar anksti jį dėti į svarbiausius puslapius.
Kaip sprendimas paveiks priežiūrą po 6-12 mėn.?
Greitis nėra vien šios savaitės klausimas. Lėtesnės svetainės dažnai tampa lėtesnės dar greičiau, nes jas sunkiau prižiūrėti, testuoti ir atnaujinti.
Klauskite: ar šis sprendimas yra standartinis WordPress kelias, ar nestandartinis apėjimas? Ar jis priklauso nuo vieno įskiepio ar vieno žmogaus? Ar jį galima lengvai išjungti nepakenkiant visam puslapiui? Ir dar vienas paprastas testas: jei po metų norėsime pakeisti tiekėją ar komandą, ar nauji žmonės supras, kas čia padaryta, be kelių dienų „archeologijos”?
Jei norite greitesnių sprendimų pokalbiuose, paprašykite rangovo pateikti ne tik „ką darom”, bet ir „ko nedarom”. Kai žmogus geba aiškiai pasakyti, ko atsisako ir kodėl, dažniausiai tai ženklas, kad architektūra valdoma, o ne tiesiog lipdoma.
DUK
Ką sako wordpress svetainių kūrėjai
Dirbant su WordPress projektais dažnai matome tą patį vaizdą: greitis pradžioje būna geras, o vėliau išsisklaido, nes kiekvienas naujas poreikis pridedamas be bendro plano. Dažna problema yra ta, kad niekas nebegrįžta prie pradinės logikos. Praktikoje mes dažnai pradedame nuo puslapio paskirties patikrinimo, nes tada iš karto aiškėja, kas turi būti pirmame ekrane, o kas gali būti vėliau arba visai nebūtina.
Rami išvada tokia: greita svetainė dažniausiai nėra ta, kurią „prispraudė” optimizacijomis pabaigoje, o ta, kuri nuo pradžių turi aiškią struktūrą ir taisykles, ką leidžiama daryti turiniui. Jei architektūra miglota, bet koks papildomas elementas kainuos vis brangiau, tiek našumu, tiek valdymu. Todėl verta rinktis mažiau, bet tvarkingai, ir tai beveik visada atsiperka realiame naudojime.
Panašūs straipsniai
Peržiūrėkite kitus mūsų ekspertų sukurtus straipsnius apie svetainių kūrimą. Galbūt rasite Jums įdomias temas.