Ich habe lange überlegt ob ich auf diesen von Dir verfassten Post eingehen soll oder ob ich es lasse, nun Anhand meiner Antwort jetzt, kannst Du meine Entscheidung sehen.
Danke, aber als Reaktion wollte ich eigentlich nicht schon wieder eine Belehrung bekommen und vor allem nicht in Sachen Community Gedanken und noch weniger den Vorwurf der Arroganz. Fast wirkt es schizophren, lobst mich einerseits, haust mir aber schon wieder ein negativ besetztes Wort um die Ohren. Irgendwie passt das nicht zusammen mit Deinem ach so hoch gelobten Community Gedanken. Ich rechne es Dir aber hoch an, dass Du die Community Fahne versuchst hochzuhalten.
Wenn Du die XTC Szene dem Vernehmen nach so lange zu kennen glaubst, hat Dich Dein Glaube an diesen Community Gedanken dem Anschein nach aber blind gemacht und Du merkst nicht, dass Du ein "totes Pferd" reitest. Nicht was den Community Gedanken anbetrifft, sondern dieses Shop System. Die Todesglocken läuten seit "Bellendorf" furchtbar laut, es hört nur keiner. Richte Deinen Blick auf das Marktumfeld rings um den Modified Shop und Du wirst feststellen, dass da eigentlich und das schon seit Jahren nichts mehr ist. Wenn selbst die Entwickler dieses Shop Systems in ihrem neuen Shop eine Domain Abfrage für den Kauf eines Moduls machen, was ja nicht wirklich für den Community Gedanken spricht und noch weniger für die GPL, solltest Du vielleicht einen Anreiz dafür bekommen, um das große Ganze zu verstehen, dass das Pferd bereits schimmelt.
Nichtsdestotrotz will ich Deinen gemeinschaftlichen Gedanken mit dem Code Beispiel unterstützen, muss diesen aber korrigieren, weil damit wie auch schon im Original absolut nichts gewonnen ist. Leider schleppt man auch in der aktuellen Version, bzw. im neu hinzugekommen responsiven Template die Fehler aus früheren Version mit. Das ist aber keine Glaubensfrage, ob und was daran falsch ist, sondern lässt sich faktisch belegen.
1.) Dein Code Beispiel ändert absolut nichts an der Datenmenge, wenn man von dem externen Optimieren der Bilder mal absieht. Deine hinzugefügten Angaben zur Größe eines Bildes sind obsolet und stehen im Widerspruch zu den CSS Angaben, die diese die HTML Größen Attribute ohnehin überschreiben. Letztendlich ist das Ergebnis das Gleiche wie unverändert. Die Bilder müssen nach wie vor bedingt durch die "RD-Methode" skaliert werden und noch viel schlimmer, jedes Gerät bekommt das gleiche Bild. Smartphones müssen also immer noch die viel zu großen Bilder für Desktops laden. Das einzige positive ist der Schnipsel für das Lazy Load, aber diese Funktion unterscheidet sich nicht wesentlich vom Original, bzw. macht das Gleiche. Bringt also nüscht.
2,) Die RD-Methode erlaubt keinen großen Spielraum, um vor allem die Datenmenge zu reduzieren, sodass auch die Möglichkeiten sehr begrenzt sind etwas verbessern zu können. "A bisserl was " geht aber immer noch. Deswegen hier mein Korrekturvorschlag.
I.) Das komplette <noscript> Gedöns bei allen Bildern entfernen. Funktioniert nicht so wie soll, ist deswegen unnötiger Code, muss aber trotzdem gerendert werden.
II.) Javascript ist eine Standard Funktion in jedem Browser, die ebenso standardmäßig aktiv ist. Wer JS bewusst ausschaltet, weiß warum er nicht mehr alles in einer Webseite so sieht wie sie aussehen sollte. Anteil derer, die bewusst ohne JS unterwegs ist geschätzt 0,001 %. Selbst wenn es ein paar Promille mehr sind, steht der alternative <noscript> Aufwand in keinem Verhältnis. Wenn man glaubt den Suchmaschinen damit eine Alternative geben zu können, der irrt. Alle wirklich relevanten Suchmanschinen, bzw. Bots und dazu zähle ich maßgeblich Google und vielleicht noch Bing haben in eine JS Engine, die sich nur noch geringfügig von der Engine in einem Browser unterscheiden. Die können also alle JS und können deswegen auch die per JS geladen Bilder laden. Also wech damit!
III.) Jede Form von Inline Scripting inerhalb des <body></body>und dazu gehört auch <noscript> ist nicht nur seit Jahren verpöhnt, sondern widerspricht der im Shop integrierten Content Security Policy. Also noch ein Grund das <noscript> Gedöns zu entfernen. Nicht zuletzt bremst Inline Scripting das Rendern der Seite und führt zu unschönen Seiteneffekten v.a. bei mobilen Geräten in Kombination mit dem Bootstrap Framework.
Anmerkung: Wenn der Pagespeed Test das gar nicht beanstandet, dann schlichtweg deswegen, weil dieser Test dies und vieles mehr gar nicht berücksichtigt, geschweige denn entsprechende Routinen hat dies zu prüfen. Gleichermaßen berücksichtigt dieser Test auch nicht die Datenmenge.
IV.) Die Möglichkeiten durch die RD-Methode, bzw. Bootstrap sind wie bereits erwähnt sehr begrenzt. Um aber trotzdem was zu verbessern deswegen im ersten Schritt in jedem Fall dieses <noscript> Gedöns im ganzen Template bei allen Bildern entfernen. Kann nix, bringt nix!
IV a.) Die bei jedem Bild enthaltene "unveil" CSS Klasse entfernen und gegen "fade-in" austauschen.
IV b.) Bei jedem Bild das Laden dieses animierten "loading.gif" ebenso entfernen, bzw. wie folgt ändern:
src="{$tpl_path}css/images/loading.gif"} ersetzen mit src="data:image/png;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs"
IV c.) In der general_bottom.js.php das Laden des Scripts mittels DIR_TMPL_JS.'jquery.unveil.min.js', im array entfernen. Anstelle dessen eine neu JS Datei mit dem Namen der eigenen Wahl erstellen. In diese neue js Datei nachfolgendes reinkopieren. Nicht vergessen den Namen dieser neuen JS Datei in das array in der general_bottom.js.php einzutragen.
function init() {
var b = document.getElementsByTagName("img");
for (var a = 0; a < b.length; a++) {
if (b[a].getAttribute("data-src")) {
b[a].setAttribute("src", b[a].getAttribute("data-src"))
}
}
}
window.onload = init;
Der obige Schnipsel macht im Grunde genommen das Gleiche wie Deiner, ist allerdings universell einsetzbar, bzw. bezieht sich auf alle Bilder und eben nicht nur auf bestimmte Bilder.
IV c.) Damit die Bilder fürs Auge, bzw. das Anzeigeverhalten etwas schöner gestaltet wird, die folgende Klasse in die stylesheet.css egal wo reinkopieren. Dieser Schritt ist aber optional und ist nur kosmetischer Natur.
@-webkit-keyframes fadeIn {
from {
opacity: 0
}
to {
opacity: 1
}
}
@-moz-keyframes fadeIn {
from {
opacity: 0
}
to {
opacity: 1
}
}
@keyframes fadeIn {
from {
opacity: 0
}
to {
opacity: 1
}
}
fade-in {
opacity: 0;
-webkit-animation: fadeIn ease-in 1;
-moz-animation: fadeIn ease-in 1;
animation: fadeIn ease-in 1;
-webkit-animation-fill-mode: forwards;
-moz-animation-fill-mode: forwards;
animation-fill-mode: forwards;
-webkit-animation-duration: .25s;
-moz-animation-duration: .25s;
animation-duration: .25s
}
.fade-in {
-webkit-animation-delay: .25s;
-moz-animation-delay: .25s;
animation-delay: .25s
}
Conclusion.
****************
Alles in Allem ist auch mein Korrekturvorschlag nicht der Burner und ändert nichts Wesentliches, aber das ist dem Bootstrap Framework verschuldet. Um was Entscheidendes ändern und verbessern zu können, müsste man viel gravierendere Änderungen machen, die dann aber den kompletten Aufbau sämtlicher Scripte betreffen. Die mitgelieferten Templates wären dann aber nicht mehr zu gebrauchen, wenngleich das Maß der Verbesserung eklatant wäre. Dabei erlaube ich mir eine Kritik an die Entwickler des Shops zu richten. Obwohl sich mit der aktuellen Version die Gelegenheit angeboten hätte, hat man die Altlasten aus den Versionen vor 2.x auch in die aktuelle Version eingeschleppt. Wenn man auf Seiten PHP sehr gute Fortschritte gemacht hat und absolut lobenswert ist, scheint fast jegliches Verständnis zu fehlen, was in Sachen Template mit vergleichsweise geringem Aufwand man hätte um ein Vielfaches besser machen können. Der Nebeneffekt wäre gewesen, dass man bei der Selbsterstellung eines eigenen Templates nicht gezwungen wird die größtenteils massiven Fehler übernehmen zu müssen. So kommt es, dass die meisten am Markt angebotenen Templates sich nur optisch unterscheiden, aber der Code Aufbau und somit auch die Fehler immer noch vorhanden sind. Das betrifft dann auch die hier im Shop zum Download angebotenen Bootstrap Templates genauso wie auch die im Shop zum Verkauf angebotenen Templates.
