Hogyan lehet felgyorsítani a rakodási hely 35 javaslatai rész # 1

A listát a 35 technikák, kombinált 7 csoporttal helyettesített. Eredeti cikk - «Best Practices, amelyek felgyorsítják a Web Site».

1. HTTP-kérések minimalizálása

80% válaszidő a végfelhasználó töltött a külső felület (front-end). A legtöbb ezúttal kapcsolódik a betöltés minden eleme egy internetes oldalon. Képek, stíluslapok, scriptek, Flash, stb Ezek közül a kisebbik alkatrészek, annál kisebb a HTTP-kérések létrehozásához szükséges az oldalt. Ez a kulcs létrehozása gyorsan oldalakon.

Az egyik lehetőség, hogy csökkentsék az alkatrészek számát egy internetes oldalon -, hogy egyszerűsítse a design. De lehetséges, hogy a létrehozott oldalakat, változatos és gazdag tartalom, és ugyanabban az időben egy kis válaszidő? Íme néhány módszer, hogy csökkentsék a számát HTTP-kérések, mentse el az oldalt design.

A fájlok összevonásával, akkor számának csökkentése HTTP-kérések egyesítésével szkripteket egytől egyig stíluslapok - egy stíluslap. Fájlösszefűzési egyre nagyobb kihívássá válik, ha a szkriptek és stíluslapok változnak oldalról oldalra, de tartalmazza azt a kiadás, akkor javulni fog a válaszidő.

CSS-sprite előnyös, hogy csökkentse a képek számát. Keverjük össze a háttérképeket az egyik, és a CSS tulajdonságokat, mint a háttér-kép és a háttér-helyzetben, hogy megjelenjen a kívánt területet.

Képtérképekkel egyesítsen kép egy. A teljes mérete közel azonos, de gyorsabb oldalak betöltése miatt kisebb számú HTTP-kéréseket. Képtérképek csak abban az esetben, ha a kapcsolódó képeket, például a navigációs sáv. Koordinátáinak meghatározására a kártya igényel sok időt és figyelmet. Navigációs térkép képek, kényelmetlen és ezért nem javasolt.

Kezdje számának csökkentése HTTP-kérések az oldalon. Ez egy nagyon fontos ajánlást, hogy javítsa az oldal teljesítményét új látogatók. Amint az a blog Tenni Theurer böngésző gyorsítótár használat - Exposed. 40-60% -a napi látogatók a honlapon jön egy üres cache. Gyors betöltés oldalát az első látogatás javítja a felhasználói élményt a webhelyen.

A rendszernek van egy főállású funkcióját ötvözi és a tömörítés CSS- és JS-fájlt, amely tartalmazza a fő modul beállításait. Ha ez az opció engedélyezve van az ideális eset az oldalon csatlakozik 3 CSS és JS-3 fájlt.

További anyag a témában:

2. Használjon Content Delivery Network (CDN - Content Delivery Network)

A távolság és a felhasználó között a webkiszolgáló befolyásolja a válaszidő. Forgalomba tartalom több szerver különböző helyeken lehetővé teszi a felhasználók feltölteni az oldalakat gyorsabban. De hol kezdjem?

Először is, ne próbálja meg átírni az alkalmazás futtatásához az elosztott architektúra. Az alkalmazástól függően, a változó építészet magában ijesztő feladat, például szinkronizáló művelet állapot és lemásolják adatbázis-tranzakciók több szerver között. Megpróbálja csökkenteni a távolságot a felhasználók és tartalmak elakad, és nem lépik túl ezt a lépést a fejlődés az építészet.

Ne feledje, hogy 80-90% -a válaszidő a végfelhasználó által meghatározott terhelés a oldal elemek, képek, stílusok, scriptek, flash-görgőket. Ez - az aranyszabály a teljesítményt. Jobb, ha nem a statikus tartalom terjesztésére, mint hogy egy kihívást módosítását alkalmazás architektúra. Ez nem csak jelentősen csökkenti a válaszidőt, de ez is könnyebb, köszönhetően a tartalomszolgáltató hálózatok.

Content Delivery Network (CDN) - a csoport webszerverek elosztva különböző helyszíneken annak érdekében, hogy a leghatékonyabb a tartalomszolgáltatás a felhasználók számára. Jellemzően a tartalmat kifejezetten a felhasználó kiválasztja a legközelebbi hálózati szerver, például egy minimális számú áttétel közötti hálózatok vagy minimális válaszidő.

Néhány nagy cégek saját CDN, de a költség-hatékony felhasználását-CDN szolgáltató, például az Akamai Technologies, EdgeCast vagy 3. szint. Induló és magán weboldalak, talán nem engedheti meg magának, hogy CDN-szolgáltatás, de a növekedés a célközönséget, és az átállás a globális szinten CDN válik szükségessé. A Yahoo! Szolgáltatás előzményeinek statikus tartalmat webszerverek CDN alkalmazások (például a harmadik fél és a belső CDN-szolgáltatás Yahoo), jobb válaszidő a végfelhasználók számára 20% -kal vagy annál nagyobb. Napfény CDN - viszonylag könnyen változtatni a kódot, ami jelentősen javítja a betöltési időt az Ön honlapján.

„1C-Bitrix Site Manager” - az első orosz CMS, integrálódott a CDN hálózat szintjén a platform! Bármely webhely tulajdonosa jelentősen felgyorsítja a projekt szó szerint „egy kattintással”, anélkül, hogy további beállításokat!

Csatlakozás: Az adminisztrációs panel a honlapon a „Beállítások” fejezetet - „cloud szolgáltatások Bitrix” - „Gyorsítás hely (CDN)» Tick »Enable gyorsulás Site« és a módosítások mentéséhez.

3. Adjuk elévülési fejléc és a Cache-Control

Ez általában magában foglalja a két szempontból:

• Statikus elemek: állítsa be a politika «soha nem járnak» az elévülési fejléc
• Dinamikus elemek: használjon megfelelő Cache-Control fejléc feltételes lekérdezés böngészőt.

Webdesign egyre gazdagabb, ami azt jelenti, egyre több és több scriptek, stílusok, képek, és a Flash-hengerek az oldalon. Új látogató kell végezni néhány HTTP-kéréseket, hanem segítségével elévülési fejléc a cache ezeket. Ezzel elkerülhető a felesleges HTTP-kérések további oldal találatot. Lejár fejlécek gyakran képekkel, de fel kell használni az összes elemeihez, például szkriptek, stílusok és a Flash-henger.

Ha a szerver fut Apache használja ExpiresDefault irányelv gyorsíthatóságát időszak vonatkozásában az aktuális dátumot. Ez a példa ExpiresDefault irányelv létrehozza eltarthatósága 10 évig az aktuális dátumot.

Tartsuk szem előtt, hogy ha az elévülési fejléc, meg kell változtatni a nevét, az összetevőt a változó tartalmát. A Yahoo! Ez része a fordítási folyamat: a verziószám tartalmazza az összetevő neve, például yahoo_2.0.6.js.

4. A GZip tömörítés

Átviteli idő HTTP-kérés és válasz lehet használatával jelentősen csökkenthető a front-end megoldásokat. Természetesen a felhasználó kapcsolat sávszélessége, a szolgáltató hálózati hely, stb nem függenek a fejlesztők. De vannak más paraméterek, amelyek befolyásolják a válaszidő. A tömörítés csökkenti reakcióidőt csökkenti a méret a HTTP-válasz.

Kezdve HTTP / 1.1, webes kliensek támogatja a tömörítést elfogadás Encoding fejléc a HTTP-kérést.

Ha a webkiszolgáló észlel lekérdezés header, akkor tömöríteni a HTTP-válasz komponensek segítségével az egyik felsorolt ​​módszerek az ügyfél. A web szerver értesíti az ügyfelet, hogy a Content-Encoding fejléc a HTTP- válasz.

Gzip-tömörítés csökkenti a méret a válasz mintegy 70%. Körülbelül 90% -a internetes forgalom (napján az írás) keresztül továbbítják a böngészők, amelyek azt állítják, hogy támogassa gzip. Ha az Apache, a modul határozza meg a tömörítési beállítások, a kiviteltől függően: Apache 1.3 használ mod_gzip-et. és Apache 2.x - mod_deflate.

Néhány ismert problémákat böngészők és proxy okozhat között eltérés, amit a böngésző fogja kapni, és fogadni tömörített tartalmat. Szerencsére ezek a problémák csökkennek, amennyiben frissítés böngészők. Apache modulok automatikusan hozzáadja a megfelelő válasz fejlécet Vary.

Web szerver határozza meg, hogy a borogatás, amely a fájl típusától, de általában meglehetősen korlátozottak a választás. A legtöbb oldalak tömörített HTML-dokumentumokat. Szintén érdemes tömöríteni szkriptek és stílusok, de sok helyen kihagyni ezt a lehetőséget. Elvileg van értelme tömöríteni bármilyen szöveges választ, beleértve az XML és JSON. Kép és PDF- nem szükséges tömöríteni a fájlokat, mivel azok már tömörített. Alkalmazás gzip, hogy ne csak feleslegesen növeli a terhelést a processzor, hanem növelheti a fájl méretét.

A lehető legszélesebb körű alkalmazására kompressziós különböző típusú fájlok - egy egyszerű módja annak, hogy csökkentsék az oldal méretét és javítja a felhasználói élményt.

5. Positioning stíluslapok elején a dokumentum

A vizsgálat során a teljesítmény Yahoo! azt találtuk, hogy ennek eredményeként az átadása stíluslapok a HEAD részben az oldalon oldalon úgy tűnik, gyorsabb. Ennek az az oka, hogy a helyét a stílus a HEAD részében egy oldal megjelenítésekor fokozatosan.

Front-end fejlesztők, akik érdeklődnek a nagy teljesítményű, inkább fokozatos terhelése az oldal, hogy van, azt akarjuk, hogy a böngésző megjeleníti a meglévő tartalmat, amint megkapja. Ez különösen fontos a nagy terhelésű oldalak és a felhasználók lassú kapcsolatok. Vannak tanulmányok és dokumentumok, amelyek bizonyítják, hogy fontos a visszacsatolás a felhasználó például terhelési mutatók. Esetünkben a HTML-oldal betöltése mutató! Ha progresszív betöltés sapkák, a navigációs sáv, a logó a fejlécben, mind ezek a komponensek végre egy visszacsatolási funkció a felhasználó számára, várva oldal betöltődik. Ez növeli a felhasználói élményt.

A probléma a helyét stílusok alján a dokumentum, hogy gátolja a fokozatos terhelés sok böngészők, beleértve az Internet Explorer. Ezek a böngészők blokkolják rendering, hogy ne kelljen újrarajzolni elemek változása esetén a stílusok. Ennek eredményeként a felhasználó lát egy üres, fehér oldal.

A HTML specifikáció egyértelműen hangsúlyozza, hogy a stíluslapot kell a HEAD rész: „Ezzel szemben az az elem A, LINK elem csak akkor lehet a HEAD részben, de megjelenhetnek tetszőleges számú alkalommal.” Egyik alternatíva, egy üres fehér képernyő vagy patak Unstyled tartalmat, a kockázat nem éri meg. A legjobb megoldás -, hogy kövesse a HTML specifikáció és a terhelés stílusok a HEAD részben.

Ahhoz, hogy tovább gyorsítsák fel a letöltési oldalon egyesült CSS-fájlt, akkor lefelé az oldalt, a zárás előtt (JS csatlakozni). Ezzel a megközelítéssel fog megjelenni az oldal „összeesett”, hogy töltse le és CSS feldolgozás. Ahhoz, hogy a felhasználó már látta a helyszínen „kész” oldalon használja a preloader, mint például a - jpreloader.

Egy másik lehetőség, a CSS-animált preloader. Egy példa az ilyen megvalósítás látható TestSertifiko oldalon.

6. Positioning script végén a dokumentum

A probléma a script, hogy blokkolják a párhuzamos letöltéseket. Specifikáció HTTP / 1.1 azt ajánlja, hogy a böngésző betölti párhuzamosan két komponens egy fogadó. Ha tárolni képeket a különböző gépek, akkor még több mint két párhuzamos letöltést. Azonban betöltése közben a script böngésző nem fogadja el más letöltések, akkor is más házigazdák.

Bizonyos helyzetekben ez nem könnyű mozgatni szkriptek le. Ha például a forgatókönyvet használ document.write módszer oldal létrehozása a tartalom, akkor nem lehet mozgatni lefelé. Ott is lehet probléma a korlátozott lehetőségek. Sok esetben ezek a helyzetek elkerülhetők.

Alternatív - kezelhető halasztott szkriptek elhalasztja tulajdonság, amely azt jelzi, hogy a szkript nem használja a document.write eljárást, és a böngésző továbbra is renderelés. Sajnos, a Firefox nem támogatja az DEFER attribútumot. Az Internet Explorer scriptek lehet halasztani. Ha a szkript lehet halasztani, akkor is lefelé az oldalt, ami lehetővé teszi, hogy gyorsabban töltődnek be.

7. Ne CSS kifejezések

CSS kifejezések - nagy teljesítményű (és veszélyes) olyan dinamikus munkát CSS tulajdonságait. Őket támogatja az Internet Explorer 5-ös verzió, de elavult kezdődő IE8. Például a háttér színét lehet változtatni óránként a CSS kifejezések:

A probléma a kifejezést, hogy ők értékelik gyakrabban, mint sok fejlesztő várható. Ezek hatását nem csupán a kijelzőn, és változtatni az oldal méretét, de idővel a görgetés és az egér mozgását. Ha felvesz egy számlálót a CSS kifejezést, hogy látható, hogy mikor és milyen gyakran a kifejezés értéke. A mozgás az egér az oldalon lehet létrehozni több mint 10.000 Central.

Az egyik módja annak, hogy csökkentsék a több közép kifejezést CSS - egyszer használatos kifejezés, amely az első számítási kifejezést beállítani konkrét értéket tulajdon helyett kifejezése CSS. Ha az ingatlan kell felülbírálni dinamikusan működése közben az oldalt, akkor a eseménykezelőkkel helyett CSS kifejezéseket. Ha mindegy, meg kell használni a CSS kifejezések, ne feledje, hogy újratervezi ezerszer, és ez befolyásolhatja a teljesítményét az oldalt.

11. Kerülje átirányítások

Átirányítása végezzük kódok 301 és 302. A következő példa a HTTP-fejléc a választ 301:

A legfontosabb dolog, hogy emlékezzen, hogy átirányítás lassítja a helyszíni munka a felhasználó számára. Átirányítás a felhasználó és a HTML-dokumentum tartalmazza oldalleképezés mert a lap nem jelenik meg, és nem indul el betöltés alkatrészek, amíg nem kap a HTML dokumentumnak.

12. Vegye ismétlődő szkriptek

Felesleges HTTP-kérések történni az Internet Explorer, de nem a Firefox. Az Internet Explorer, ha egy külső script tartalma kétszer, és nem cache-be, hogy létrehozott két HTTP-kérést az oldal betöltésekor. Még ha a szkript cache, extra HTTP-kérelem történik, ha újraindítja az oldalt.

Az egyik módja annak, hogy elkerüljék a párhuzamos szkriptek - scriptek végrehajtása irányítási template rendszer. Egy tipikus módja az egy script - használja a script tag a HTML-oldalon:

Ehelyett PHP adhat insertScript funkciót.

Amellett, hogy a tilalom a párhuzamos a forgatókönyvet, ez a funkció képes kezelni az egyéb kérdéseket szkriptek, például a függőség ellenőrzésével és hozzá verziószámot a script fájl nevét a jövőben támogassa elévülési fejlécben.

13. Állítsa be a ETag

Entity Címkék (ETag) - mechanizmus által használt böngészők és szerverek annak meghatározására, hogy az alkatrész a böngésző cache komponens a forrás szerver. (A „lényeg” - egy másik kifejezés a komponensek: képek, scriptek, és egyéb stílusok.) ETag adunk a rugalmas végző szervezetek, mint az utolsó módosítás dátuma. ETag - egy karakterláncot, amely azonosítja a komponens verziója. Az egyetlen megkötés formátumban - a következtetést a string idézőjelek közé. A forrás szerver megállapítja ETag alkatrész keresztül ETag válaszul fejlécében.

Később, ha a szükség, hogy ellenőrizze a böngésző komponens használt fejléc Ha-None-Match ETag továbbítására vissza az eredeti szerver. Ha ETag mérkőzés, a kód 304 vissza ebben a példában, hogy csökkenti a választ, hogy 12195 bájt.

A probléma a ETag is, hogy azokat általában létre attribútumokat függ egy adott kiszolgáló, amely a helyszínen. ETag nem egyezik, ha a böngésző lesz az összetevő egy szerver és megpróbálja szinkronizálni egy másik szerverre, ami egy meglehetősen gyakori helyzet oldalak használatával szerverfürtöt kérések kezeléséről. Alapértelmezésben és az Apache és az IIS tartalmazza a ETag adatokat, ami csökkenti annak a valószínűségét halad a megbékélés webhelyeken több szerverrel.

ETag formátum Apache 1.3 és 2.x - inode-size-időbélyeg. Bár a kép lehet ugyanabban a könyvtárban több szerver között, az azonos méretű, a felbontás időbélyeg, és mások. Inode jellemzőtípusának függ az adott szerveren.

Az IIS 5.0 és 6.0 is ugyanaz a probléma a ETag. ETag méret IIS - Filetimestamp: ChangeNumber. Képesség ChangeNumber - számláló, amely nyomon követi az IIS konfigurációs változásokat. Nem valószínű, hogy ChangeNumber ugyanaz lesz minden Site Web szerver.

Ennek eredményeként, a ETag által létrehozott Apache vagy IIS ugyanazon összetevő eltérő lesz a különböző szervereken. Ha a ETag nem egyezik, a felhasználó kap, hanem egy kicsi és gyors válaszát 304 amelyre a ETag és hoztak létre, a szokásos 200 válasz együtt az összes komponens adatokat. Ha a webhely csak egy szerver, ez nem jelent problémát. De ha egy pár, és használja az Apache vagy IIS az alapértelmezett beállításokat a ETag, a felhasználók lassan betölteni az oldalakat, és proxy cache hatékony a tartalmat. Még ha az összetevők vannak jelölve a címsor lejár, még létrehozott egy feltételes GET kérelmet, amikor a felhasználó megnyomja a „Reload” vagy a „Frissítés”.

Kapcsolódó cikkek

• Töltsük be a site segítségével plesk fájlkezelő