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!