Tinklaraščio priežiūra ir optimizavimas
Nuotrauka: Entering Hyperspace. Autorius: Éole.
Tinklaraščio (ar šiaip tinklalapio) priežiūra ir optimizavimas tokia pat slidi tema kaip ir operacinės sistemos pasirinkimas. Nėra vieno teisingo ar geriausio būdo kaip tai atlikti, o kiekvienas vartotojas tai daro (jei išvis daro) savaip. Todėl noriu iškart pasakyti, kad šiame įraše tik pasidalinsiu savo patirtimi, kuri nebūtinai yra teisinga. Jei turite pastabų, komentarų, ar šiaip nesutinkat su mano toliau išdėstytom mintim, prašau parašyti komentaruose ir aš mielai pataisysiu tekstą jei tik to prireiks.
O dabar prie reikalo. Kadangi tinklaraštį rašau jau ne vienus metus, o per tą laiką išbandžiau kelias platformas (Blogger, WordPress, Tumblr), pakeičiau kelis talpinimo paslaugų tiekėjus ir perinstaliavau visą sistemą nuo 0, manau, kad sukaupiau šiek tiek patirties, kuria norėčiau pasidalinti su jumis. Suprantama, kadangi galiausiai apsistojau ties WordPress sistema ir ją geriausiai žinau, didelė dalis patarimų bus pritaikyti būtent šiai sistemai.
Visų pirma tai geram tinklaraščio veikimui reikia pasirinkti teisingą talpinimą. Pradinukams gal ir pakanka visokių tinklapis.net bei hostingas.in, kurie daug nekainuoja, bet jei planuojat rimtai kibti į tinklaraščio rašymą, garantuoju, kad greitai tokio hostingo nepakaks. Taip pat neskubėčiau rinktis talpinimo užsienyje. Taip, dažnai jie pigesni, tačiau krovimosi laikas nuo fizinio serverio atstumo taip pat kenčia. Ir nors atrodytų, kad su šiuolaikiniais interneto greičiais tai nėra didelė problema, ji tikrai egzistuoja — kalbu iš patirties.
Kalbant apie WordPress optimizavimą, reiktų rinktis temą, kuri nėra perkrauta paveiksliukais ir dzinguliukais, nes kiekvienas jų tik pailgins krovimosi laiką. Dzinguliukai — daugumos tinklaraščių „kirvis“, ant kurio ir aš pats ne taip seniai buvau pasimovęs. Visi iš išorės kraunami dalykėliai kaip whos.amung.us, FeedBurner skaitliukas, Twitter paskutiniai pranešimai, ir t.t., tik sulėtina svetainės krovimąsi. Nesakau, kad visko reikia atsikratyti, kaip padariau aš, tačiau kiekvieną jų versta apsvarstyti ir labai rimtai pagalvot ar jo tikrai reikia. Taip pat nebloga idėja JavaScript failus persikelt pas save į serverį ir juos krauti lokaliai.
Srauto taupymo sumetimais nemaža dalis tinklaraščių autorių talpina paveiksliukus išorinėse talpyklose, kurios, kaip parodė tiek mano, tiek vienotokio kolegos patirtis, dažnai pridaro daugiau bėdos nei naudos.
Po Denio pristatymo BarCamp (ne)konferencijoje, paklausiau jo ar jis galėtų patarti kaip optimizuoti WordPress tinklaraščius. Jis man pasiūlė tris įskiepius:
- Script Compressor — suspaudžia JavaScript failus (tik tuos, kurie yra serveryje) ir CSS prieš pateikdamas juos vartotojui (lankytojui);
- WP-Compress-HTML — išima tarpus iš HTML kodo ir galiausiai jūsų tinklaraščio išeities kodas pateikiamas kaip viena ilga eilutė. Kodėl? Todėl, kad 1 simbolis (tarpas) = 1 baitas (ar bitas?);
- WP smush.it — įkeliant paveiksliuką į tinklaraštį, jis automatiškai apdorojamas Smush.it tarnyboje ir iš jo išimama įvairi nereikalinga informacija, kuri nematoma galutiniam vartotojui, bet užima vietą;
WordPress įskiepiais taip pat nereiktų piktnaudžiaut — kiekvienas papildomas įskiepis apkrauna serverį ir pailgina svetainės krovimosi laiką.
Jei norite išgauti maksimalią optimizaciją, galite atlikti kelis pakeitimus savo temoje. Visų pirma perkelkite visus JavaScript kvietimus už </body> žymos. Taip užtikrinsine, kad pirma vartotojui parodomas turinys, o tik tada kraunami dzinguliukai.
Dar kelias šimtąsias sekundės sutaupysite pakeisdami kai kuriuos PHP kodo gabaliukus paprasčiausiu HTML. Pavyzdžiui tinklaraščio RSS adresas keičiasi retai, tad kam palikti adreso nustatymo darbą PHP, jei galima viską įrašyt rankomis. Tas pats galioja ir CSS failo nustatymui, tinklaraščio pavadinimui, bei keliems kitiems PHP kodo gabaliukams, kurie būna temose.
Tiek patarimų iš mano arsenalo. O kokius tinklaraščio (svetainės) optimizacijos triukus naudojate jūs?
P.S. nepatingėkite sudalyvauti apklausoje „Kurių senos temos šoninių skydelių labiausiai pasigendate?“, kurią rasite tinklaraščio dešiniame šone.
Sveiki užsukę į mano tinklaraštį!
Turbut turejai omenyje tinklalapis.net (vietoj tinklapis.net)
:)
Tiesą sakant taip, turėjau galvoje tinklalapis.net, bet kad ir tinklapis.net SMS planai man kiek juokingi atrodo. Kuriam laikui tokio gali pakakt?
Dėkui už nuorodas į pluginus, pirmus du būtinai pamėginsiu. Pats galiu pasiūlyti http://aciddrop.com/php-speedy/ , suspaudžia ir CSS ir javascriptą į du failus, tik, kad kai kurie įskiepiai javascript naudojantis neveikė :D
Pagal aprašymą, tai PHP speedy tą patį ką Script Compressor daro. Būtų įdomu palyginti ir pažiūrėti kuris tai daro geriau.
Uh, nutolęs gerokai nuo viso šito, bet įkišiu savo trigrašį :)
Paveiksliukai ir dzinguliukai didelės įtakos puslapio krovimui neturi. Taip, pirmą kartą kraunantis puslapis krausis šiek tiek ilgiau, bet visos šiuolaikinės interneto naršyklės paveiksliukus kešuoja, todėl kraunamas būna tik puslapio HTML kodas ir paveiksliukai krovimo įtakos neturi – svarbu, kad serveris būtų protingai sukonfigūruotas.
Hostinimas užsienyje nėra jau toks blogas dalykas. Dabar kai namų varotojai turi mažiausiai po 1 MB duomenų priėmimo spartą, puslapio krovimosi laikas nuo to kur serveris yra mažai priklauso. Visi normalūs užsienio provaideriai turi labai gerus interneto srautus.
Jei normalus Twitter įskiepis, svetainės krovimosi laiko neturėtų įtakoti, jeigu yra galimybė kešuoti duomenis pačiame WordPress. Visus WhosAmungUs ir skaitliukus geriausia grūsti į IFRAME tagą, tuomet jie neįtakos puslapio krovimosi laiko.
Apskritai vargti bandyti keisti PHP kodą į statinį HTML tikrai neverta, nes sutaupysit gal 0.0001 s. puslapio krovimo laiko. Geriau įsidiegti viso WordPress kešavimą su wp-supercache ar kažkuo panašiu. Tuomet svetainė vartysis labai greitai ir generuosis iš PHP tik kam nors parašius komentarą ar pačiam parašius įrašą.
O šiaip tai super straipsnis :)
Na ir labai džiugu, kad įkišai savo trigrašį — gerai, kai straipsnį pakomentuoja išmanantis žmogus ir parodo, kur aš neteisus.
O šiaip tai kalbėjau iš savo patirties. Man tai padėjo arba bent pasirodė, kad padėjo.
Sakai dzinguliukai krovimosi nestabdo, bet jei jie yra dinaminiai (twitter, whos.amung.us, feedburner ir t.t.) tai jie nesikešuoja. Aišku tada padėtų tavo iFrame sprendimas.
O dėl PHP kodo rušinimo, tai sakiau, kad porą milisekundžių tik sutaupys :) Bet juk sutaupys, o tai svarbiausia ;)
Tikiu, kad ir su užsieniniu hostingu gyvent galima, blogeriai.lt labai geras to pavyzdys (neskaitant poros minučių nepasiekiamumo kasdien). Tačiau asmeniškai man teko su Dreamhost pagrinde susidurt, o jie, nors ir yra dideli ir žinomi, stabdo tikrai gan stipriai.
Su internetinių svetainių optimizavimu yra keletas labai paprastų taisyklių:
1. Jei galima optimizuoti kodą, optimizuoti kodą (scaling vertically)
2. Jei kodas išoptimizuotas, daryti kešavimą (caching)
3. Jei jau kešavimas nepadeda, reikia statyti papildomus serverius (scaling horizontally)
Galiu atsakingai teigti, kad 95% WordPress paremtų svetainių puikiai sukasi nieko nedarant. 4% puikiai padeda kešavimas, o likusiam 1% tenka naudotis 3 patarimu, bet tai labai labai išimtiniais atvejais, kuomet tai yra ypač populiarūs blogai, bet natūralu, kad ir užsidirba papildomiems serveriams :)
Įtariu, kad tinklaraščiai, kuriems dėl populiarumo reikia statyti papildomus serverius, WordPress nenaudoja :)
Visko gali būti. Matai, kai prieini tokią ribą, kad reikia statyti papildomus serverius, jau nesvarbu kokią sistemą naudoji :)
Su lietuviškais interneto planais, kai lietuvos/užsienio greičių santykis 1:10, 1:100, tai sakyčiau gan normaliai jaučiasi ar Lietuvoj patalpinta ar užsienyje… Ir taip pat už wp-supercache :-)
Hmm, aš to supercache prisibijau, nes paskutinį kartą kai naudojau tai man prigrybavo kažką, tik nepamenu ką :) Bet kai dabar išmečiau visus dzinguliukus lauk, tai nelabai yra ką čia užgrybaut. Reiks išbandyt. Dėkui.
Šiaip manau kad optimizavimas yra viena vertus geras dalykas, kita vertus nelabai. Turėjau reikalų su vienu programuotoju, kuriam buvo labai svarbus puslapio užsikrovimo laikas, jam labai skyrėsi pvz 0.5 sek ir 0.4 sek, ir jis optimizuodavo kol pasiekdavo vos ne geriausią įmanomą rezultatą. Bet tai realiai – kas iš to? Sugaišta daug brangaus laiko, o lankytojai skirtumo beveik nepajaučia. Na aišku, kai puslapis kraunasi ryškiai ilgokai ir tai trukdo naršyti, tai gal ir vertėtų susimąstyti, arba kitas atvejis – kai tinklapio lankytojų skaičius peržengia tam tikrą ribą, pvz kelis tūkstančius per dieną, bet bendrai optimizavimo “liga” mano nuomone yra išpustas burbulas daugeliu atvejų
Pritariu, kad dėl 0.1 sekundės į vieną ar kitą pusę nėra ko plėšytis, bet mano tinklaraštis dar visai neseniai nuo 0 (su išvalytu cache) iki 100% užsikraudavo per 30+ sekundžių, kas yra visiškai nepriimtina.
O šiaip jei optimizacija neeikvoja resursų (išskyrus laiką) tai galima ir pakvailiot optimizuojant iki maksimumo :) Aišku jei mokėt už tai reikia, čia jau kita kalba…
Na ir aš, ne taip jau seniai čia užklydęs, pasisakysiu :)
Optimizavimui pirmiausia naudoju turinio suspaudimą. Kadangi seniau man buvo labai aktualus duomenų srautas, tai šis puslapio, prieš siunčiant naršyklei, supakavimas į gzip formatą leido sumažint beveik 3 kartus. O ir yra pasisakymų, kad nors suspaudimas sunaudoja kažkiek papildomų CPU resursų, bet tai atsiperka, nes mažiau laiko reikia “laikyti” sujungimą su vartojo kompu. Nors, kiek čia tiesos – nežinau.
Tiesa, persikėlus į dabartinį hosting’ą jau srautas kaip ir neaktualus patapo, bet dėl savybes puslapio kelis kart greičiau pasiekti lankytoją – iki šiol tebenaudoju. Gaila, kad pastaruoju metu (ypač šiandien) jau pradedu nusivilti hosting’o pasirkinimu… Greičiausiai jau reiks galvoti jau apie kokį nors VDS, o ne tenkintis esama shared hosting’o situacija… Nors jis man patiko bent jau dėl tikrai gero spam’o filtro. Pakeitus kelis nustatymus, jis daug geriau man sugaudo viską, nei gmail’o.
Toliau – minėtus HTML ir CSS sutraukimo (tarpų panaikinimo) galimybes bandžiau. Iš dalies gerai (nors man tai nelabai trukdo, bet mažiau copy-paste’inančių HTML source:)), bet tai sukelia papildomų problemų. Pvz. textads.lt neveikia; negalima visiškai visur suglaudinti (pvz. forumo redagavimo žinutėje).
CSS mano irgi buvo suspaustas, bet prireikė pakeisti vieną kart smulkmeną, po to kitą kartą. Tai, trečią kartą ir nebesuglaudinau :)
Taip pat naudojau (dabar trumpam nebe) direktyvas (jei taip galima vadint) naršyklei, kad kešuotų kokį CSS, paveikslėlius ne tiek, kiek šiaip susigalvoja, o pvz. “Expired” laiką nurodau po mėnesio. Ir tikrai ilgiau laiko, nei įprastai.
O dėl daugybės paveiksliukų, norėčiau nesutikti su Arvydu. Nes, bent aš, į puslapius, kurie pirmą kartą kraunasi baisiai ilgai, ne taip dažnai ir sugrįžtu (kiek pastebėjau, ne tik aš taip darau). Apie vien Flash’inius, jau nekalbu (nors regis tik ant Linux čia tokios Flash ir apkrauto CPU problemos, bet dėl to windows tikrai nesinaudosiu:))
Ir IFRAME – nors ir labai pagreitina viską (dėl banerių ir skaitliukų – tikrai sutinku), bet tikrai nėra taip, kad pirma užkrauna visą html, o tik po to visas Iframe. Jei neklystu, viena iš šiuolaikinių naršyklių savybių ir yra, kad jos moka iš kart viską po truputi krauti.
Na ir gal užteks mano nuomonės :)
Apie serverio procesų optimizavimą tai man dar anksti kalbėt, pirma su WordPress susidorot reikia :)
O dėl tarpų išėmimo, tai minėti įskiepiai juos išima prieš pateikdami lankytojui (aišku pateikia sukešavę, o ne kaskart tai daro). Man pačiam atsidarius HTML ar CSS failą viskas rodoma su normaliais tarpais.
Dėl HTML nekrovimo, tai galima įdėti specialų komentarą, kuris nurodo kurio kodo nesuspaust. Ten viskas gerai apgalvota. Rimtas įskiepis.
“Apie serverio procesų optimizavimą tai man dar anksti kalbėt”
Nors nesu tikras, bet man regis, kad WordPress irgi viskas eina per vieną index.php failą, tai tam gzip’inimui užtenka tame index.php viršuje visko vos vieną eilutę įsidėt ir nereiks jokių atskirų plugins’ų:
ob_start(“ob_gzhandler”);
Tą patį galima ir su .htaccess padaryti, bet šią minutę nepamenu kaip. Tiesa, nesu tikras, ar nesipyks su kuo nors bet pabandyt tikrai verta :)
o kad CSS (analogiškai ir paveiksliukams) kešuotų mėnesį, .htaccess’e galima ir, pavyzdžiui, taip parašyt:
ExpiresActive On
ExpiresByType text/css “modification plus 1 month”
“O dėl tarpų išėmimo, tai minėti įskiepiai juos išima prieš pateikdami”
Na, kai aš pasirašiau savo TVS, tai man šituo pasinaudoti neišeis :)
Dėkui, reiks pasidomėt kaip su tuo suspaudimu WordPress’e. Jei gerai pamenu, tai ir nustatymuose yra toks pasirinkimas, bet kodėl aš jo nerušinau anksčiau tai pats nežinau.
didelis dėkui už šio įskiepio pavadinimą WP-Compress-HTML :)
Didelis prašomt, jei tai ne reklaminis komentaras :) Nes uzsidirbk.info net nenaudojamas WordPress, tai kam tau to įskiepio reik?
Dėl optimizavimo tai visą reik matuot su tokiais įrankiais kaip Firebug ir YSlow (Yahoo sukurtas), šie įskiepiai sukurti Firefox’ui. Tada per juos realiai matai kas kiek laiko užtrunka ir jokių spėliojimų nereikia.
Dėl greičio tai realiai tarkim šio puslapio (įrašo su komentarais ir t.t.) dabar visas dydis yra 230 KB (aišku jis didės kai prisidės mano komentaras bei kitų komentarai). Tai realiai reiškia, kad jei greitis yra 1 Mbps į užsienį tai viso šito siuntimas užtrunka 1,8 s. Jei svetainė stovi Lietuvoje ir tarkim turima 40 Mbps greitis į Lietuvą tai reiškia, kad siuntimas užtruktų 0.045 s. Be to prisiminkim tai, kad čia tik pirmą kartą tiek laiko trunka. O antrą kartą kraunant tavo puslapio atveju krauna dvigubai mažiau KB, tai reiškia, kad dvigubai mažiau trunka siunčiant failus (nors header’iai ir nesutvarkyti). Aišku čia tas atvejis kai nėra dzinguliukų (nors daug užklausų valgo gravatar ). Tad realiai ar svetainė užsienyje ar Lietuvoje tikrai matosi ir toks optimizavimas yra gerai. Nes kuo mažiau užklausų į failus tuo geriau, nes pačios užklausos nešasi papildomą informaciją – header’ius, po to yra serverio užlaikymas ir t.t., dėl to vėlgi ilgėja laikas. Vėlgi naudojant gzip’ą JS, CSS ir HTML failams galima sutaupyti dar šiek tiek KB – tekstas spaudžiasi maždaug ~ 5-6 kartus. Tavo atveju JS+CSS+HTML užima 90.3 KB tad visa šitai suspaudus gzip’u realiai galima sutaupyti nemažai srauto, kad suspausti gzip’u dažniausiai naudojama Apache mod_deflate arba šiaip su tam tikrais moduliais WordPress’ui, kad išmestų gzip headerį ir gzip’u suspaustus duomenis. Realiai dėl spaudimo vėlgi reikia žiūrėti, nes tai naudoja CPU resursus aišku tai sudaro labai mažą dalį visos svetainės CPU sunaudojamų resursų, bet vis dėl to šiek tiek naudoja ir dėl to vėlgi prisideda šiek tiek milisekundžių. Po to tarkim paveiksliukams kurie laikomi savam serveryje padaroms .htaccess failas su tam tikrais header’iais, kad kiekvieną kartą nesisiųstų failo iš naujo, o imtų iš naršyklės cache – naršyklės laikinosios atminties.
P.S. Pats turiu 40 Mbps Lietuvoje ir į užsienį 2Mbps. Nors 50 % Lietuvos gyventojų turi Zebra (iki 0.5 Lietuvoje / 0.25 užsienyje už 26 Lt/mėn, iki 1 Mbps Lietuvoje / 0,5 Mbps užsienyje už 36 Lt/mėn) O dėl greičio tai tarkim Firebug’as rodo, kad dažniausiai žymiai ilgiau užtrunka užklausa negu pats failo siuntimas. Tad realiai geri .htaccess nustatymai ir turinio cache sistemų naudojimas žymiai padidina sistemos greitį. Kiekvienai užklausai [net ir paveiksliukui] Firefox’as siunčia header’ius su vartotojo cookie (sausainiais), kokia naršyklė, kokia naršyklės versija, kokia OS ir pan., ką naršyklė palaiko, Referer’io adresą ir t.t.) tai vėlgi rodo, kad geriau mažiau užklausų, bet jos didesnės, realiai labai gerai CSS išnaudojimas kada į vieną paveiksliuką sugrūdi daug paveiksliukų, o po to iš to vieno paveiksliuko rodai tik tuos atskirus paveiksliukus.
O dėl iframe tai blogis. Visų pirma jį reik mest iš standarto dėl kylančių saugumo problemų, nuorodų problemų ir t.t. O be to tai ilgiausiai trunkantis objektas kurį naršyklė generuoja jeigu galima taip išsireikšti, aišku tai mažai įtakos turi bendrame vaizde viso puslapio krovimo, bet vis dėl to paminėjau kaip faktą.
Pabaigai noriu pasakyt, kad svarbiausia atkreipti dėmesį į esminius dalykus kurie stabdo, o ne į šalutinius. Vienas iš esminių geri header’iai failams.
Oho koks komentaras! Visas atskiras įrašas…
Tau tikrai reikia blogint pradėt. Rimtai.
Tikrai įdomios info iš tavo komentaro sužinojau. Na, kad ir YSlow pirmą kartą išgirdau.
Be viso to, kad jau aukščiau paminėta komentaruose, reik atkreipt dėmesį, kad puslapiui parodyt laikas sugaištamas ne tik kol failai parsisiunčia į kompą, bet ir kol jie surenderinami ir įvykdomi visokie unobtrusive javascriptai. Šiuo atveju, Firebug Net srityje apačioje rodomas laikas, per kurį blogas buvo pakrautas iš serverio ar vidinio kešo, o YSlow apatiniame kampe rodo galutinį laiką, koks truko atvaizduot puslapiui ir šis galutinis laikas visada būna didesnis už skirtingų failų pasikrovimo laiką. Išvada tokia, kad geriausiai nenaudoti tų įskiepių, kurie valgo daug resursų ir minimizavimas ne visada padės.
Na, mano nurodyti metodai tai čia paviršinis krapštymas. Tai, ką gali dauguma vartotojų.
Džiaugiuos turėdamas skaitytojų, kurie žino kaip lėsti giliau ir nepatingi pasidalint su manim :)
Ir kiek tarpų sutaupei? :D Tavo avataras užima NET 1.6kb, tai ojojoj kiek tarpų į jį tilptų. :D IMO, nesąmonė tokie scriptai, nes jie sutaupo tik bitus. Geriau naudok gzip kompresiją 9 lygio, tavo kodas bus spaudžiamas, siunčiamas ir vartotojo kompe atspaudžiamas. Užkrauna servo CPU, bet šiandien tai juokingos apkrovos, o vat tiek intiko kanalą, tiek krovimo laiką iki 10x gali sumažint. Tikriausiai pastebėjot, kad tekstas ar koks word nesveikai su visais zip spaudžias >10x kartų. :)
dzinguliukus galima dėti, kad ir pas save į puslapį, bet tą puslapį į svetainę dėti su iframe, nes iframe kraunasi nepriklausomai nuo puslapio. Taigi tarkim iframintos reklamos kaip pas mane nei kiek nekeičia puslapio krovimo greičio, jos yra ar ne, nors jos užima vos ne kaip pats puslapis vietos. :)
Na taip, visi čia apie gzip kalba, reikia išsiaiškinti. O dėl tų bitų, tai jei nors ir kelis sutaupau, o rankytėm tarpų išiminėt nereikia, kodėl gi ne.
iframe irgi reiks išbandyt jei sugalvosiu kuriuos nors dzinguliukus gražint. Dėkui už patarimus. Good stuff ‘skant :)
Kadangi kodas kraunas nuosekliai, tai net feedburner skaitliukas footeryje nieko nekeičia, nes jis kraunas paskutinis. Lygiai kaip galima pažaisti su dizainu, kai kodas paskutinis, bet div ir styles persikelia į kažkokią kitą puslapio vietą iš galo.
Taip pat, jei paveikslėlis ar iframe turi dydžio atributus, tai dažniausiai naršyklės jam palieką tą jo plotą, ir iš kart lygiagrečiai toliau kodą krauna. Jei tarkim paveikslėlis neturi dydžio atributų, kodas po juo bus kraunamas tik tada, kai bus užkrautas paveikslėlis ir nustatytas jo dydis, kadangi naršyklė nebežino, kiek vietos užims, ir kur jį dėti.
Kaip ir turinį dėl google rank ir krovimo greičio reiktų rašyti kodo viršuje, o kokius sidebar ir footer užkrauti jau po visko, pačiame gale.
Dėl kodo krovimo nuoseklumo tai žinau ir sutinku 100%, bet vien tai, kad tu sukiši viską į footer, dar negarantuoja sklandaus svetainės užkrovimo.
Ta prasme, kad turinys gali būt užkrautas ir atvaizduotas labai greit, bet tas pats FB skaitliukas viską užlaikyt ir rodys, kad svetainę dar krauna. O iš patirties (bent jau man taip yra) žinau, kad FB dažnai kažkur pastringa.
Problemos kaip ir nėra, nes lankytojas jau mato turinį, bet psichologiškai svetainė atrodo lėtesnė, nes po turinio parodymo vis dar matosi, kad naršyklė kažką veikia.
Aišku čia diskusija be pabaigos, bet pripažinsiu, kad prieš lengva ranka nubraukdamas visus dzinguliukus galėjau pagalvot apie iframe ir gzip bei išbandyt šiuos metodus.
[...] vienintelis greitas būdas išjungti Windows XP. • F5 klavišas – ne vienintelis galimas būdas priversti tinklaraštį krautis sparčiau. • Renginių organizavimas su invite.lt pagalba – paprastas ir efektyvus. • Apsauga nuo SQL [...]
Kalbant apie gzip, tai jeigu patys valdot http serverį (tarkim, VDS, kaip dabar pas Karolį), tai skriptinimo kalbos galima nė neliesti ir įjungti gzip’ą visam tam tikro formato output’ui. Nginx’ui tą padaryt vienas juokas, manau Apache taip pat turėtų turėt tokią galimybę
Reiks pasidomėt / užklaust HOSTEX’o. O kurio formato output’ui čia tą gzip įjungt reiktų?
text/plain, text/html, text/css, application/x-javascript, text/xml, application/xml, application/xml+rss, text/javascript. Self-descriptive :-)
Kapiš =]