Javascript Performance Probleme

deshtruct · 26.11.2013

Hallo Freunde,
arbeite zur Zeit an dem Webauftritt eines Architektenbüros.
Hier könnt ihr schon mal einen Blick drauf werfen.

Wie ihr sehen werdet, habe ich ein großes Raster erstellt.
Die Spalten bilden die einzelnen Projekte und darin befinden sich weitere Divs in denen jeweils ein Bild liegt.
Eigentlich bin ich recht zufrieden mit dem bisherigen Ergebnis, wenn da nicht die dämlichen Smartphones wären.
Auf meinem iphone 3gs ist die Projekteansicht ziemlich zerhackt und die Perfomance ist unter aller Sau. Wenn das Scrolling mal funktioniert, dann nur sehr ruckelig.
Ich beschäftige mich noch nicht sehr lange mit Webprogrammierung und denke, dass es noch eine Menge zu optimieren gibt.
Vielleicht hat jemand von euch einen konkreten Tipp?

Danke schon mal vorweg,
mfg Georg

cythux · 26.11.2013

AW: Javascript Performance Probleme

für Javascript/CSS zu verkleinern kann man mittels YUI Compressor verkleiner http://refresh-sf.com/yui/

ich weiss jetzt nicht ob es von Dir oder dem CMS inline styles sollte man vermeiden

für mobile Fassung, sollest du Mediaqueries nutzen vieles darüber kann man auch bei Css-tricks finden

Duddle · 26.11.2013

AW: Javascript Performance Probleme

Ich habe kaum Erfahrung mit JavaScript Profiling (und das ist das Zauberwort für deine Google-Suche), aber FireBug sagt mir, deine Seite benötigt rund 37k JS-Operationen beim Seitenaufruf. Zum Vergleich: spiegel.de oder psd-tutorials.de machen 15k.

Wahrscheinlich kannst du mit entsprechenden Tools genauer eingrenzen, welches deiner 20 PlugIns am meisten Performance kostet, aber ich würde raten, deine eigene Scripte am Ende (die ich mir nur im Überblick angeschaut habe) sind Ursache der überflüssigen Funktionsaufrufe. Das sieht mir ein bisschen zu komplex (für diese Website) und fast schon wie Java aus.

Duddle

deshtruct · 26.11.2013

AW: Javascript Performance Probleme

Hallo ihr Beiden,
danke für eure schnellen Antworten

Erstmal zu dir, cythux:
Den Compressor werde ich mir mal anschauen, aber ich denke nicht, dass es allzu viel bringen wird. Die Inline-styles habe ich natürlich nicht per Hand geschrieben. Die werden durch Javascript erzeugt
Das mit den Mediaqueries ist mir natürlich bewusst, aber leider sieht die Seite auf jedem Smartphone anders aus.

Nun zu dir, Duddle:
Danke für den Hinweis mit den Operationen. Wo genau sieht man das bei Firebug?
Allerdings dachte ich mir schon, dass da das Problem liegt. Versuche gerade den Code etwas aufzuräumen.
Wieso meinst du, sieht mein Code aus wie Java? Wegen den vielen Klassen und den Funktionen? Ich dachte immer, das würde guten Code ausmachen.
So, ich mach dann mal weiter

Duddle · 26.11.2013

AW: Javascript Performance Probleme

Wo genau sieht man das bei Firebug?

In der FB-Konsole: Zeitmessung - irgendwas machen - nochmal Zeitmessung. Es gibt aber sicher bessere Tools, das von FireBug ist nicht so hilfreich.

Wieso meinst du, sieht mein Code aus wie Java?

Wie gesagt, es sieht übermässig komplex aus für das was die Website macht. Aber das ist nur mein Ersteindruck nach dem Überfliegen.

Duddle

Myhar · 27.11.2013

AW: Javascript Performance Probleme

deshtruct schrieb:
Das mit den Mediaqueries ist mir natürlich bewusst, aber leider sieht die Seite auf jedem Smartphone anders aus.

Nicht, wenn du mit Mediaqueries arbeitest. Natürlich, ein identes Aussehen wirst du auf unterschiedlichen Geräten nicht schaffen, aber das ist auch nicht möglich, bzw. erwünscht.
Und wieso verwendest du auf deiner Seite user-scalable=no ? Da wird nie jemand deine kleine Schrift lesen können.
Aber ich kann mich ansonsten nur duddle anschließen: Räume deine Seite, bzw. deine Javascripts auf. Überdenke auch, welche von deinen Effektspielereien du wirklich benötigst: Du schränkst deine Besucher doch sehr in Ihrer Handlungsfreiheit ein. Sicher, es sind supercoole Effekte und so, aber wenn ich auf einer Seite nicht einmal ordentlich scrollen kann, dann verlasse ich die Seite so schnell, wie ich sie gefunden habe. Auch ist die Struktur der Seite nicht wirklich erkennbar.
Es gibt Punkte, die einem anzeigen, wo man gerade ist, aber anklicken kann man sie nicht. Und solche Punkte werden von den meisten Usern nicht als das erkannt, was sie sind (positionsangaben). Auch, wenn diese Punkte auf vielen Seiten verwendet werden.
Dann gibt es noch diese Quadrate, auf die kann man komischerweise klicken. Dann weiß man erst einmal nicht, wie man wieder zurück zum vorigen Projekt kommt, da hier ja alles mit JS passiert und der Zurück-Button nicht wie erwartet funktioniert.
Mein Rat also: Anstatt zu versuchen, JS zu optimieren, schaffe eine klare, verständliche Struktur und verzichte dafür auf solche Effektspielereien. Gib jedem Projekt eine eigene Seite, dann lassen sich die Projekte übrigens auch für Suchmaschinen besser indizieren und man wird besser gefunden. Nur so als Denkanstoß, falls das deinem Kunden wichtig ist

Curanai · 27.11.2013

AW: Javascript Performance Probleme

Darf ich mich hier mit einklinken? Performance-Analyse und Flaschenhalsöffnung ist ein geliebtes Fachgebiet ... ^^

Also klicken wir mal oben auf die URL ... mit einer VDSL-Leitung des Magenta-T klappt das alles superschnell, keine Schmerzen und am heimischen PC mit Leistungsmerkmalen oberer Klasse ist die Seite problemlos (verwendet: FF).

Aber wenn Du "responsive webdesign" probierst - was Du versuchst -, verstößt Du gegen diese, aber auch generelle Grundsätze. Zunächst ...

Bilder skalieren - das ist ein toller Effekt ... aber das Bild (direkt das 1.) bleibt bei 200k. Für meinen PC, für eine Konsole, ein Auto, einen Kühlschrank, ein Tablet oder Smartphone! Diese 200k müssen erstmal ankommen ... auch gehe ich damit konform, dass die ganzen Plugins vielleicht gar nicht sein müssen und Du da ausmisten müsstest. Doch zurück zum Quelltext ...

Jede Performance-Analyse fängt mit folgender Frage an: "Ist JavaScript und CSS extern und wieviele http-Requests (zzgl. DNS-Lookups) werden für die Verfügbarkeit erzeugt?" Schaue ich in Deinen Source, sehe ich sieben JavaScripts (= 7 requests) - und nochmal acht (= 8 weitere requests) am Ende der Seite. Warum stehen a) nicht alle JavaScript "bottom" und werden nicht zentral geladen? (= ein Request nur?!) Sobar ein Request für 1 Byte (!) auf myfonts.de ist drin ...

Ich erhalte 404er (für "arrow_up.png" bspw.) - auch das sind Requests, die niemand benötigt.

Nebenbei: Du hast bereits jetzt rudimentäre SEO-Fehler drin (Stichwort: h1-Tag), die sich später nur ganz schwer wieder rausnehmen lassen - wenn es so bleibt!

Warum ruckelt es auf dem Smartphone, wenn die Plugins doch eigentlich das können? Und jetzt fliegt Dir wohl die Seitenstruktur um die Ohren - und da solltest Du Mobilgeräten eine andere Lösung anbieten: Ein Aufruf der Seite lädt alles - direkt (darunter sehr viele und große Bilder). Ich mutmaße, dass Dein Smartphone deshalb ruckelt, da Du mit dem Scrollen beginnst, obwohl das DOM noch gar nicht fertig gerendert (da noch nicht alle Bilder da [Skalieren = Rechenzeit]) ist. Und ein "Apfel" (beim 5er liegt mir keine andere Meldung vor) cached Dateien > 25 KB gar nicht ...

Warum benutzt Du keine Sprites für die "snap_"-Images? Du könntest da aus 5 Grafikabholunen eine machen ...

JavaScript kannst Du auch mit "minify" verkleinern - bedenke aber, dass Du den Quellcode "offen" irgendwo dennoch behältst. Kompressoren sind nett für "unnötige Zeichen" (Leerschritte, Abstände usw.) und verringern das Datenvolumen dadurch natürlich, können den Weg zurück aber nicht ... also, aufgepasst!

Die htaccess liefert übrigens auch "no-cache" zurück, aber das schiebe ich jetzt auf "Entwicklung".

Zusammengefasst: 92 Anfragen (= requests) für 5,5 MB (!) ... benötigt hier drei Sekunden! (abzgl. Plugin-Zeit) ... aber das ist eigentlich viel zu langsam "in the wild". Soviel Zeit hat die Seite nicht, wenn ein (neuer) Besucher diese besuchen will und es zu lange dauert ...

Mein Tipps für Dich:
- CSS: @import url("//hello.myfonts.net/count/28d107"); = "noch ein request nebst DNS-Lookup"
- lade keine Bilder, die der User gar nicht sieht/sehen wird/nicht anfordert
- Scripte zusammenfassen und "bottom"-load
- Überdenke, ob Du die eigenständigen Divs (mit Bild und Artikeln je Projekt) nicht lieber bei Bedarf via AJAX nachlädst (ein User hat für eine Ladegrafik eher Verständis - außerdem sieht er dann schon was); alternativ: zwei Artikel im voraus laden ... prinzipiell wie diese "infinity-load"-Listen
- SEO überdenken (vieles ist schon richtig, aber das mit h1-Tags ist ein "no go")

Jetzt muss ich selbst zurück und was tun ... viel Erfolg!