Inną istotną różnicą jest sposób obsługi procesu HTTP w odniesieniu do seryjnego odbioru. Zlecenie pobrania przychodzące z przeglądarki wyzwala pomiędzy przeglądarką a serwerem cały szereg rund wymiany danych. Dzieje się tak dlatego, że każda strona webowa składa się z wielu obiektów - za każdym razem, kiedy użytkownik zleca sprowadzenie strony z Weba, dla każdego obiektu na stronie jest ustanawiana sesja TCP, a po niej następuje zlecenie get HTTP. Protokół HTTP 1.1 ma ulepszony system uzyskiwania obiektów przez zastosowanie pewnej formy techniki pipeline, przekazującej obiekty w grupach. Jednak trzeba mieć na uwadze fakt, że w przeważającej liczbie ośrodków webowych nadal jest używany protokół HTTP 1.0.

Dostęp do buforowanych stron webowych zmniejsza czas reakcji i jest jedną z korzyści zastosowania tej techniki. Jednak produkty stosujące tę technikę musza też zadbać o aktualność (świeżość) buforowanych danych. Część elementów na stronie webowej może szybko tracić aktualność (na przykład notowania giełdowe). Jest to powód, dla którego motor buforujący musi kontaktować się z oryginalnym serwerem w celu określenia, czy poszczególne obiekty strony webowej nie uległy zmianie od czasu ostatniego pobrania do bufora. Problemem jest tu jednak pewne opóźnienie, wprowadzane przez zlecenia kontroli świeżości - wielkość takiego opóźnienia zależy od czynników środowiskowych, takich jak aktualne warunki panujące w Internecie lub obciążenia serwera docelowego.

Twórcy urządzeń buforujących nie zdołali, jak na razie, przekonać projektantów ośrodków webowych do wprowadzenia czegoś, co jest znane pod pojęciem explicit expiration, a mogłoby efektywnie rozwiązać problem opóźnień buforowania. Technika ta wymaga od projektanta oznakowywania elementów Weba datą ważności.

Kształtowanie ruchu i buforowanie pomagają w uzyskaniu lepszej kontroli nad dostępnym pasmem i w redukcji opóźnień, jednak nie mniej ważną rzeczą jest także zapewnienie odpowiedniego poziom dyspozycyjności serwera webowego. Jest to problem, do rozwiązania którego stosuje się techniki rozkładania obciążeń. Popularność ośrodka webowego może zostać zdeprecjonowana możliwościami przetwarzania pojedynczego serwera webowego. Rozkładanie obciążeń rozdziela ruch pomiędzy serwery webowe zawierające identyczną lub pokrywającą się zawartość. Podejście to redukuje lub eliminuje przeciążenia serwera - najczęstszy powód kiepskich czasów reakcji ośrodka webowego.

Rozdzielacze obciążeń, w swojej najprostszej formie, są regulatorami ruchu HTTP, FTP i innych, kierowanych do serwera webowego. Rozdzielacze obciążeń przechwytują ruch webowy, zanim osiągnie on właściwe serwery webowe, i określają, który serwer w puli jest najlepiej przystosowany do zapewnienia optymalnej wydajności i najszybszego czasu reakcji na zlecenie użytkownika.

Rozdzielacze obciążeń śledzą też serwery webowe w celu określenia, które z nich są najmniej obciążone, aby przydzielić im obsługę nadchodzących transakcji. Mogą się tu opierać na relatywnie prostych pomiarach czasu reakcji metodą komendy ping lub pomiarach czasu uzyskania z serwera odpowiedzi na zlecenia przekazywane za pośrednictwem sesji Telnet lub HTTP.

Ujemną stroną rozdzielaczy obciążeń stosujących protokół PING do sprawdzania stanu serwerów jest to, że obsługa HTTP na serwerze może być zawieszona, podczas gdy sieciowe połączenie serwerowe może być nadal aktywne i odpowiadać na ping. Prowadzi to do sytuacji, w której rozdzielacz obciążeń jest "przekonany", iż serwer może obsługiwać zlecenia HTTP.

Bardzo efektywnym rozwiązaniem jest zainstalowanie na serwerze agenta gromadzącego statystyki i przesyłającego je do rozdzielaczy obciążeń. Agent zapewnia bardziej szczegółowe informacje niż ta, która może być uzyskana z prostych zleceń ping. Trzeba jednak pamiętać, że agent pracujący na serwerze konsumuje cenny czas CPU.

Każdy algorytm zarządzający ruchem webowym musi uwzględniać konieczność wykrywania uszkodzonych serwerów. Jednak pojęcie "serwer niedostępny" jest dość względne. Jeżeli identyfikacja "martwego" serwera nie nastręcza trudności, to problemem jest wykrycie serwera, na którym stos TCP/IP jest czynny, ale załamało się oprogramowanie serwera webowego.

Regulatory ruchu, motory buforujące i rozdzielacze obciążeń mogą samodzielnie zapewnić wydatne skrócenie czasu odpowiedzi ośrodka webowego. Jednak istotna poprawa wydajności zależy często od zastosowania wszystkich tego rodzaju urządzeń w jednym wdrożeniu.

I tak na przykład motor buforujący, umiejscowiony przed rozdzielaczem obciążeń, może zredukować liczbę zleceń trafiających bezpośrednio do serwerów, buforując najczęściej używane strony lub elementy stron webowych. Również stosowanie regulatorów ruchu pakietów może zapewnić ruchowi o znaczeniu strategicznym zawsze "otwarte drzwi", a rozdzielacz obciążeń może przejąć taki ruch i skierować go do serwera najlepiej przystosowanego do obsługi takich zleceń. Motory buforujące umiejscowione bezpośrednio za rozdzielaczami obciążeń pozwolą z kolei na rozładowanie powtarzalnych zleceń ściągania stron z serwera, uwalniając go dla innych zleceń, np. zamówień i innych bardzo ważnych transakcji.

W najbliższej perspektywie można oczekiwać produktów oferujących zintegrowane usługi przyspieszenia ruchu. Funkcje buforowania i kształtowania ruchu zostaną wbudowane do przełączników sieciowych, a dostawcy rozdzielaczy obciążeń z kolei będą oferować kształtowanie ruchu oparte na regułach i możliwości kontroli ruchu nadbudowanych nad innymi mechanizmami.