Saturs
- Palēnināšanās cena
- Satura piegādes tīkli
- Turpmākās metodes
- Apsvērumi par iepriekšēju iegādi un iepriekšēju sagatavošanu
- Ajax satura ielāde
Šis raksts pirmo reizi parādījās žurnāla .net 231. numurā - pasaulē vislabāk pārdotajā tīmekļa dizaineru un izstrādātāju žurnālā.
Ātrumam jābūt svarīgam katrai vietnei. Tas ir labi zināms fakts, ka Google meklēšanas rezultātiem kā vietnes rangu izmanto vietnes ātrumu. Tas mums saka, ka apmeklētāji dod priekšroku ātrām vietnēm - tur nav pārsteigums!
Jakobs Nīlsens 1993. gadā rakstīja par trim reakcijas laika ierobežojumiem; lai gan pētījums ir vecs pēc interneta standartiem, mūsu psiholoģija starp 19 gadiem nav daudz mainījusies. Viņš norāda, ka, ja sistēma reaģē mazāk nekā 0,1 sekundes laikā, tā tiks uztverta kā acumirklīga, savukārt atbildes, kas ātrākas par vienu sekundi, ļauj lietotāja domu plūsmai palikt nepārtrauktai. Tīmekļa lapas ielāde 0,1 sekundes laikā, iespējams, nav iespējama; aptuveni 0,34 sekundes ir Google UK labākais ielādes laiks, tāpēc tas kalpo kā reālāks (lai arī vērienīgs) etalons. Lappuses ielāde kaut kur aptuveni 0,34 līdz 1 sekundē ir sasniedzama un svarīga.
Palēnināšanās cena
Šāda veida mērķiem ir reāla ietekme uz jūsu vietni un uzņēmējdarbību. Google Marissa Mayer 2006. gadā runāja par eksperimentu, kurā meklētājprogrammas atdoto rezultātu skaits tika palielināts līdz 30. Tas palēnināja lapas ielādes laiku par aptuveni 500 ms, un tam tika piešķirts datplūsmas kritums par 20%. Tikmēr Amazon mākslīgi aizkavēja lapas ielādi ar 100 ms soli un atklāja, ka "pat ļoti maza kavēšanās radītu ievērojamus un dārgus ieņēmumu kritumus".
Citas nelabvēlīgas asociācijas, kas saistītas ar lēnām vietnēm, ir mazināta uzticamība, sliktāka uztveramā kvalitāte un vietne tiek uzskatīta par mazāk interesantu un pievilcīgu. Palielināta lietotāju neapmierinātība un paaugstināts asinsspiediens ir vēl divi efekti, kurus mēs visi zināmā laikā esam pieredzējuši! Bet kā mēs varam pārliecināties, ka mūsu vietnes tiek ielādētas pietiekami ātri, lai izvairītos no šiem jautājumiem?
Viena no pirmajām lietām, kas jāaplūko, ir HTML koda lielums. Iespējams, ka šī ir viena no visvairāk aizmirstajām vietām, iespējams, tāpēc, ka cilvēki pieņem, ka mūsdienu platjoslas savienojumiem tā vairs nav tik aktuāla. Dažas satura pārvaldības sistēmas ir samērā liberālas, salīdzinot ar to apjomu, kas ir viens no iemesliem, kāpēc var būt labāk izveidot pašmāju rokdarbus.
Kā vadlīnijas jums vajadzētu būt iespējai viegli ievietot lielāko daļu lapu 50 KB HTML kodā, un, ja jums ir mazāks par 20 KB, jūs darāt to ļoti labi. Acīmredzot ir izņēmumi, taču tas ir diezgan labs īkšķis.
Ir arī svarīgi paturēt prātā, ka tagad mobilajās ierīcēs cilvēki biežāk pārlūko pilnas vietnes. Ātruma atšķirības starp vietnēm, kuras skatās no mobilā, bieži ir vairāk pamanāmas, jo tām ir lēnāki pārraides ātrumi nekā vadu savienojumiem. Divas konkurējošas vietnes ar 100 KB lieluma atšķirību vienā lapā var nozīmēt vairāk nekā vienas sekundes ielādes laika starpību dažos lēnos mobilajos tīklos - arī Jakoba Nīlsena norādītajā “pārtrauktās domu plūsmas” reģionā. Trimmera, ātrākas vietnes pārlūkošana būs daudz mazāk nomākta, dodot izteiktu konkurences priekšrocību pār treknākām vietnēm un dodoties tālu uz atkārtotu apmeklējumu veicināšanu.
Viena no svarīgākajām iezīmēm lielākajai daļai tīmekļa serveru ir iespēja kalpot HTML saspiestā formātā. Tā kā HTML pēc būtības satur daudz atkārtotu datu, tas padara to par perfektu saspiešanas kandidātu. Piemēram, vienas mājas lapas 18,1 KB HTML tiek samazināts līdz 6,3 KB, ja to piegādā saspiestā formātā. Tas ir 65 procentu ietaupījums! Saspiešanas algoritmu efektivitāte palielinās, jo lielāks teksta korpuss viņiem jāstrādā, tāpēc jūs redzēsiet lielākus ietaupījumus ar lielākām HTML lapām. 138.1K populārā foruma lapa tiek samazināta līdz 25.7K, kad tā tiek saspiesta, tādējādi ietaupot vairāk nekā 80 procentus - kas var ievērojami uzlabot kopējo resursu pārsūtīšanas laiku.
HTML apkalpošanai šajā formā praktiski nav negatīvu; ikvienam vajadzētu to iespējot visam HTML saturam.Dažiem tīmekļa serveriem ir atšķirīgi statiskā un dinamiski ģenerētā satura saspiešanas iestatījumi, tāpēc, ja iespējams, ir vērts pārliecināties, ka jūs servējat saspiestu saturu abiem.
Satura piegādes tīkli
Satura piegādes tīkli (pazīstami kā CDN) var arī ievērojami uzlabot jūsu vietnes ielādes laiku. CDN ir serveru kolekcija, kas izplatīta visā pasaulē un kuros visi satur jūsu satura kopijas. Kad lietotājs pieprasa attēlu no jūsu vietnes, kas mitināts CDN, attēla apkalpošanai tiks izmantots lietotājam ģeogrāfiski vistuvāk esošais CDN serveris.
Ir pieejami daudzi CDN pakalpojumi. Daži no tiem ir ļoti dārgi, taču reklamē, ka tie piedāvās labāku veiktspēju nekā lētāki CDN. Bezmaksas CDN pakalpojumi arī ir sākuši augt, un, iespējams, ir vērts tos eksperimentēt, lai noskaidrotu, vai tie var uzlabot veiktspēju jūsu vietnē.
Viens svarīgs apsvērums, lietojot CDN, ir nodrošināt pareizu tā iestatīšanu, lai nezaudētu SEO vērtību. Atkarībā no jūsu vietnes rakstura, iespējams, saņemat lielu trafiku no jūsu domēnā mitinātajiem attēliem, un, pārvietojot tos uz ārēju domēnu, tas var nelabvēlīgi ietekmēt jūsu datplūsmu. Amazon S3 pakalpojums ļauj norādīt apakšdomēnu uz tā CDN, kas ir ļoti vēlama CDN funkcija.
Satura rādīšanai citā domēnā (piemēram, CDN) vai apakšdomēnā savam domēna nosaukumam, kurā netiek iestatīti sīkfaili, ir vēl viena galvenā priekšrocība. Kad domēns ir iestatīts sīkfails, pārlūks nosūta sīkfailu datus ar katru pieprasījumu visiem resursiem tajā pašā domēnā. Biežāk sīkdatņu dati nav nepieciešami statiskam saturam, piemēram, attēliem, CSS vai JavaScript failiem. Tīmekļa lietotāju augšupielādes ātrums bieži vien ir daudz lēnāks nekā pieejamais lejupielādes ātrums, kas dažos gadījumos var ievērojami palēnināt lapas ielādes laiku. Izmantojot statusa saturam citu domēna nosaukumu, pārlūkprogrammas nesūtīs šos nevajadzīgos sīkfailu datus, jo tiem ir stingras starpdomēnu politikas. Tas var ievērojami paātrināt pieprasījumu laiku katram resursam.
Vietņu sīkfaili arī var aizņemt lielāko daļu HTTP pieprasījuma; 1500 baiti ir aptuveni visbiežāk izmantotais vienas paketes ierobežojums lielajiem tīkliem, tādēļ, ja jūs varat saglabāt savus HTTP pieprasījumus zem šī ierobežojuma, viss HTTP pieprasījums jānosūta vienā paketē. Tas var piedāvāt uzlabojumus lapu ielādes laikos. Google iesaka, lai jūsu sīkfailu izmērs būtu mazāks par 400 baitiem - tas ļoti palīdz saglabāt jūsu vietņu HTTP pieprasījumus zem viena iepakojuma / 1500 baitu ierobežojuma.
Turpmākās metodes
Ir arī citas, vieglāk īstenojamas metodes, kas var sniegt lielas priekšrocības jūsu vietnes ātrumam. Viens no tiem ir ievietot JavaScript failus HTML dokumenta beigās, tieši pirms beigu pamatteksta, jo pārlūkprogrammās ir ierobežoti resursu daudzuma lejupielādes ierobežojumi no viena un tā paša resursdatora.
Sākotnējā HTTP 1.1 specifikācija, kas rakstīta 1999. gadā, iesaka pārlūkprogrammām no katra resursdatora nosaukuma paralēli lejupielādēt tikai divus resursus. Bet mūsdienu pārlūkprogrammās pēc noklusējuma ierobežojums ir aptuveni seši. Ja jūsu tīmekļa lapai ir vairāk nekā seši ārējie resursi (piemēram, attēli / JavaScript / CSS faili), tā var piedāvāt jums labāku veiktspēju, lai tos apkalpotu no vairākiem domēniem (piemēram, apakšdomēna galvenajā domēna nosaukumā vai CDN), lai nodrošinātu pārlūkprogrammu nepārsniedz maksimālo paralēlo lejupielāžu ierobežojumu.
Tā vietā, lai sadalītu vairākus pieprasījumus dažādos domēnos, varat apsvērt to apvienošanu. Katram HTTP pieprasījumam ir pievienota pieskaitāmā summa. Vairāki desmiti attēlu, piemēram, ikonas jūsu vietnē, tiek izmantoti kā atsevišķi resursi, radot daudz izšķērdīgu papildu izmaksu un izraisot jūsu vietnes palēnināšanos, bieži vien ievērojamu. Apvienojot savus attēlus vienā attēlā, kas pazīstams kā “sprite sheet”, jūs varat samazināt nepieciešamo pieprasījumu skaitu. Lai parādītu attēlu, to definējat CSS, iestatot elementa platumu un augstumu tā attēla platumam un augstumam, kuru vēlaties parādīt, pēc tam iestatot sprite lapas fonu. Izmantojot background-position īpašumu mēs varam pārvietot fona sprite lapu pozīcijā, lai tā jūsu vietnē būtu redzama kā paredzētais attēls.
Sprite loksnes piedāvā arī citas priekšrocības. Ja izmantojat peles kursora attēlus, to glabāšana vienā un tajā pašā sprite lapā nozīmē, ka, uzsākot peles kursora pārvietošanu, nav kavēšanās, jo peles kursora attēls jau ir ielādēts sprite lapā! Tas var ievērojami uzlabot lietotāja uztverto ielādes laiku un izveidot daudz atsaucīgāku vietni.
Visu citu attēlu izmēru norādīšana img /> tagi ir arī svarīgs faktors, lai palielinātu jūsu tīmekļa vietnes uztverto ielādes laiku. Izstrādātājiem parasti nav skaidri noteikts lapu platums un augstums. Tas var izraisīt lapas lieluma palielināšanos lēcienos, kad katrs attēls (daļēji) tiek ielādēts, padarot lietas lēnākas. Ja ir iestatīti izteikti izmēri, pārlūkprogramma var rezervēt vietu attēlam, kad tas tiek ielādēts, apturot lapas lieluma maiņu un dažkārt ievērojami uzlabojot lietotāja uztverto ielādes laiku.
Ko tad mēs vēl varam darīt, lai to uzlabotu? Iepriekšēja ielāde ir viena no šādām funkcijām, kas pieejama HTML5. Iepriekšēja ielāde ļauj ielādēt lapas un resursus, pirms lietotājs tos faktiski pieprasījis. Pašlaik tā atbalsts ir ierobežots ar Firefox un Chrome (ar alternatīvu sintaksi). Tomēr tā ieviešanas vieglums un noderīgums, lai uzlabotu jūsu tīmekļa lapas uztverto ielādes laiku, ir tik liels, ka ir jāapsver ieviešana.
! —Firefox Prefetching -> link rel = "prefetch" href = "http://www.example.com/page2.html">! - Chrome Prerender -> link rel = "prerender" href = "http: / /www.example.com/page2.html">!— Abi vienā rindā -> link rel = "prefetch prerender" href = "http://www.example.com/page2.html">
Starp iepriekšēju ielādēšanu un pirmrenderēšanu ir uzvedības atšķirība. Mozilla's prefetch ielādēs augšējā līmeņa resursu konkrētam URL, parasti pašu HTML lapu, un šeit ielāde tiek pārtraukta. Google pirmsrenderēšana tiek ielādēti arī bērnu resursi un Google vārdiem sakot “veic visu nepieciešamo darbu, lai parādītu lapu lietotājam, faktiski to nerādot, līdz lietotājs noklikšķina”.
Apsvērumi par iepriekšēju iegādi un iepriekšēju sagatavošanu
Bet šīs funkcijas izmantošana ietver arī svarīgus apsvērumus. Ja priekšpiegādājat / iepriekš ielādējat pārāk daudz līdzekļu vai lapu, var ciest visa lietotāja pārlūkošanas pieredze; ja jums ir kāda servera puses statistika, tā var stipri izkropļot. Ja lietotājs nenoklikšķina uz iepriekš ielādētā resursa un aiziet no jūsu vietnes, statistikas izsekotājs apmeklējumu var skaitīt kā divus, nevis faktiskos. Tas var būt maldinošs attiecībā uz svarīgu metriku, piemēram, atlēcienu līmeni.
Chrome pirmsrenderēšana ir vēl viens brīdinājums, par kuru izstrādātājiem jāzina, ka iepriekš iesniegtā lapa izpildīs JavaScript. Priekšrenderētājs ielādēs lapu gandrīz tieši tāpat kā tad, ja lietotājs ir noklikšķinājis uz saites. Pārlūkprogramma Chrome nesūta īpašas HTTP galvenes ar priekšrenderētāju; tomēr lapas redzamības API ļauj atšķirt, vai lapa tiek iepriekš sniegta. Tas atkal ir ārkārtīgi svarīgi visiem jūsu izmantotajiem trešo pušu skriptiem, piemēram, reklāmas skriptiem un statistikas izsekotājiem (Google Analytics jau izmanto lapas redzamības API, lai jums par to nebūtu jāuztraucas). Ja atkal nepareizi apstrādājat šos līdzekļus, izmantojot lapas redzamības API, jūs riskējat sagrozīt svarīgu metriku.
Izmantojot prefetch un pirmsrenderēšana par lapotu saturu, iespējams, ir droša un noderīga ieviešana - piemēram, apmācību tīmekļa lapā, kas ir sadalīta vairākās sadaļās. Īpaši attiecībā uz tādu saturu kā apmācība, iespējams, ir svarīgi ievērot Nielsena “nepārtrauktās domu plūsmas” robežas.
Google Analytics var arī sniegt vērtīgas norādes par to, kuras lapas jūs varētu vēlēties iepriekš sagatavot / ielādēt. Izmantojot lapā ievietoto analīzi, varat noteikt, uz kuras sākumlapas saites, visticamāk, tiks noklikšķināts. Dažos gadījumos ar ļoti definētiem aicinājumiem uz darbību šis procents var būt ārkārtīgi augsts - kas padara to par lielisku kandidātu iepriekšējai ielādei.
Gan iepriekšēja, gan iepriekšēja atveidošana strādā starpdomēniem - neparasti liberāla nostāja pārlūkprogrammām, kas parasti ir ārkārtīgi stingra attiecībā uz piekļuvi starpdomēniem. Tomēr tas, iespējams, darbojas Google un Mozilla labā, jo viņi vairākos veidos var radīt ātrāku pārlūkošanas pieredzi saviem lietotājiem, piedāvājot ievērojamu konkurences priekšrocību salīdzinājumā ar citām pārlūkprogrammām, kas vēl neatbalsta šādas funkcijas.
Prefetching un jo īpaši priekšrenderēšana ir spēcīgi rīki, kas var ievērojami uzlabot tīmekļa lapu uztverto ielādes laiku. Bet ir svarīgi saprast, kā tie darbojas, lai jūsu lietotāja pārlūkošanas pieredzi tieši un negatīvi neietekmētu.
Ajax satura ielāde
Vēl viens veids, kā uzlabot ielādes laiku, ir izmantot Ajax, lai ielādētu saturu, nevis atkārtoti ielādētu visu lapu - efektīvāk, jo tas ielādē tikai izmaiņas, nevis katlu, kas katru reizi ieskauj saturu.
Daudzas Ajax ielādes problēma ir tā, ka tā var justies kā nedabiska pārlūkošanas pieredze. Ja pogas netiek izpildītas pareizi, poga “Atpakaļ” un “Uz priekšu” nedarbosies tā, kā lietotājs sagaida, un tādu darbību veikšana kā lapu grāmatzīmēšana vai lapas atsvaidzināšana rīkojas arī negaidīti. Veidojot vietnes, ieteicams netraucēt šādu zemu uzvedību - tas ir ļoti nepatīkams un nedraudzīgs lietotājiem. Spilgts piemērs tam būtu centieni, uz kuriem dažas vietnes dodas, lai atspējotu peles labo klikšķi uz savām tīmekļa lapām kā veltīgu mēģinājumu novērst autortiesību pārkāpumus. Lai gan Ajax ieviešana neietekmē pārlūka darbību ar tādu pašu nolūku atspējot labo klikšķi, efekti ir līdzīgi.
HTML5 kaut kādā veidā risina šīs problēmas ar History API. Tas tiek labi atbalstīts pārlūkprogrammās (izņemot Internet Explorer, lai gan to plānots atbalstīt IE10). Strādājot ar HTML5 vēstures API, mēs varam ielādēt saturu ar Ajax, vienlaikus simulējot lietotājiem “parastu” pārlūkošanas pieredzi. Pareizi lietojot aizmugures, uz priekšu un atsvaidzināšanas pogas, viss darbojas kā paredzēts. Var atjaunināt arī adreses joslas URL, kas nozīmē, ka grāmatzīmes tagad atkal darbojas pareizi. Ja tas tiek ieviests pareizi, jūs varat noņemt daudz atkārtotu resursu ielādi, kā arī graciozi atkāpties pārlūkiem ar JavaScript atspējotu.
Tomēr ir liels mīnuss: atkarībā no vietnes, kuru mēģināt izveidot, sarežģītības un funkcijas, ir grūti ieviest Ajax satura ielādi ar History API lietotājam neredzamā veidā. Ja vietne izmanto arī servera puses skriptu, jūs varat arī pierakstīt divas reizes: vienu reizi JavaScript un vēlreiz serverī - tas var izraisīt uzturēšanas problēmas un neatbilstības. To pilnveidot var būt grūti un laikietilpīgi, taču, ja tas darbojas atbilstoši iecerētajam, jūs varat ievērojami samazināt faktisko, kā arī uztverto lietotāja ielādes laiku.
Mēģinot uzlabot vietnes ātrumu, var rasties dažas neatrisināmas problēmas. Kā minēts šī raksta sākumā, nav noslēpums, ka Google kā lapas rādītāju izmanto lapas ātrumu. Tam vajadzētu būt ievērojamai motivācijai uzlabot jūsu vietnes ātrumu. Tomēr jūs varat pamanīt, ka, izmantojot tādus resursus kā Google Webmaster Tools lapu ātruma pārskati, tie ziņos par lēnāku ielādes laiku, nekā jūs varētu gaidīt.
Cēlonis var būt trešo pušu skripti, piemēram, Facebook Like pogas vai Tweet pogas. Bieži vien tiem var būt simtiem milisekunžu gaidīšanas laiks, kas var ievērojami pavilkt visas vietnes ielādes laiku. Bet tas nav arguments šo skriptu noņemšanai - iespējams, svarīgāk ir, lai jūsu vietnē būtu sociālo mediju pogas. Šīs pogas parasti aizņem salīdzinoši nelielas vietas jūsu lapā, tāpēc tās būtiski neietekmēs apmeklētāja uztverto ielādes laiku - tas ir tas, par ko mums galvenokārt vajadzētu rūpēties, veicot ātruma optimizāciju.
Atklājiet 101 CSS un Javascript apmācību mūsu māsas vietnē Creative Bloq.
