A HTTP protokoll működése röviden a következő: miután lekértük a megtekinteni óhajtott weboldal HTML kódját, a böngésző összegyűjti belőle a megjelenítéshez szükséges fájlokat (képeket, stíluslapokat stb.), és, amennyiben szükséges, letölti azokat a szerver(ek)ről. Ha az adott fájlt korábban már lekértük, akkor először azt ellenőrzi le, hogy változott-e a tartalma, ha igen, akkor a szerver újraküldi, ha nem, akkor pedig csak annyit válaszol, hogy nincs változás, használhatjuk a gyorstárban lévő állományt (ilyenkor csak az úgynevezett válasz fejléceket küldi vissza, ami pár sornyi szöveg).
Hiába gyorsul a legtöbb helyen az internetelérés sebessége, a "legdrágább", azaz leglassabb művelet a fent leírt ellenőrzés, mivel minden egyes fájl esetében egyesével kell elküldeni a kérést, és megvárni a választ. Egy átlagos lekérés 50-100 milliszekundumot vesz igénybe (feltételezve, hogy az adott tartalom már a számítógépünkön van), ezt szorozzuk meg a lekérendő állományának számával, és máris több másodperces válaszoknál is tarthatunk. Ahogy a böngészők és a személyi számítógépek fejlődnek, egy átlagos weboldalon is akár ötven-hatvan lekérés is történhet oldalmegnyitáskor, gondoljunk csak a sok képre, reklámokra, programozási keretrendszerekre, statisztikai számlálókra stb.
A modern böngészők ezen a problémán úgy segítenek, hogy egyszerre több adatkapcsolatot indítanak a webszerver(ek) felé, de ennek is vannak korlátai, és egyáltalán nem biztos, hogy a kiszolgáló két kérést kétszer olyan gyorsan tud feldolgozni, mint egyet. Különböző trükkökkel lehet még a sebességet növelni, de igencsak hamar elérhetjük a protokoll korlátait.
A megoldás egészen nyilvánvaló, ha a fentebb leírtakat továbbgondoljuk. Egy kérés minimális ideje - induljunk ki a magasabb számból - 100 milliszekundum, azaz ennyi idő alatt kapcsolódunk a szerverhez, az feldolgozza a kérést, és visszaadja a megfelelő válaszfejléceket. Ha egy megabites kapcsolattal számolunk (egy másodperc alatt kb. 125 kilobájt adat), akkor ennyi idő alatt 12,5 kilobájtot küldhetett volna. Ahánnyal a kérések számát csökkentjük, annyiszor 12,5 kilobájtnyi adatforgalmat és annyiszor 100 milliszekundumot spórolhatunk meg. Ezt a legkönnyebben úgy tehetjük meg, hogy az oldal megjelenítéséhez szükséges fájlokat egy nagy fájlba csomagoljuk, így egyszerre küldünk el annyit, amennyit lehetséges.
Mit nyerünk így? A kevesebb kérés gyorsabb feldolgozást eredményez mind a kliens böngészőjében, mind pedig a szerveren, és tovább javíthatunk a sebességen, ha ezeket a csomagokat tömörítjük. A fenti példánál maradva az ötven fájlt ha öt csomagra tudjuk bontani, fél másodpercet nyerhetünk csak a letöltési időben.
Mivel minden éremnek két oldala van, ez a megoldás új problémákat is felvet: jól át kell gondolnunk, hogy az egyes csomagokba mit pakolunk (érdemes például a képeket külön tenni a szöveges információkat tartalmazó állományoktól), bár erre viszonylag könnyen lehet a webszerverekhez olyan kiegészítést írni, ami automatikusan elkészíti a forgalmi adatok alapján a megfelelő csomagokat.
Steve Souders, az ismert szakértő, aki a weboldalak megjelenítésének gyorsaságával foglalkozik, is ajánlja ezt a megoldást, már létezik is erre kidolgozott technológia, bár még nem igazán támogatott.
Amit jelenleg tehetünk, az az, hogy a fentiekben vázolt megoldást propagáljuk, átgondoljuk, kidolgozzuk. Emellett foglalkozni kell a jelenleg is működő gyorstárazási technológiák bemutatásával, hogy a webmesterek és programozók teljeskörűen megismerhessék a lehetőségeket, és gyakorlati tanácsokat kéne összegyűjteni a témakörben, hogy ne több helyről kelljen ezeket az információkat összegyűjteni.
