nicht angemeldet
Performance durch Code-trimming
0 0 0 
Gunnar Bittersmann
0
0
Performance durch Code-trimming
Der Martin
suit
MudGuardMoin,
klar, es gibt viele Seiten zu meiner Frage bei Lycos etc. Allerdings möchte ich hier mal die Experten fragen:
Wieviel bringt es, seinen JS-Code zu trimmen (Leerzeichen, Kommentare, Zeilenumbrüche, ...)? Lohnt sich der Aufwand, wenn man am Ende z.B. statt 10.000 Zeichen nur noch 5.000 Zeichen auf den Server stellt?
Paul
-
Wieviel bringt es, seinen JS-Code zu trimmen (Leerzeichen, Kommentare, Zeilenumbrüche, ...)? Lohnt sich der Aufwand, wenn man am Ende z.B. statt 10.000 Zeichen nur noch 5.000 Zeichen auf den Server stellt?
Bezüglich Übertragungszeit oder Ausführungszeit?
Es wird sich natürlich beides irgendwo auswirken machen, nur ob mans wirklich spürt?
Fragt sich eher was du davon hast wenn du deinen Code editieren musst und in einer einzigen langen Zeile nichts mehr kapierst. -
Es lohnt sich!
Ich hab mir selbst für Javascript und CSS ein kleines PHP Script geschrieben, was die zwei Sachen jeweils einliest, etwas optimiert und dann wieder ausgibt.
Da ich es selbst geschrieben habe, ist noch nicht das optimale heraus geholt.
Bei Javascript konnte ich jedoch 1/5 der Dateigröße optimieren. Und dass nur durch entfernen der Kommentare, Leerzeichen (natürlich nicht alle :D) und Zeilenumbrüche. Anscheinend habe ich zuviel von den drei Sachen in meinem JS Code....hmmm...
Bei Javascript kann ich aus meiner Erfahrung sagen, dass das Einsparen 1:1 auf die Übertragungszeit geht. Sprich ich hab 1/5 beim Code eingespart und 1/5 bei der Übertragungszeit. Das sind bei mir immerhin ~0,3 Sekunden.
Bei CSS sieht es etwas anders aus. Da konnte ich die Datei Größe um 1/3 reduzieren. Das hat aber lediglich ~0,1 Sekunde gebracht, wenn nicht sogar noch weniger. Die Übertragungszeit gesamt liegt bei ~350ms (JS) und ~280ms(CSS).
Bei Javascript muss ich jedoch noch hinzufügen, dass ich durch das PHP Script mehrere JS Dateien in einen Request packe. Sprich, das PHP Script liest alle JS Dateien aus einem Verzeichnis, baut daraus einen großen String, optimiert diesen und gibt dann alles als eine große JS Datei zurück. Somit habe ich die Request gleichzeitig minimiert.Gruß
mein Motto - schnelle Webseite, langer Sex
T-Rex-
@@T-Rex:
nuqneH
Bei Javascript kann ich aus meiner Erfahrung sagen, dass das Einsparen 1:1 auf die Übertragungszeit geht. Sprich ich hab 1/5 beim Code eingespart und 1/5 bei der Übertragungszeit.
Du überträgst den JavaScript-Code nicht gezippt? Der Vergleich von gezipptem minifiziertem und gezipptem nicht minifiziertem Code dürfte deutlich geringer ausfallen, da die Kompression schon das meiste rausholt.
Bei der Ausführung dürfte minifizierter Code etwas schneller sein, da 'a42' schneller zu parsen ist als 'meinLangerSprechenderVariablenname'.
Bei Javascript muss ich jedoch noch hinzufügen, dass ich durch das PHP Script mehrere JS Dateien in einen Request packe.
Ja, das sollte man i.d.R. tun. Auch bei CSS, falls man sein Stylesheet auf mehrere Dateien verteilt haben sollte.
Qapla'
--
Gut sein ist edel. Andere lehren, gut zu sein, ist noch edler. Und einfacher.
(Mark Twain)-
Du überträgst den JavaScript-Code nicht gezippt?
Ne, wie macht man das?
Sorry für die Leihenfrage.
-
Hallo,
Du überträgst den JavaScript-Code nicht gezippt?
Ne, wie macht man das?wahrscheinlich doch, denn die Server der meisten Webhoster sind schon von Haus aus so konfiguriert, dass sie das automatisch tun, wenn der Client (Browser) mitspielt.
Sorry für die Leihenfrage.
Laien haben in der Regel nichts mit Leihen zu tun.
Ciao,
Martin--
F: Was ist schneller: Das Licht oder der Schall?
A: Offensichtlich der Schall. Wenn man den Fernseher einschaltet, kommt immer erst der Ton, und dann erst das Bild.
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:( -
-
-
-
-
Hallo,
Wieviel bringt es, seinen JS-Code zu trimmen (Leerzeichen, Kommentare, Zeilenumbrüche, ...)? Lohnt sich der Aufwand, wenn man am Ende z.B. statt 10.000 Zeichen nur noch 5.000 Zeichen auf den Server stellt?
Es ist kein Aufwand, man sollte es automatisiert vor dem Hochladen der Scripte tun. Dabei helfen einem Build-Programme wie das von HTML5 Boilerplate.
Neben dem Entfernen von Whitespace nehmen Tools wie der Google Closure Compiler noch weitere Optimierungen vor, sodass der Code etwas anders als im Original aussieht und dadurch minimal schneller wird.
Wichtig(er) ist wie gesagt das Komprimieren mit GZip, der Webserver sollte entsprechend konfiguriert sein. Zudem sollten mehrere JS-Dateien zu einer zusammengefasst werden sowie Bibliotheken wie jQuery von Content-Delivery-Networks eingebunden werden.
Kombiniert man das alles, lohnt es sich auf jeden Fall.
Mathias
-
sowie Bibliotheken wie jQuery von Content-Delivery-Networks eingebunden werden.
Das hat aber auch negative Nebenwirkungen. Diese CDN ("content delivery networks") sind immer noch weitere Server. Das birgt neben klaren Vorteilen (einmaliges Caching in Proxis und Browsern) auch die Gefahr von Problemen.
Ein Server sei zu 99% online und erreichbar. Zwei davon sind es nur zu 98% (0.99 * 0.99 = 0.9801). Das macht dann im Jahr statt 3.65 immerhin 7.3 Ausfalltage. Jedenfalls wenn die externen Skriptbibliotheken wichtig für die Funktion sind.
Ich weiß das die Ausfallraten von CDN sehr niedrig sein sollen. Die nächste Frage ist die nach der Sicherheit der DNS. Gerade da hört man wenig Gutes. Fast zum Schluss noch eine Einschränkung: Was passiert bei Webseiten die mit SSL (also verschlüsselt) abgeholt werden und im Klartext ausgelieferten Skripten?
Und dann ist da noch ein Problem. Der Datenschutz. Diese CDN lassen sich prima zum User-Tracking verwenden. Und wenn man auf die CDN verweist, dann hat man keine Kontrolle mehr über die gelieferten Skripte. Das kann der "größte anzunehmende Unfall" werden.
Fred
-
Ein Server sei zu 99% online und erreichbar. Zwei davon sind es nur zu 98% (0.99 * 0.99 = 0.9801). Das macht dann im Jahr statt 3.65 immerhin 7.3 Ausfalltage. Jedenfalls wenn die externen Skriptbibliotheken wichtig für die Funktion sind.
Du gehst in deiner Rechnung davon aus, dass ein CDN mit Verfügbarkeitsklasse 2 im Netz hängt?
Ich weiß das die Ausfallraten von CDN sehr niedrig sein sollen.
Eben - eine zu vernachlässigende Größe.
Die nächste Frage ist die nach der Sicherheit der DNS. Gerade da hört man wenig Gutes.
Quelle? Google und Microsoft haben bei mir jedenfalls noch immer jQuery ausgeliefert und nicht irgendwelchen Schadcode.
Ich würde mich da eher um den Datenschutz sorgen - ein CDN stellt man nicht zur Verfügung weil man nett ist, sondern weil man Wirtschaftliche interessen hat - jQuery über ein CND auszuliefern ist genauso schädlich wie einen Facebook-Like-Button einzubinden.
Fast zum Schluss noch eine Einschränkung: Was passiert bei Webseiten die mit SSL (also verschlüsselt) abgeholt werden und im Klartext ausgelieferten Skripten?
Security Through Obscurity funktioniert nicht - warum sollte man JavaScript verschlüsseln? Sensible Dinge laufen "daheim" und den Quelltext diverser Frameworks kann man sich auch so überall ansehen.
Und dann ist da noch ein Problem. Der Datenschutz. Diese CDN lassen sich prima zum User-Tracking verwenden. Und wenn man auf die CDN verweist, dann hat man keine Kontrolle mehr über die gelieferten Skripte. Das kann der "größte anzunehmende Unfall" werden.
Siehe oben - der Datenschutz ist ein Problem, aber dass die Scripte manipuliert werden, halte ich bei seriösen Anbietern trotzdem für ausgeschlossen - und nein, Facebook ist nicht seriös :)
-
Tach,
Security Through Obscurity funktioniert nicht - warum sollte man JavaScript verschlüsseln?
Es ist wichtig so viel wie möglich zu verschlüsseln, damit verschlüsselte Botschaften nicht hervorstechen.
Sensible Dinge laufen "daheim" und den Quelltext diverser Frameworks kann man sich auch so überall ansehen.
In einer Applikation die sensible Daten verarbeitet, darf man natürlich keinen externen, unkontrollierbaren Code einbinden.
Siehe oben - der Datenschutz ist ein Problem, aber dass die Scripte manipuliert werden, halte ich bei seriösen Anbietern trotzdem für ausgeschlossen
Bei der Menge an ein Einbrüchen bei Certificate Authorities in diesem Jahr, hältst du das immer noch für ausgeschlossen? Deine Zuversicht möchte ich haben.
mfg
Woodfighter-
Es ist wichtig so viel wie möglich zu verschlüsseln, damit verschlüsselte Botschaften nicht hervorstechen.
Wenn damit nicht ein defekter oder unsicherer Verschlüsselungsalgorithmus kaschiert wird, kann das zusätzliche Sicherheit bedeuten - in einer Open-Source-Umgebung (was quasi die Grundvoraussetzung für Kryptographie ist), funktioniert das aber nicht.
In einer Applikation die sensible Daten verarbeitet, darf man natürlich keinen externen, unkontrollierbaren Code einbinden.
So ist es.
Siehe oben - der Datenschutz ist ein Problem, aber dass die Scripte manipuliert werden, halte ich bei seriösen Anbietern trotzdem für ausgeschlossen
Bei der Menge an ein Einbrüchen bei Certificate Authorities in diesem Jahr, hältst du das immer noch für ausgeschlossen? Deine Zuversicht möchte ich haben.
Ich meinte, dass Scripte absichtlich manipuliert werden :)
-
Siehe oben - der Datenschutz ist ein Problem, aber dass die Scripte manipuliert werden, halte ich bei seriösen Anbietern trotzdem für ausgeschlossen
Bei der Menge an ein Einbrüchen bei Certificate Authorities in diesem Jahr, hältst du das immer noch für ausgeschlossen? Deine Zuversicht möchte ich haben.
Ich meinte, dass Scripte absichtlich manipuliert werden :)
Naja. Zuerst baut sich der Staat Bayern ein ganz eigenes Zertifikat für https://api.wasweisich.com/, weil dessen Betreiber nicht so will wie der Diener des (Rechts-)Freistaates selbst.
Dann verbiegt der rechtstreue oder mit einer Steuerprüfung oder mit der Beschlagnahme aller Server ("Auf einer der Webseiten steht was, das könnte eine Beleidigung sein!") erpresste Zugangsverschaffer die IP von api.wasweisich.com auf die 200.150.22.134.
Aus irgend einem dummen Grund wird bei den Besuchern von diversen in Deutschland gehosteten und deshalb "sicheren und gut geschützten Webseiten" illegale Software installiert sowie ein paar Filmchen in einer verschlüsselten Datei gespeichert und just vor einem Wahltermin gerade noch rechtzeitig bei einem "Sozi" gefunden (und die verschlüsselte Datei aufregend schnell geknackt!) um damit WIRKLICH jedem Bürger klar zu machen, dass die Online-Durchsuchung das ultimative und alternativlose Mittel ist um böse Kinderschänder, Linksterroristen, arabisch aussehende Busfahrer oder Raubmordkopierer am Arsch zu kriegen, weshalb er gefälligst die vom LKA gesteuerte NPD (oder anders herum?) oder mindestens die CDU zu wählen hat!
Jemand mein das gibt es nicht? Wohl gibt es das!
-
Tach,
Es ist wichtig so viel wie möglich zu verschlüsseln, damit verschlüsselte Botschaften nicht hervorstechen.
Wenn damit nicht ein defekter oder unsicherer Verschlüsselungsalgorithmus kaschiert wird, kann das zusätzliche Sicherheit bedeuten - in einer Open-Source-Umgebung (was quasi die Grundvoraussetzung für Kryptographie ist), funktioniert das aber nicht.
nein, es geht darum, dass verschlüsselte Kommukition nicht hervorstechen darf: Wenn du deine gesamte Kommunikation verschlüsselst, stechen die wirklich wichtigen Nachrichten darin nicht mehr hervor; so ist zum Beispiel nicht mehr nachvollziehbar, mit wem du geheim kommunizieren möchtest/mußt und mit wem nicht.
Siehe oben - der Datenschutz ist ein Problem, aber dass die Scripte manipuliert werden, halte ich bei seriösen Anbietern trotzdem für ausgeschlossen
Bei der Menge an ein Einbrüchen bei Certificate Authorities in diesem Jahr, hältst du das immer noch für ausgeschlossen? Deine Zuversicht möchte ich haben.
Ich meinte, dass Scripte absichtlich manipuliert werden :)
Ich auch.
mfg
Woodfighter
-
-
-
jQuery über ein CND auszuliefern ist genauso schädlich wie einen Facebook-Like-Button einzubinden.
Das ist ein völliger Quatsch. Facebook.com setzt einen Cookie, und wenn man bei Facebook eingeloggt ist, so bekommt Facebook bei jedem Like-Button auf einer Drittseite mitgeteilt, dass eben dieser Nutzer dort verkehrt. Das kann googleapis.com natürlich nicht. Weder setzt es einen Cookie noch kann der Betreiber so einfach wie Facebook eine Verbindung zur Person bzw. einem Profil herstellen.
Mathias
-
Das ist ein völliger Quatsch. Facebook.com setzt einen Cookie, und wenn man bei Facebook eingeloggt ist, so bekommt Facebook bei jedem Like-Button auf einer Drittseite mitgeteilt, dass eben dieser Nutzer dort verkehrt.
Da muss ich dir entschieden widersprechen - Facebook trackt auch dann das Nutzerverhalten über die Like-Buttons wenn man nicht bei Facebook eingeloggt ist - selbst dann, wenn man nichtmal dort Mitglied ist.
Das kann googleapis.com natürlich nicht. Weder setzt es einen Cookie noch kann der Betreiber so einfach wie Facebook eine Verbindung zur Person bzw. einem Profil herstellen.
Allein über den HTTP-Request den du stellst, kann schon relativ gut nachvollzogen werden, auf welchen Seiten du dich bewegst - auch wenn kein direkter "Personen"bezug hergestellt werden kann. IP-Adresse und User-Agent reichen für ein grundlegendes Tracking bei weitem aus.
Kommst du dann bei Google vorbei - mit derselben IP-Adresse und demselben User-Agent, ist es recht einfach die Daten zu verknüpfen.
Der Unterschied: Google verkauft die Daten nicht an Dritte, Facebook schon.
-
-
Hi,
Fast zum Schluss noch eine Einschränkung: Was passiert bei Webseiten die mit SSL (also verschlüsselt) abgeholt werden und im Klartext ausgelieferten Skripten?
Security Through Obscurity funktioniert nicht - warum sollte man JavaScript verschlüsseln? Sensible Dinge laufen "daheim" und den Quelltext diverser Frameworks kann man sich auch so überall ansehen.z.B: weil Browser Warn-Meldungen anzeigen, wenn in einem per https abgerufenen Dokument Resourcen eingebunden werden, die nicht per https geholt werden.
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
z.B: weil Browser Warn-Meldungen anzeigen, wenn in einem per https abgerufenen Dokument Resourcen eingebunden werden, die nicht per https geholt werden.
Das ist mir klar - aber was hindert dich, entsprechendes Zeug per HTTPS einzubinden? Selbst der Facebook-Like-Button wird in so einem Fall per HTTPS eingebunden, das ist kein Argument.
-
Hi,
z.B: weil Browser Warn-Meldungen anzeigen, wenn in einem per https abgerufenen Dokument Resourcen eingebunden werden, die nicht per https geholt werden.
Das ist mir klar - aber was hindert dich, entsprechendes Zeug per HTTPS einzubinden?
Seltsam - erst fragst Du, warum man Javascript verschlüsseln sollte, und wenn man Dir einen Grund nennt, dann sagst Du, dann verschlüssel es doch ...
cu,
Andreas--
Warum nennt sich Andreas hier MudGuard?
O o ostern ...
Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
-
-
-
-
Hallo,
1. Wenn das CDN nicht erreichbar ist, kann man einfach prüfen, ob die Bibliothek geladen wurde und ggf. synchron eine lokale Variante laden, vgl.
2. SSL-Websites verwenden einfach SSL-CDNs.
3. CDNs können einfache Statistiken führen, mehr nicht. Sobald sie z.B. Cookies setzen, machen sie ihre Aufgabe jedoch falsch, denn das belastet die Performance. Davon ist abzusehen.
4. CDNs hat man durchaus unter Kontrolle. Dass Google und Microsoft für jeden JS-Bibliotheken hosten, ist kein CDN im engeren Sinne. Ein solches wäre etwa Amazon CloudFront, dort kann man eigenen Content verteilen. Das ist so sicher wie zentrale Webspaces, auf die man etwas hochlädt.
Mathias
-
- CDNs können einfache Statistiken führen, mehr nicht.
Die können mindestens die gleiche Statistik führen wie jeder andere Webserver, also IP, Useragent, Uhrzeit, Datum usw. Ich halte das für ne ganze Menge.
Wenn das für dich eine einfache Statistik ist, muss ich mich fragen, wo bei dir die Überwachung angeht.
Mal abgesehen davon, dass ich nicht will, dass ein externer Anbieter weiss, wieviele Seitenaufrufe ich habe, will ich nicht, dass diese Daten meiner Seitenbesucher bei irgendwelchen Datenkraken landen.
-
-
-