Kā paātrināt lapas ielādes ātrumu
Deniss Fedotovs (deni2s), 11.06.2007., 22:40Pēc lietojamības eksperta Džeikoba Nīlsena domām, ir labi, ja lapa ielādējas pārlūkprogrammā 1 sekundes laikā. Kā to panākt?
Paskatīsimies pēc kārtas visus procesus, kuri notiek pēc tam kad serveris ir saņēmis pieprasījumu pēc kādas lapas, un kā šos procesus iespējams ietekmēt.
Kods
Pirmām kārtām, ja lapa nav statiska (nav gatava lapa uz servera HTML kodā), bet gan HTML tiek veidots dinamiski, izmantojot PHP, Perl vai jebkuru citu valodu, tad jācenšas pēc iespējas optimizēt programmas kods, lai tas izpildītos pēc iespējas ātrāk. Protams, ka izpildes ātrums ir atkarīgs arī no servera parametriem – tā ātrdarbības, atmiņas daudzuma un citiem parametriem, taču diemžēl bieži vien mājaslapu veidotājiem nav iespējas ietekmēt šos resursus.
Informācijas kešošana uz servera
Cita lieta, kuru var izmantot, lai paātrinātu mājaslapas darbību, ir kešošana. Piemēram, ja mums mājaslapā ir jāattēlo nākamās dienas koncertu saraksts, kurš tiek veidots no ierakstiem datubāzē, tad katru reizi dienas laikā, kad kāds apmeklēs šo lapu, tiks pieprasīta un apstrādāta viena un tā pati informācija no datubāzes. Parasti šādu ierakstu atlase un apstrādāšana aizņem salīdzinoši lielu laiku.
Tātad optimizējam to tādā veidā, ka informācija tiek pieprasīta no datubāzes un apstrādāta tikai pirmo reizi pa dienu apmeklētājam atverot lapu un tādos gadījumos, ja tiek mainīta informācija par nākamās dienas koncertiem datubāzē. Pie tam šo apstrādāto informāciju saglabājam datubāzē vai failā un nākamreiz, kad tiek atvērta šī lapa un pieprasīta šī pati informācija, mēs vienkārši attēlojam iepriekš saglabāto informāciju, kura jau ir vienreiz apstrādāta, ieekonomējot gan servera jaudas resursus, gan laiku.
Līdzīgi protams var darīt ar komentāriem zem rakstiem un citu informāciju, kura ir jāatlasa un jāapstrādā konkrētai lapai.
Gzip kompresija
Tad, kad ir izveidota HTML lapa, tad bieži vien tiek izmantota iespēja to sakompresēt izmantojot gzip kompresiju, lai tā aizņemtu mazāk. Ja tiek izmantots PHP un Apache webserveris, tad to parasti var panākt Apache webservera konfigurācijas failā .htaccess ievietojot šādas rindiņas:
Ciparu var norādīt no 0 līdz 9, kas norāda uz kompresijas līmeni. Parasti tiek ieteikts neizmantot lielāku līmeni par 6, jo ieguvumu/patērētās jaudas attiecība sākt palikt nelietderīga. Reāli kompresijas rezultātā ir iespējams samazināt HTML lapas izmēru par 10%-50%, kas ir diezgan liels ieguvums. Pie tam ir iespējams sakompresēt arī CSS un Javascript failus.
Kompresējot ar gzip lapas ieguvums ir lapas izmēra samazināšanās, līdz ar to pie lēnāka interneta pieslēguma šāda lapa nonāks ātrāk no servera līdz lietotājam, kas protams ir liels pluss.
FBIB
Taču gzip kompresijai ir arī savi trūkumi. Viens no tiem, ir tas, ka kompresija var notikt tikai tad, kad PHP kods ir beidzis savu darbību. Tātad jāsagaida, kamēr izpildīsies pilnībā PHP kods, tad lapa tiek kompresēta uz servera un tikai tad tā kompresētā veidā tiek nodota tālāk apmeklētāja pārlūkprogrammai, kura šo lapu atkompresē un tikai tad var attēlot lapas apmeklētāja pārlūkprogrammā.
Neizmantojot gzip kompresiju, lapa var tikt sākta attēlota uz apmeklētāja ekrāna vēl pirms PHP kods ir beidzis savu darbību uz webservera, kas lietotājam šķitīs ātrāk, kaut arī lapas kopējais ielādes laiks var būt daudz ilgāks, nekā tad, ja tiek izmantota gzip kompresija.
Reāli tas notiek tā, ka tiko PHP kods izpildās un sākt dot ārā HTML kodu, tā šis kods jau tiek sūtīts uz lietotājam uz pārlūkprogrammu, kur tas jau tiek attēlots iespēju robežās (lietotājs jau redz lapas sākumu), kamēr PHP kods vēl turpina izpildīties uz servera.
Tāpēc ir cilvēki, kuri uzskata, ka FBIB (First Byte in Browser – pirmais baits pārlūkprogrammā) ir daudz būtiskāks parametrs, nekā visas lapas ielādes ātrums.
Kurš no variantiem ir pareizāks, izmantot gzip kompresiju vai neizmantot – tas laikam ir atkarīgs no konkrētās situācijas.
HTML Headers
Tātad lapa ir izveidota un vajadzības gadījumā arī sakompresēta un tiek nosūtīta uz lapas apmeklētāja pārlūkprogrammu. Izrādās, ka arī pa ceļam mēs varam mazliet piestrādāt pie lapas ielādes ātruma, izmantojot arī šeit kešošanu.
Izmantojot dažādus HTML Headers (PHP kodā, javascript kodā un citās valodās), mēs varam norādīt vai šīs lapas kopiju var saglabāt (un ja var, tad cik ilgi) uz proxy serveriem, kas atrodas starp mājaslapas serveri un lietotāja datoru. Līdz ar to, ja kāds vēlēsies aplūkot šo pašu lapu vēlreiz, iespējams, ka viņam tuvākais proxy serveris atsūtīs saglabāto (kešoto) lapas kopiju – tātad tas aizņems daudz mazāk laika, nevis ja lapa tiktu sūtīta no servera, uz kura lapa tiek veidota.
Te ir jāuzmanās ar to, kuru lapu kopijas drīkst kešot šādā veidā un kuras nē. Citādi var gadīties, ka, ja esmu ielogojies lapā http://www.serveris.lv/lapa/ un tajā rakstīts „Sveiks, Deniss!”, un kāds Pēteris gribēs pēc tam atvērt šo pašu lapu, tad viņam gaidītā „Sveiks, Pēteri!” vietā attēlosies „Sveiks, Deniss!”.
HTML kods
Tātad lapa nonāk veiksmīgi līdz lietotāja pārlūkprogrammai un, ja tai ir pielietota gzip kompresija, tad tā tiek atkompresēta. Ja tā nav kompresēta, tad to mūsdienu pārlūkprogrammas jau sāk mēģināt attēlot jau pēc pirmā baita saņemšanas.
Es uzrakstīju „mēģināt” apzināti, jo bieži vien šie mēģinājumi ir vairāki, kamēr lapa ielādējas pilnībā. Te nu ir ļoti svarīgs korekts kods, lai šādi mēģinājumi būtu pēc iespējas mazāk. Piemēram, ja nav norādīti bildes izmēri HTML kodā, pie
Tiek uzskatīts, ka ir slikts stils izmantot tabulas lapas izkārtojuma attēlošanai. Viens no iemesliem tiek minēts tas, ka tabulas tiek attēlotas tikai tad, kad tās un to saturs ir ielādēts pilnībā. Nemāku spriest, kā to dara pārlūkprogrammas mūsdienās, taču zinu pavisam noteikti pēc savas pieredzes, ka xHTML kodā veidota tabula uz FireFox 2.0 pārlūkprogrammas tiek sākta attēlota vēl pirms tabula ir ielādējusies pārlūkā pilnībā.
Pieprasījumu skaits
Nākamais, ko dara pārlūkprogramma, kad saņem HTML kodu pilnībā vai daļēji, tas ir tā veido pieprasījumus pēc bildēm, CSS failiem, javascript failiem un citiem, kuri ir norādīti saņemtajā HTML kodā. Te nu atkal, ņemot vērā tīmekļa darbības principus, jāsaprot, ka jo mazāk būs šādu pieprasījumu skaits, jo ātrāk tie tiks izpildīti un saņemta nepieciešamā informācija – tātad arī lapa ielādēsies ātrāk.
Kešošana, kuru veic pārlūkprogramma
Nepieminēju par vēl vienu kešošanas veidu – arī pārlūkprogramma veic HTML apmeklēto lapu un tajo iekļauto elementu kešošanu, ja vien lietotājs to ir atļāvis un ja pieprasītā lapa to pieļauj – šos parametrus var norādīt arī HTML kodā
Līdz ar to, ja tas ir iespējams, tad nākamreiz apmeklējot to pašu lapu, tā tiks nevis pieprasīta no servera, bet izmantota tās kešotā kopija, kura glabājas turpat uz lietotāja datora.
Neapmeklēto lapu kešošana
Ir vēl viens ļoti interesants veids, kuru izmanto arī Google, kā paātrināt lapas ielādes ātrumu – proti piespiest pārlūku ielādēt lapu kešā, pirms tā tiek pieprasīta. Piemēram, ja mēs ielādējam pārlūkprogrammā lapu ar kāda raksta pirmo daļu, tad, kamēr mēs to lasām, pārlūkprogramma mums nemanot var ielādēt kešā lapu, kurā ir raksta otrā daļa, pieņemot, ka tā būs nākamā lapa, kuru mēs vēlēsimies aplūkot. Šādu procesu sauc par „prefetching”. Tad kad mēs noklikšķināsim, lai pieprasītu lapu ar raksta otro daļu, tā jau būs ielādēta kešā un mums nebūs jāgaida, kamēr tā tiks nosūtīta no servera.
„Prefetching” efektu var panākt ar javascript palīdzību, taču ir arī cita iespēja.
Uz Mozilla bāzētie pārlūki un Google Web Accelerator (kuru var izmantot kopā ar Internet Explorer), atbalsta HTML tagus, kuri norāda, kuru lapu prefetčot. Šie tagi ir šādi:
Javascript un AJAX
AJAX tehnoloģiju, kas balstās uz javascript parasti izmanto, lai nosūtītu datus (pieprasījumu) uz serveri, saņemtu atbildi no tā un ņemot vērā saņemto informāciju nepārlādējot visu lapu pārlūkprogrammā, izmainīt tikai daļu no lapas. Lielisks piemērs AJAX tehnoloģijas izmantošanai ir redzams draugiem.lv.
Pozitīvais AJAX izmantošanā parasti ir tas, ka netiek zaudēts laiks, kamēr pārlādējās visa lapa un arī serveris ir mazāk noslogots, jo tam ir jāsūta informācija nevis par visu lapu, bet tikai par vienu tās daļu - tātad stipri mazāk.
Negatīvais AJAX izmantošanā ir dažas lietojamības problēmas (javascript nestrādā uz mobilajām ierīcēm, mainot lapas saturu izmantojot AJAX iespējas, nevar tikt pie iepriekšējā lapas izskata nospiežot pārlūkprogrammas "Back" pogu un vēl dažas citas). Taču ja AJAX izmanto tikai kā papildus alternatīvu iespēju esošai iespējai, nevis esošās iespējas vietā (lai iespēja nezustu ja javascript ir atslēgts), tad daudzas lietojamības problēmas tiek atrisinātas un lietojamība tikai palielinās, jo AJAX risinājumi strādā ātrāk par tradicionālajiem, klasiskajiem risinājumiem.
Nobeigumā
Protams, ka ir arī citas metodes, kā tiek paātrināts mājaslapas ielādes ātrums, šeit tika apskatītas tikai dažas vienkāršākas. Beigās padalīšos ar noderīgu saiti uz kādu pakalpojumu, kurš gan, manuprāt, nepretendē uz pašu korektāko informāciju, bet tomēr dod kādu priekšstatu dažiem aspektiem, kā varētu censties uzlabot norādītās lapas ielādes ātrumu - Web Page Analyzer.
Kods
Pirmām kārtām, ja lapa nav statiska (nav gatava lapa uz servera HTML kodā), bet gan HTML tiek veidots dinamiski, izmantojot PHP, Perl vai jebkuru citu valodu, tad jācenšas pēc iespējas optimizēt programmas kods, lai tas izpildītos pēc iespējas ātrāk. Protams, ka izpildes ātrums ir atkarīgs arī no servera parametriem – tā ātrdarbības, atmiņas daudzuma un citiem parametriem, taču diemžēl bieži vien mājaslapu veidotājiem nav iespējas ietekmēt šos resursus.
Informācijas kešošana uz servera
Cita lieta, kuru var izmantot, lai paātrinātu mājaslapas darbību, ir kešošana. Piemēram, ja mums mājaslapā ir jāattēlo nākamās dienas koncertu saraksts, kurš tiek veidots no ierakstiem datubāzē, tad katru reizi dienas laikā, kad kāds apmeklēs šo lapu, tiks pieprasīta un apstrādāta viena un tā pati informācija no datubāzes. Parasti šādu ierakstu atlase un apstrādāšana aizņem salīdzinoši lielu laiku.
Tātad optimizējam to tādā veidā, ka informācija tiek pieprasīta no datubāzes un apstrādāta tikai pirmo reizi pa dienu apmeklētājam atverot lapu un tādos gadījumos, ja tiek mainīta informācija par nākamās dienas koncertiem datubāzē. Pie tam šo apstrādāto informāciju saglabājam datubāzē vai failā un nākamreiz, kad tiek atvērta šī lapa un pieprasīta šī pati informācija, mēs vienkārši attēlojam iepriekš saglabāto informāciju, kura jau ir vienreiz apstrādāta, ieekonomējot gan servera jaudas resursus, gan laiku.
Līdzīgi protams var darīt ar komentāriem zem rakstiem un citu informāciju, kura ir jāatlasa un jāapstrādā konkrētai lapai.
Gzip kompresija
Tad, kad ir izveidota HTML lapa, tad bieži vien tiek izmantota iespēja to sakompresēt izmantojot gzip kompresiju, lai tā aizņemtu mazāk. Ja tiek izmantots PHP un Apache webserveris, tad to parasti var panākt Apache webservera konfigurācijas failā .htaccess ievietojot šādas rindiņas:
php_flag zlib.output_compression On
php_value zlib.output_compression_level 5
Ciparu var norādīt no 0 līdz 9, kas norāda uz kompresijas līmeni. Parasti tiek ieteikts neizmantot lielāku līmeni par 6, jo ieguvumu/patērētās jaudas attiecība sākt palikt nelietderīga. Reāli kompresijas rezultātā ir iespējams samazināt HTML lapas izmēru par 10%-50%, kas ir diezgan liels ieguvums. Pie tam ir iespējams sakompresēt arī CSS un Javascript failus.
Kompresējot ar gzip lapas ieguvums ir lapas izmēra samazināšanās, līdz ar to pie lēnāka interneta pieslēguma šāda lapa nonāks ātrāk no servera līdz lietotājam, kas protams ir liels pluss.
FBIB
Taču gzip kompresijai ir arī savi trūkumi. Viens no tiem, ir tas, ka kompresija var notikt tikai tad, kad PHP kods ir beidzis savu darbību. Tātad jāsagaida, kamēr izpildīsies pilnībā PHP kods, tad lapa tiek kompresēta uz servera un tikai tad tā kompresētā veidā tiek nodota tālāk apmeklētāja pārlūkprogrammai, kura šo lapu atkompresē un tikai tad var attēlot lapas apmeklētāja pārlūkprogrammā.
Neizmantojot gzip kompresiju, lapa var tikt sākta attēlota uz apmeklētāja ekrāna vēl pirms PHP kods ir beidzis savu darbību uz webservera, kas lietotājam šķitīs ātrāk, kaut arī lapas kopējais ielādes laiks var būt daudz ilgāks, nekā tad, ja tiek izmantota gzip kompresija.
Reāli tas notiek tā, ka tiko PHP kods izpildās un sākt dot ārā HTML kodu, tā šis kods jau tiek sūtīts uz lietotājam uz pārlūkprogrammu, kur tas jau tiek attēlots iespēju robežās (lietotājs jau redz lapas sākumu), kamēr PHP kods vēl turpina izpildīties uz servera.
Tāpēc ir cilvēki, kuri uzskata, ka FBIB (First Byte in Browser – pirmais baits pārlūkprogrammā) ir daudz būtiskāks parametrs, nekā visas lapas ielādes ātrums.
Kurš no variantiem ir pareizāks, izmantot gzip kompresiju vai neizmantot – tas laikam ir atkarīgs no konkrētās situācijas.
HTML Headers
Tātad lapa ir izveidota un vajadzības gadījumā arī sakompresēta un tiek nosūtīta uz lapas apmeklētāja pārlūkprogrammu. Izrādās, ka arī pa ceļam mēs varam mazliet piestrādāt pie lapas ielādes ātruma, izmantojot arī šeit kešošanu.
Izmantojot dažādus HTML Headers (PHP kodā, javascript kodā un citās valodās), mēs varam norādīt vai šīs lapas kopiju var saglabāt (un ja var, tad cik ilgi) uz proxy serveriem, kas atrodas starp mājaslapas serveri un lietotāja datoru. Līdz ar to, ja kāds vēlēsies aplūkot šo pašu lapu vēlreiz, iespējams, ka viņam tuvākais proxy serveris atsūtīs saglabāto (kešoto) lapas kopiju – tātad tas aizņems daudz mazāk laika, nevis ja lapa tiktu sūtīta no servera, uz kura lapa tiek veidota.
Te ir jāuzmanās ar to, kuru lapu kopijas drīkst kešot šādā veidā un kuras nē. Citādi var gadīties, ka, ja esmu ielogojies lapā http://www.serveris.lv/lapa/ un tajā rakstīts „Sveiks, Deniss!”, un kāds Pēteris gribēs pēc tam atvērt šo pašu lapu, tad viņam gaidītā „Sveiks, Pēteri!” vietā attēlosies „Sveiks, Deniss!”.
HTML kods
Tātad lapa nonāk veiksmīgi līdz lietotāja pārlūkprogrammai un, ja tai ir pielietota gzip kompresija, tad tā tiek atkompresēta. Ja tā nav kompresēta, tad to mūsdienu pārlūkprogrammas jau sāk mēģināt attēlot jau pēc pirmā baita saņemšanas.
Es uzrakstīju „mēģināt” apzināti, jo bieži vien šie mēģinājumi ir vairāki, kamēr lapa ielādējas pilnībā. Te nu ir ļoti svarīgs korekts kods, lai šādi mēģinājumi būtu pēc iespējas mazāk. Piemēram, ja nav norādīti bildes izmēri HTML kodā, pie
<img> taga izmantojot atribūtus width=" " un height=" ", tad pārlūkprogramma vēl nezin, cik daudz vietas uz ekrāna jāieplāno bildei, kamēr tā vēl nav ielādēta, tāpēc pārlūkprogrammai nāksies visu pārzīmēt vēlreiz, kad būs zināms, cik tad īsti bilde aizņem vietas uz ekrāna.Tiek uzskatīts, ka ir slikts stils izmantot tabulas lapas izkārtojuma attēlošanai. Viens no iemesliem tiek minēts tas, ka tabulas tiek attēlotas tikai tad, kad tās un to saturs ir ielādēts pilnībā. Nemāku spriest, kā to dara pārlūkprogrammas mūsdienās, taču zinu pavisam noteikti pēc savas pieredzes, ka xHTML kodā veidota tabula uz FireFox 2.0 pārlūkprogrammas tiek sākta attēlota vēl pirms tabula ir ielādējusies pārlūkā pilnībā.
Pieprasījumu skaits
Nākamais, ko dara pārlūkprogramma, kad saņem HTML kodu pilnībā vai daļēji, tas ir tā veido pieprasījumus pēc bildēm, CSS failiem, javascript failiem un citiem, kuri ir norādīti saņemtajā HTML kodā. Te nu atkal, ņemot vērā tīmekļa darbības principus, jāsaprot, ka jo mazāk būs šādu pieprasījumu skaits, jo ātrāk tie tiks izpildīti un saņemta nepieciešamā informācija – tātad arī lapa ielādēsies ātrāk.
Kešošana, kuru veic pārlūkprogramma
Nepieminēju par vēl vienu kešošanas veidu – arī pārlūkprogramma veic HTML apmeklēto lapu un tajo iekļauto elementu kešošanu, ja vien lietotājs to ir atļāvis un ja pieprasītā lapa to pieļauj – šos parametrus var norādīt arī HTML kodā
<meta> tagos.Līdz ar to, ja tas ir iespējams, tad nākamreiz apmeklējot to pašu lapu, tā tiks nevis pieprasīta no servera, bet izmantota tās kešotā kopija, kura glabājas turpat uz lietotāja datora.
Neapmeklēto lapu kešošana
Ir vēl viens ļoti interesants veids, kuru izmanto arī Google, kā paātrināt lapas ielādes ātrumu – proti piespiest pārlūku ielādēt lapu kešā, pirms tā tiek pieprasīta. Piemēram, ja mēs ielādējam pārlūkprogrammā lapu ar kāda raksta pirmo daļu, tad, kamēr mēs to lasām, pārlūkprogramma mums nemanot var ielādēt kešā lapu, kurā ir raksta otrā daļa, pieņemot, ka tā būs nākamā lapa, kuru mēs vēlēsimies aplūkot. Šādu procesu sauc par „prefetching”. Tad kad mēs noklikšķināsim, lai pieprasītu lapu ar raksta otro daļu, tā jau būs ielādēta kešā un mums nebūs jāgaida, kamēr tā tiks nosūtīta no servera.
„Prefetching” efektu var panākt ar javascript palīdzību, taču ir arī cita iespēja.
Uz Mozilla bāzētie pārlūki un Google Web Accelerator (kuru var izmantot kopā ar Internet Explorer), atbalsta HTML tagus, kuri norāda, kuru lapu prefetčot. Šie tagi ir šādi:
<link rel="prefetch" href="http://url.to.prefetch/" />un
<link rel="next" href="http://url.to.prefetch/" />Nevar izmantot
GET metodes pieprasījumus, kā arī https protokolu norādot saiti, kuru vajag prefetčot.Javascript un AJAX
AJAX tehnoloģiju, kas balstās uz javascript parasti izmanto, lai nosūtītu datus (pieprasījumu) uz serveri, saņemtu atbildi no tā un ņemot vērā saņemto informāciju nepārlādējot visu lapu pārlūkprogrammā, izmainīt tikai daļu no lapas. Lielisks piemērs AJAX tehnoloģijas izmantošanai ir redzams draugiem.lv.
Pozitīvais AJAX izmantošanā parasti ir tas, ka netiek zaudēts laiks, kamēr pārlādējās visa lapa un arī serveris ir mazāk noslogots, jo tam ir jāsūta informācija nevis par visu lapu, bet tikai par vienu tās daļu - tātad stipri mazāk.
Negatīvais AJAX izmantošanā ir dažas lietojamības problēmas (javascript nestrādā uz mobilajām ierīcēm, mainot lapas saturu izmantojot AJAX iespējas, nevar tikt pie iepriekšējā lapas izskata nospiežot pārlūkprogrammas "Back" pogu un vēl dažas citas). Taču ja AJAX izmanto tikai kā papildus alternatīvu iespēju esošai iespējai, nevis esošās iespējas vietā (lai iespēja nezustu ja javascript ir atslēgts), tad daudzas lietojamības problēmas tiek atrisinātas un lietojamība tikai palielinās, jo AJAX risinājumi strādā ātrāk par tradicionālajiem, klasiskajiem risinājumiem.
Nobeigumā
Protams, ka ir arī citas metodes, kā tiek paātrināts mājaslapas ielādes ātrums, šeit tika apskatītas tikai dažas vienkāršākas. Beigās padalīšos ar noderīgu saiti uz kādu pakalpojumu, kurš gan, manuprāt, nepretendē uz pašu korektāko informāciju, bet tomēr dod kādu priekšstatu dažiem aspektiem, kā varētu censties uzlabot norādītās lapas ielādes ātrumu - Web Page Analyzer.
Par web.hc.lv
web.hc.lv ir vortāls, kurā tiek aplūkoti mājaslapu veidošanas un mārketinga aspekti, no idejas līdz gandarījumam.
Reklāma