A Google jQuery által tárolt könyvtár – jó?

A külső CDN használatának két fő előnye van mint például a Google a jQuery üzemeltetésére:

1. Ez gyorsabb. Minden bizonnyal gyorsabb legyen, mint a webhelye, és valószínűleg gyorsabb, mint bármelyik saját maga által beállított CDN.
2. Lehet, hogy máris gyorsítótárba kerül . Sok webhely hivatkozik a jQuery-re a Google CDN-jén is, tehát ha az Ön webhelye előtt meglátogattak egy másik webhelyet, akkor nem is kell letölteni.

Potenciális árnyoldalak:

1. A domain blokkolható lehet (ez elég gyakori olyan helyeken, mint Kína ). Megoldhatja ezt egy helyi tartalékkal ( lásd lásd, hogyan ).
2. A verziószámok töredezettsége meglehetősen magas, tehát Lehet, hogy a webhelye látogatóinak sok különböző változata van gyorsítótárban, de nem az Ön által hivatkozott verzióval ( itt talál néhány friss statisztikát ). Ez azonban csak az első oldal betöltésével kapcsolatos kérdés.

Megjegyzések

• Tudna-e közzétenni egy hivatkozást a helyi tartalék?
• Amint arra a Zistolen korábban rámutatott, egy másik előny, hogy a webhelyeivel párhuzamosan más eszközöket is letölt. Érdemes ezt hozzáadni ehhez az egyébként nagyszerű válaszhoz is.
• Ez ‘ kissé félrevezető. A böngészők párhuzamosan töltik le az eszközöket, függetlenül attól, hogy hol vannak tárolva, de van egy korlátozás azoknak a dolgoknak a számára, amelyeket ‘ egyszerre ugyanarról a gazdagépről letöltenek.
• Kihagytam, hogy őszintén szólva ‘ s sem itt, sem ott – a fájl párhuzamosan letölthető, de ‘ emellett további DNS-keresés. Ráadásul bármelyik időbeli különbség amúgy is elhanyagolható.
• Elég tisztességes. De gyors kapcsolatok esetén nem eredményezhet-e ennél gyorsabb teljes betöltési időt, mivel a ” cső több ” felhasználható?

További hátrány:

A CDN használata lehetővé teszi a CDN operátorának, hogy nyomon kövesse az oldalak látogatói. Ezért nem kerülnek pénzbe.

Megjegyzések

• A követés biztos, de a látogatók nem: mindkét jquery ‘ a saját és a google ‘ s jquery CDN olyan domaineken található, amelyek nem ‘ nem állítanak be vagy használnak sütiket (ez valószínűleg teljesítményoptimalizálás is), és ‘ nincsenek igazán azonosítható információk a kérésben. A CDN szolgáltató képet kaphat az IP-címekről, valamint a felhasználói ügynökök húrjairól és a hivatkozókról szóló statisztikákról. Ez valószínűleg értékes, de ‘ önmagában nem jelent óriási adatvédelmi kockázatot (ha ezek a nyilvántartások összefüggésben lennének egy másik adatbázissal – mondjuk, hasonló időpontban kiszolgált személyre szabott hirdetésekkel), akkor talán a követés eszköze).
• Úgy gondolom, hogy magától értetődőnek tekinthető (a google esetében), hogy az adatok összefüggésben vannak más adatbázisokkal, mivel szinte mindenki állandóan a google-t használja keresésre. Ugyanez a helyzet a google betűtípusokkal: Nemrégiben megpróbáltam a betűkészleteket saját szerveren tárolni egy szerveren, de kiderült, hogy ezt nagyon nehéz megtenni. A Google nem tiltja (nyílt forráskódú), de nem ‘ nem biztosítják Önnek a fájlokat használatra kész formában: Vagy maga fordíthatja le őket (de van no makefile), vagy hamisíthat kéréseket a kiszolgálókhoz, amelyeket a normál kézbesítésükhöz használnak. Mindkettő nem kivitelezhető nem technikus számára.
• Talán. Nincs ‘ semmilyen bennfentes információm, ezért ‘ ezt nehéz biztosan megmondani. Én ‘ biztos vagyok benne, hogy ‘ biztosan hibás leszek, és jelentős hiányosságok vannak bennem: Az internetet használó legtöbb helyen azonban NAT van, és több jó néhány hasonló géppel rendelkező felhasználó (valószínűleg azonos UA húrok) – lehetetlen ‘ tudni, hogy melyik kérés kiktől származik. És persze mi van az adsense és a közösségi megosztás gombjaival, azoknak szinte mindig megbízhatóbb eszközeik vannak, ezért el tudom képzelni, hogy nem zavarják őket. Ami a betűtípusokat illeti – én ‘ ezeket többször is letöltöttem, ezért nem értem ‘, hogy értem, hogy ez nehéz?
• Hogy egyértelmű legyek: Én ‘ feltételezem, hogy az Ön által elvégzett webhelylátogatások többségét a nagy statisztikai gyűjtők nyomon követhetik és fogják követni. közösségi megosztási gombok (meglehetősen terjedő) és hirdetések, amelyek szinte mindenhol megtalálhatók. Ezért csak kíváncsi vagyok, hogy az erősen gyorsítótárazott js kérésekből származó, esetlegesen megtévesztő információk mennyire értékesek – nem nagyon fogadok, ezért feltételezem, hogy nem ‘ ne törődjön azzal, hogy megpróbálja személyesen azonosítani az embereket a CDN által szolgáltatott JS használatával.
• Ez nem olyan gyorsítótárazott, mint gondolnánk – Ha betűtípusokat ágyaz be a Google által előnyben részesített módon, CSS hivatkozást helyezve be a fonts.googleapis oldalra. com, minden egyes oldalnézet megnyitja a kapcsolatot a google-val (a Firebug-ban láthatja őket). A ‘ nem számít, ha gyorsítótárazott vagy sem. A letöltést illetően: Tudna rámutatni egy olyan helyre, ahol letölthetem a betűtípusokat kiváló minőségű eot, woff, ttf és svg formátumban (ugyanazokat a verziókat nyújtja a Google, nem tartalmaz külső átalakítókat)?

A CDN (ek) használata a függőségek feloszlásához sok szerveren, így ez lényegében kompromisszumot jelent a sávszélesség és a késés között, feltéve, hogy csak Ön érdekli a teljesítményről.

Mellesleg azt feltételezem, hogy az alternatíva nem egyszerűen lokális tárhely, hanem egy másik helyi kérés összefűzése – általában nincs jó ok arra, hogy ne összefűzzünk, amikor csak lehet.

Ha a sávszélesség végtelen, akkor az a legjobb, ha NEM szilánkosít, mert akkor lesz olyan lassú, mint a leglassabb szolgáltatása – mivel a késleltetés nem tökéletesen kiszámítható, elegendő szolgáltatás mellett, még akkor is, ha gyorsak, akkor csak egy kis balszerencsére van szükség az oldal lassú betöltéséhez.

Ha a várakozási idő 0, akkor a terhelés elosztása sok kiszolgálón javíthatja a sávszélességet sok kiszolgálás felhasználásával. rs (ez nem olyan hasznos, mivel valószínűleg a sávszélesség-korlátozások az ügyfelek, nem pedig a szerverek közelében vannak), de ami még fontosabb, kissé csökkentheti a továbbított adatok mennyiségét a gyorsítótár gyorsításának hatékonyságának növelésével.

Ez attól függ, hogy a forgatókönyved, de általában azt várnám, hogy a késleltetés inkább kérdés, mint sávszélesség, hacsak a szkriptjeid őrületesen hatalmasak (ami nem a jquery). Ekkor általában gyorsabb a jquery tárolása egy összefűzött helyi fájl részeként.

Azok az okok, amelyek miatt nem helyben kell hostolni, például, ha fizet a sávszélességért, vagy ha valami lassú szerveren tárol ( az ügyféllel való kapcsolata szűk keresztmetszetet jelent az Ön oldalán, és nem az ügyfélé, vagy tudja, hogy az ügyfeleknek valóban alacsony a sávszélességük (mondjuk alacsony szintű DSL vagy modemek – a mobil általában több késleltetési problémát okoz, mint a sávszélesség) , vagy az ügyfelek fizetnek a sávszélességért (pl. mobil), és a szkriptek annyira észrevehető részei, hogy a kisebb gyorsítótár gyorsaságot nyer (nem valószínű).

Mindenesetre: sokkal relevánsabb az, hogy Ön ” először az alapokat ismertettük; megfelelő gyorsítótár-fejlécek, összefűzés, minifikálás és gzipelés (előnyösen magas tömörítési aránnyal). És itt van a lényeg: ha NEM T csinálod ezt, akkor legalább a CDN megteszi, így az nyer …

TL; DR: Ha összefűzés + minifikáció + gzippelés + gyorsítótár tárolja az összes lefedettséget, akkor a kis szkriptek helyi kiszolgálása gyorsabb, mint egy CDN-ről a CDN jobb teljesítménye ellenére – de csak akkor, ha elkészítette házi feladatait, esetleg nem az első az oldal betöltése, és mindenképpen vannak kivételek ez alól a szabály alól.

Megjegyzések

• Egyébként van néhány bájtforgács, amelyek csak egy kérés használatával nyertek: önmagában a fejlécek csaknem 1 kt-ot tesznek ki, ami 28 kt hasznos teher esetén nem ‘ semmi. A gzip több kontextus esetén jobban működik, ami további 0,5 kt-t takarít meg. A TCP, DNS, HTTPS általános költségek mind könnyen hozzáadhat egy KB-t ide vagy oda, és ami még rosszabb, az RTT ‘ s. Ez ‘ s miért ilyen kis fájlok esetén a CDN egy nem úgy gyorsan, mint gondolná.

A Google által a jQuery által tárolt könyvtár használata lehetővé teszi az oldalának, hogy gyorsabban töltődik be. Valójában a könyvtár az oldaladdal egy időben töltődik be, nem pedig utána.

Megjegyzések

• De hogyan befolyásolja az oldal betöltését?
• A helyi könyvtárak az oldal betöltésekor is betöltődnek – Az eszköz letöltése mindkét esetben akkor kezdődik, amikor a (modern) böngésző meglátja a letöltést kiváltó kódrészletet, ami általában a teljes dokumentum letöltése előtt történik. . Például lásd ezt a Firebug képernyőképet