Ladezeit enorm hoch?

Beitrag von **Nullpointer** » 04.11.2009, 18:41

Die aktuelle kleine Version heißt
jquery-1.3.2.min.js
55.9 KB
gegenüber 117 bei der großen
die große halt ohne min

von **Anzeige von ABAKUS** »

Beitrag von **domainsnake** » 04.11.2009, 19:18

Hmm, keine Ahnung, ok auf jeden Fall ist das Kleiner aber ich hab nicht mal ne Ahnung, wofür das überhaupt ist ? Ob die kleine Version ausreicht oder ob man dann eingeschränkt ist?

Beitrag von **chris21** » 04.11.2009, 19:27

@domainsnake:

Die ist nicht eingeschränkt.

Bei normalen Javascript Dateien sind viele Prozent der Datei nur auf Leerzeichen, Zeilenumbüchen und Kommentaren im Code zurückzuführen.

Dadurch ist es für Entwickler sehr gut lesbar und somit wartbar.

Die minify Version oben verzichtet lediglich auf diese Leerzeichen, Zeilenumbüche und Kommentare und kürzt eventuell auch Variablennamen.

Für die Funktionalität hat dies keinerlei Einfluss, dort wird nicht gekürzt.

Beitrag von **domainsnake** » 04.11.2009, 19:40

Wow, thanks für die ausführliche Erklärung.

Beitrag von **Bauchladen** » 04.11.2009, 19:40

Gebe deinem Programmierer mal den Tip dass sich Javascript und Stylesheet Dateien auch packen lassen. 117 KB für https://www.anglerzeitung.de/js/jquery.js ist ein wenig viel. Da lassen sich locker 62 KB einsparen. Calendar.js gleich mit packen (spart 20 KB) lassen und die englische Sprachdatei von Calendar (https://www.anglerzeitung.de/js/calenda ... ndar-en.js) übersetzen lassen (die DE ist kaputt, ist bekannt, darum hat der die "english" Version genommen. Übersetzen dauert 5 Minuten) .. wobei ich mich frage wo der Calendar auf der ersten Seite benötigt wird.

Mit https://www.anglerzeitung.de/files/angeln.css kommt man von 22 KB auf 17 KB

Bevor du den Webserver für die Komprimierung der Daten verwendest lasse deinen Entwickler mal was tun.

Grüße

Beitrag von **domainsnake** » 04.11.2009, 20:44

Ok, habs weitergeleitet. Ich denk auch das viel Einsparpotential vorhanden ist. Auf der Startseite wird das glaub ich auch net benutzt, sondern innerhalb des Membersystems für das Eintragen vom Geburtstag.

Danke euch allen für die Tipps.

Beitrag von **xAaron** » 04.11.2009, 21:23

Ok, eigentlich ist das meiste schon gesagt worden:
Überall in den html, js und css Dateien die Kommentare entfernen. Sämtliche js-scripte und css-code in eigene Dateien auslagern, dann den Server so einstellen, dass die Besucher, wenn sie diese Daten noch Mal abrufen(also eine andere Seite aufrufen) einen 304er bekommen(der Browser kriegt nur den Hinweis, dass die Daten denen, die schon geschickt wurden entsprechen, die js und css Dateien werden also nur ein einziges Mal geladen, egal wie viele Unterseiten angeguckt werden).
Dann die html-, js- und css-Dateien g-zip-komprimieren, also mit dem deflate-Modul oder in php mit ob_gz... Dann brauchst du auch nicht aus dem Quellcode die Leerzeichen rausschmeißen. Das reduziert ie Größe in etwa auf 1/3. Wenn noch die Kommentare raus sind, dann hast du eine schon wirklich gute Einsparung.
Die jpg-Bilder in Photoshop immer mit Web-Export speichern und nicht unter datei->speichern, das bringt auch noch signifikante Unterschiede.

Beitrag von **domainsnake** » 04.11.2009, 21:28

Muss gleich wech aber eines wollt ich doch noch wissen. Ist ja immer nicht verkehrt etwas zu verstehen, um ein Problem zu beseitigen. Was ich nicht verstehe ist wie der Traffic zustande kommt. Ich mein gesetzt dem folgenden Fall das die Homepage wie am Anfang 750kb auf der Startseite hat.

750 kb x Anzahl der Besucher 125 =87 MB und 500 kb (Grob gesagt) Ich geh mal vom 5 Seitenimpressions pro User aus. 5 x 87,5 = 437,5 MB

Laut Trafficverbrauch hab ich im Schnitt 2-3 GB Traffic gehabt. ???? Oder hab ich jetzt nen totalen Denkfehler drin. Wär ca 7x so viel wie ich jetzt ausgerechnet hab.

Beitrag von **xAaron** » 04.11.2009, 21:31

Guck mal in deine log-files, nicht dass dir irgendwer eins der skripte gehackt hat und gerade irgendwelche warez-Dateien runtergeladen werden. Du musst in deine Rechnung auch noch die Bilder einfließen lassen.

Beitrag von **xlb** » 04.11.2009, 21:57

Hallo...

Hat dein Coder schon mal was von Doctypes und Validität gehört? Weiss'ja net in wie weit das für dich wichtig ist, aber 526 Fehler ist absoluter Rekord bisher!

Einen solches Markup zu verbrechen :
massig Inline-CSS, massig Inline-JS, massig als "deprecated" gekennzeichnete Tags, riesige auskommentierte Blöcke, "blöde" CSS-, Javascript- und HTML-Fehler und das alles als strict XHTML ...

Jag'die Seite mal durch einen Validator und/oder lasse beim Laden der Seite mal die Fehlerkonsole mitlaufen ... - ein Trauerspiel

Das Markup sollte dringend komplett überarbeitet werden, dann wird's auch automatisch schlanker.
Das Tabellen-Layout sollte in deinem Fall evtl. besser durch eine schlanke CSS-Alternative ersetzt werden.

Bei der bis dato enormen Menge an externem JS und CSS macht es auf jeden Fall Sinn, unnötigen Whitespace zu entfernen und die Files dann komprimiert auszuliefern.

Die Bilder haben auch noch Potential zur Optimierung. Mit PS muss man dafür aber auch umgehen können. Gibt'da ein AddOn für IrfanView, dass das recht unkomliziert erledigt.

Bevor du mit Server-seitigem offpage-Krams anfängst oder auf SEO schielst, sollte hier onpage erstmal eine Menge getan werden!

Gruss soweit,
xlb

Beitrag von **domainsnake** » 05.11.2009, 04:47

In den 500kb sind die Bilder doch schon mit drin, also mit eingerechnet. Aber egal wie ich hin oder herrechne, der Traffic scheint mir für die Handvoll Besucher einfach zu gross. Gestern wieder ein neuer Rekord mit sage und schreibe 3,17 GB Traffic laut Transferdetails von Parallels Confixx. In den AWstats hingegen steht das die 150 Besucher 200 MB verbraucht haben oder ich les da was falsch. ??? Dann noch ne andere komische Sache wie ich finde.

Unter den Robots/Spider war dieser Wert zu finden. Also über dem Google Bot. Beim Google Bot standen für den 5.11 35 MB
Unknown robot (identified by empty user agent string) 189536+1 9.66 GB 05.11.2009 - 02:04

Keine Ahnung, ob das was zu sagen hat aber ich muß der Sache ja nachgehen. Viel Ahnung hab ich aber von der Materie net.

Ja, hab ich auch schon festgestellt das der Code Verbesserungswürdig ist. Steht auch auf der Liste den noch zu verbessern, Fehler zu korrigieren etc. Bin aber auch froh, wenn erstmal alles funktioniert

Beitrag von **domainsnake** » 05.11.2009, 04:57

Hab nochmal eben die Werte für Oktober nachgeschaut. 18,84 GB ???

Unknown robot (identified by empty user agent string) 373555+4 18.84 GB 31.10.2009 - 23:53
Unknown robot (identified by 'crawl') 7068+107 244.49 MB 31.10.2009 - 23:59
Googlebot 5263+36 195.83 MB 31.10.2009 - 23:53

Hmm, also im Juli lag der Wert noch im MB Bereich vom unknown Bot, im August bei 2,3 GB, im September bei 9,8GB, im Oktober bei 18,8 GB und jetzt im November schon bei 9,8

Ist das alles ein Anzeichen für Seite gehackt?

Beitrag von **domainsnake** » 05.11.2009, 05:08

Langsam glaub ich echt es war ein Fehler Web 2.0 Elemente, Membersystem etc. mit einzubringen, wenn man dann so leicht gehackt wird. Scheint ja jetzt doch eher daran zu liegen.

Wie könnte man so einen Hack jetzt überhaupt finden und beseitigen? Fragen über Fragen.

Beitrag von **Nullpointer** » 05.11.2009, 06:38

schau doch mal in die access logs vom apache, auf welche dateien der unknown bot zugreift.

Beitrag von **xlb** » 05.11.2009, 08:54

Ja, hab ich auch schon festgestellt das der Code Verbesserungswürdig ist.

Wann hast du das festgestellt? Gab's während der "Entwicklung" der Seite eine nennenswerte Kommunikation/Evaluation mit deinem Coder? Tests?

Bin aber auch froh, wenn erstmal alles funktioniert

IMHO komplett faslcher Ansatz für ein solch "grosses" Projekt. Denn offenbar funktioniert irgendwas irgendwo überhaupt nicht so wirklich. Von daher wundert mich auch deine Frage:

Wie könnte man so einen Hack jetzt überhaupt finden und beseitigen?

Hmm ... - siehe oben: Seite aufräumen, (Skript-)Fehler finden und korrigieren - vom "Kleinen zum Grossen". Könntest deinen Coder mal fragen, woher die (servereitigen) Skripte stammen, bzw. ob die Quellen "vertrauenswürdig" sind/waren. Hoffe in deinem Interesse, dass er da nicht wirklich selbst Hand angelegt hat. Das total verkorkste Frontent-Markup weckt da wenig Vertrauen.
Von daher ...

... lasse deinen Entwickler mal was tun.

... - besser nicht.

Ist das alles ein Anzeichen für Seite gehackt?

Nein - "erstmal" nicht. Befolge Nullpointer's Rat und wirf einen Blick in aktuelle access.logs. Vielleicht klaut sich ein (oder mehrere?) Media-Bot deine Bilder - gibt's ja einige von.
In diesem Zusammenhang ist deine robots.txt erwähnenswert:

Code: Alles auswählen

User-agent&#58;*
Disallow&#58;

Alle Bots dürfen alles lesen.

Basiert deine Seite auf einem CMS? Was "selbstgestricktes" ...?

Edit: Sollten sich in deinen Logs Einträge mit "merkwürdigen" oder ohne UserAgents finden lassen, dann jag'die IPs mal durchs whois oder poste sie ...