outta schrieb:
Solche Testrechner wie meine "Lieblingspczeitschrift"
Computerbild verwendet sind für mich alt:
Weder ist die Kiste wirklich alt, noch würden neuere/schnellere Maschinen ein deutlich anderes Ergebnis zeigen. Die Skalierung dürfte bei allen ähnlich sein.
outta schrieb:
Aber ich würde gerne mit meinem PC mal einen Test irgendwo machen, wieviel schneller FireFox 37 64bit objektiv, bei mir, im Vergleich zu Chrome ist!
Und was hindert dich? SunSpider & Co sind doch kein Firmengeheimnis oder sowas. Du solltest obigen CBild-Artikel auch lesen, nicht nur lästern.
Aber was sagen dir die Benchmark-Ergebnisse am Ende? NADA!
Wenn ein Browser jetzt 100 Punkte mehr bei SunSpider & Co hat, dann heißt dass, dass extrem aufwändiges JavaScript x-tausend Mal durchgeführt wurde und am Ende eine extreme Winzigkeit schneller fertig war.
Mit "realer Geschwindigkeit" hat das alles gar nichts zu tun. Alle Browser, die einen halbwegs gepflegten JIT-Compiler einsetzen, können selbst auf schwächeren Rechnern (schwächer, als was du da oben bemängelst) die meisten Bedürfnisse problemlos befriedigen. Unterschiede liege da allesamt nur im Bereich der Messtoleranz, und sind NICHT spürbar.
Ladezeiten zB gibt es subjektiv gar nicht mehr!
Subjektiv... bringt dir nur nichts.
Objektiv kannst du irgend einem Händler 50€ für ne supi-tolle Netzwerkkarte und vergoldete Kabel bezahlen, und am Ende bist du genauso dran wie der User, der n einfaches Cat5e aus dem Baumarkt mit dem Onboard-Netzwerkchip kombiniert. Und warum? Weil deine Seitenaufrufe GENAU DASSELBE Problem haben, wie alle: Serverseitige Latenzen.
Wenn du eine Seite aufrufst, passiert folgendes:
- Dein OS macht einen DNS - Request. Von deiner Hardware hängt der quasi gar nicht ab, nur von der Geschwindigkeit des DNS
- Dein Browser startet eine TCP-Verbindung zum Server. Die Antwortzeit hängt nicht zuletzt davon ab, wie viel Druck der Server gerade hat und wie gut er angebunden ist. Aber auch das einfache Routing durchs Netz spielt eine Rolle, genauso wie die geographische Entfernung.
- Wenn SSL verwendet wird, kommen jetzt der SSL-Handshake nebst Key Negotiation. Egal was du da für Komponenten verbaut hast, so ein Handshake dauert seine 100-200ms. Hier limitiert der Server
- Wenn du jetzt als Antwort ein 301 oder 302 bekommst, startet obiges Spiel noch einmal neu....
- Der Webserver fängt jetzt an, deine Antwort zu berechnen. Fragst du eine statische Ressource wie n Bild, geht das recht fix. Fragst du etwas dynamisches, wie z.B. einen Forenpost hier, dann muss der Server erst einmal Scripte laden, Datenbanken abfragen,...
- Das war die "Time to First Byte", auf die deine Hardware quasi 0 Einfluss hat. JETZT beginnt der eigentliche Datentransfer, und der hängt von der Internetverbindung zwischen dir uns Server ab. Ein Cat7-Kabel bei dir bringt dabei genau 0, wenn du nicht an einem GBit-Internetanschluss hängst. Da außerdem eine Webseite aus vielen kleinen Teilen besteht (Grafiken, CSS,...) und, ohne SPDY bzw. HTTP/2, all diese Teile jeweils obigen Verbindungsaufbau durch machen, spielt selbst dein hypothetischer GBit-Internetanschluss keine Rolle. Wenn du für ne 5kByte große CSS-Datei 200ms für den TCP- und SSL-Handshake verballert hast, dann spielt es einfahc keine ernsthafte Rolle, ob du die 5kB jetzt mit 1, 10 oder 100MBit/s lädst
So... wenn obiges passiert ist, DANN fängt der Browser erst an. Jetzt greifen die Mechanismen, die einen Browser "schnell" machen, also allen voran der optimierte CSS Renderer und der JavaScript JIT.
Denk dran, selbst wenn du eine einzelne HTML-Seite mit integriertem CSS- und JS-Code sowie Bildern als Base64-kodierte Strings geladen hast, hast du trotz allem bereits 500ms oder so an die Time to First Byte verloren, in denen Lynx genauso schnell wäre wie FF... Lynx ist eh einer der schnellsten Browser auf dem Markt. Da schmatzen Chrome, FF und IE gnadenlos ab!
