Der Browser ist wahrscheinlich näher an CPU-Einschränkungen als Netzwerk-Constraint, oder? Wir haben eine sehr starke Ajax-Anwendung, aus der Perspektive des Brower (nicht der Server) sollte es vielleicht besser sein, keine Komprimierung zu verwenden.Lohnt es sich aus der Sicht eines Browsers, HTTP-Antworten zu komprimieren?
Was denken Sie,
Es hängt ganz von dem Browser und dem Gerät ab. Auf einem normalen Laptop oder Desktop bei nach Hause würde ich erwarten, dass das Netzwerk der begrenzende Faktor ist. In einem gut verbundenen Büro kann es CPU sein, wenn es wirklich einen Engpass überhaupt gibt.
Dann haben Sie, Netbooks, möglicherweise über 3G und dann Mobiltelefone ...
Persönlich würde ich für die Kompression gehen - ich denke, es ist eher ein Gewinn als ein Engpass.
Nun, im Allgemeinen CPU-Zyklen sind ziemlich billig, im Vergleich zu Netzwerkgeschwindigkeit. Und die Dekomprimierung wird nicht zu viele CPU-Zyklen benötigen, es sei denn, Sie versuchen, MB von Daten zu dekomprimieren.
Aber ich denke am Ende kommt es auf die Leute an, die die Website benutzen werden. Wenn Sie sicher sind, dass sie wirklich schnelle Internetverbindungen haben, dann müssen Sie vielleicht keine Komprimierung verwenden. Auf der anderen Seite können Sie immer sicher sein, dass sie ziemlich gute CPUs haben.
Meine Kunden neigen dazu, kleine Büros zu sein, die sich eine Internetverbindung teilen, und die Bandbreite ist ein wichtiger Faktor. Unsere Anwendung bietet ziemlich große Seiten, daher hat die Komprimierung einen großen Unterschied gemacht.
Hängt von Bandbreite, Anzahl der Benutzer, Seitengröße ab.
Komprimierung und Dekomprimierung sind ziemlich optimiert, und Sie können die Komprimierungsstufe steuern.
Der häufigste Grund für nicht Komprimierung ist die CPU-Last, die es auf den Server legt (für dynamische Seiten). Normalerweise ist das das weitaus größere Problem, also nehme ich an, dass die CPU-Last auf einem durchschnittlichen Desktop-PC vernachlässigbar ist (es sei denn, Sie möchten bz2 verwenden).
Wenn die Komprimierung den Server stark belastet und/oder die Komprimierungsrate schlecht ist (z. B. wenn eine 20K-Seite auf 19K komprimiert wird), würde ich erwägen, sie auszuschalten. Sofern Ihre Benutzer keine sehr schnelle Verbindung mit niedriger Latenz zum Server haben, ist der Browser mit ziemlicher Sicherheit netzwerkgebunden.
Ich würde auch HTTP-Caching-Techniken in Betracht ziehen - sie sind ziemlich effizient, noch mehr mit AJAX. Dies spart Bandbreite und CPU-Zyklen sowohl auf der Server- als auch auf der Clientseite - Sie müssen nicht erneut anfordern, neu generieren, erneut übertragen, erneut analysieren und erneut speichern, was Sie bereits haben.
Siehe Yahoo's best practices for making web pages fast. Besonders Gzip Components Fazit:
so viele Dateitypen wie möglich Gzipping ist eine einfache Möglichkeit, Seite um Gewicht zu reduzieren und die Benutzererfahrung zu beschleunigen.
Dekomprimierung ist ein sehr schneller Prozess im Vergleich zur Komprimierung. Selbst eine schwache CPU (wie eine in einem mobilen Gerät) kann GZIP (ZIP, Deflate usw.) in kürzester Zeit effektiv dekomprimieren. Die Komprimierung der Daten ist viel schwieriger.Durch die Verwendung von Komprimierung erhöhen Sie die Serverlast ... und die Erhöhung ist nicht immer vernachlässigbar. Normalerweise ist es ein Kompromiss zwischen der Bandbreitenauslastung und der CPU-Auslastung auf der Serverseite. Für den Client spielt er normalerweise keine große Rolle, es sei denn, der Internetzugang ist sehr langsam (z. B. eine Mobiltelefonverbindung). Allerdings kann nur text/html/css/js effektiv komprimiert werden, die meisten anderen Daten, die Sie auf Webseiten finden (wie zum Beispiel Tonnen von Bildern), können überhaupt nicht komprimiert werden; Wenn wir also über Seiten sprechen, auf denen 8 kb Webseiten-Daten sind und die Seite selbst mehr als 200 kb Bilddaten lädt, dann vergessen Sie die Komprimierung und Sie werden praktisch nichts kaufen.
Alle Skripte oder Inhalte, die der Browser herunterlädt, müssen nur dekomprimiert werden, sobald sie heruntergeladen werden, und von da an ist sie bereits dekomprimiert (die einzige Ausnahme ist, wenn Sie etwas seltsames mit HTTP-Headern wie Cache tun -Kontrolle: no-Store).
Es wird schneller dekomprimieren als es herunterladen kann - der Flaschenhals ist sehr unwahrscheinlich, die Dekompression zu sein.
Selbst ein etwas älterer, träger Computer könnte GZIP wahrscheinlich mit mehr als 50 MB pro Sekunde dekomprimieren, was eine Netzwerkgeschwindigkeit von mindestens 410 Mbit/s (das sind 410.000 Kbit/s) zur Sättigung erfordert.
Ich wäre besorgt über fehlerhafte Browser wie IE6 (Pre-SP2), die nach komprimiertem Inhalt fragen, aber in manchen Situationen nicht damit zurechtkommen, etwa wenn Sie CSS komprimieren.
Es mag nicht sehr relevant für die Frage sein, aber da Sie "eine sehr schwere Ajax-Anwendung" erwähnt haben, beachten Sie bitte, dass IE ein schlechter Performer ist, wenn es um JavaScript geht. Das Laden der Homepage für StackOverflow.com auf IE 7 hängt meinen Browser für ein paar Sekunden. –