So ähnlich habe ich mir das auch fast gedacht!
Ich werde das mal gleich testen, aber erst mal etwas essen.
Danke Dir erstmal, ich werde berichten.
So ähnlich habe ich mir das auch fast gedacht!
Ich werde das mal gleich testen, aber erst mal etwas essen.
Danke Dir erstmal, ich werde berichten.
Gruß Thomas
"Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du." Mahatma Gandhi
Zumindest bekomme ich jetzt eine Reaktion!
Eine weiße Seite.
Mal weiter testen.
Gruß Thomas
"Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du." Mahatma Gandhi
Ein kleiner Hinweis: Dein Array nennst du $strReplace, an die Funktion übergibst du aber $arrReplace.
Gruß CeeKay
Ja danke, das habe ich vorhin auch gesehen und schon geändert!
Trotzdem wird die Seite garnicht erst mehr ausgegeben.
Gruß Thomas
"Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du." Mahatma Gandhi
Hi,
ich habe noch eine kleine Anleitung geschrieben, wie man die contao.css und das Inline-CSS auch noch in die zusammengefasste CSS-Dateien mit reinbekommt. Dadurch wird noch einmal ein Request eingespart und der Seitencode durch das fehlende Inline-CSS noch schlanker.
Alles Gute
Jan
Jan Theofel
Barcamp-Moderator für Corporate-Barcamps und öffentliche Barcamps
Hallo zusammen,
ich habe diese wunderbare Anleitung bei einem Projekt mit Contao 2.9.3 www.hochdruckliga.de umgesetzt und einen Wert von 99/100 erreicht.
Allerdings nur im Firebug beim Firefox. Page Speed im Chrome gibt mir stattdessen 88/100 an.
Könnt Ihr mir das erklären?
Gruß
PAndroid
Ich weiß ja nicht, aber ich bekomme einen Wert von 83 PS angezeigt!
YSlow gibt mir 89.
Gruß Thomas
"Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du." Mahatma Gandhi
Hallo Thomas,
danke, dass du die Seiten mal getestet hast.
Also YSlow gibt im Firefox auch 89 Punkte aus. Aber PageSpeed bleibt bei 99/100.
Ich verstehe das auch nicht. Wenn es bei Dir 83 Punkte anzeigt, habe ich wohl keinen Grund zur Freude. :-(
LG
PAndroid
Page Speed sagt mir bei deiner Seite sogar nur 56/100 Punkten an ("Keep-Alive aktivieren" und "
Bilder in CSS-Sprites kombinieren" bekommen einen roten Punkt).
Allerdings habe ich festgestellt, Google Page Speed ist sowieso nur mit Vorsicht zu genießen. Teilweise ändert sich die Bewertung mit jedem Klick (er konnte sich bei mir mal nicht zwischen 88 und 89 entscheiden, obwohl sich auf der Seite nichts geändert hat). Letztens hatte ich auch ein paar Tipps von dem Tool "bearbeitet" - auf einmal hatte ich weniger Punkte als vorher... Und seit dem Update auf Contao 2.10 bin ich auf 60 runter...
Geändert von SunBlack (13.09.2011 um 16:24 Uhr)
Hallo SunBlack,
danke für Dein Feedback.
Das wird ja immer besser... oder schlechter.
Habe heute morgen meine Seite nochmal durch Page Speed prüfen lassen:
Firefox: 99/100 (unverändert) GPS 1.12 in Firebug 1.8.2
Chrome: 98/100 (war 88/100) GPS 1.12.01
Rote Punkte habe ich gar nicht...
Irgendwie beschleicht mich das Gefühl, dass ich hier irgendetwas nicht richtig gemacht habe oder Google Page Speed nicht zuverlässig arbeitet.
Welche Version des Plugins benutzt Du denn? In welchem Browser hast Du die Werte gemessen?
Also ich habe in Chrome/Mac GPS 1.12.0.1 88/100 und in Firefox/Mac GPS 1.12 87/100. Das kann schon passen. Es gibt ja auch noch einiges zu tun ;-)
Viele Grüße
Mario
Nicht das Du denkst, wir würden Dich veralbern!
Hier kannst Du Online schauen: http://pagespeed.googlelabs.com/#url...F&mobile=false
Im Anhang ist ein Screenshot unter FF6 mit PG 1.12!
Man könnte annehmen, dass PG unter FF nicht richtig funktioniert!
Ich habe eine meiner Seiten sowohl mit PG Online als auch unter FF gemessen und es gab beide Male einen Wert von 92 (ohne komprimiertes und optimiertes JAVA & CSS).
Da stellt sich dann die Frage, warum gibt es bei Dir diese Abweichungen?
Gruß Thomas
"Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du." Mahatma Gandhi
Kann ich Dir schicken, aber per PM!
Die Seite ist noch nicht offiziell.
Gruß Thomas
"Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du." Mahatma Gandhi
Hallo Thomas,
danke für den Link Deiner Seite.
Im Chrome bekomme ich dafür eine 91/100 Punkte.
Im Firefox 97/100 Punkte.
Scheinbar bewertet mein Firefox Plugin auch Deine Seite etwas besser als bei Dir.
Wird mir wohl nix anderes bleiben, als auf das Online-Tool zurückzugreifen und hoffen, dass das "sauber" arbeitet.
Wie SunBLack jedoch auf diese echt miserablen Werte kommt, ist mir absolut schleierhaft.
LG
PAndroid
Keine Ahnung. Ich habe auch FB 1.8.2 und GPS 1.12
Screenshot siehe Anhang...
Interessanterweise verhält es sich bei meiner Website anders: da gibt mir das online-Tool weniger Punkte, als das FB-Plugin...
Ich komme ohne Optimierung auf 85/100 - mit Optimierung auf 76/100
Andere Ergebnisse von FB-Plugin und Webseite.
Fazit: Egal.
Haha, mir geht es genauso!
Ich habe mich da nochmal drauf gestürzt und drei Subdomains eingerichtet, die die Auslieferung der statischen Inhalte übernhemen sollten.
Die Umschreibung funktionierte jetzt auch, allerdings waren die Werte von 91 - 92 auf 67 zurück gegangen. Page Speed meckerte dann schön über zuviele Umleitungen. Auch YSlow gab wesentlich schlechtere Werte aus., demnach habe ich das erstmal wieder entfernt.
In meinen Augen, zumindest unter 2.9.5 völlig überbewertet.
Ein nächster Test wird mit 2.10.x folgen, die passende Seite wird nach einem Mittagsschläfchen *hust* aufgesetzt.
Gruß Thomas
"Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du." Mahatma Gandhi
Größte Problem seh ich mit den imageslider und Slideshow2, da spinnt der Firefox, und läd kein mootools mehr rein
Geladen wird es, aber in keinem Browser ausgeführt.
Ich habe das Problem gerade aktuell.
Auf ein und dem selben Server läuft eine Installation mit 2.9.5 und 2.10.2. Unter 2.10.2 werden die Scripte ordnungsgemäß eingebunden aber in keinem Browser zur Ausführung gebracht. 2.9.5 funktioniert weiterhin tadellos. Ich habe unter 2.10.2 auch den Imageslider im Einsatz.
Ich komme heute nicht zum Testen oder erst spät, vielleicht schaut da ja noch Jemand drüber.
Ich denke aber, dass es ein neues Thema wert ist, da es indirekt mit der Optimierung zutun hat.
Gruß Thomas
"Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du." Mahatma Gandhi
Ja also in 2.9.5 meine ich dann zusätzlich mit der moopage Erweiterung, wodurch man dann auch 3 subdomains eintragen kann, dann gehts wie gesagt nur im Firefox bei mir nicht... komich. Und da man fast immer imageslider einbaut (ich zumindest) fällt die Funktion leider weg... bzw. geht zumindest 1 Subdomain: Datei-URL
Die anderen hab ich frei gelassen...
Hmmm, ich weiß nicht!
Habe gerade nochmal alle statischen entfernt (2.10.2), Javascript wird dennoch in den Browsern nicht ausgeführt!
Da muss noch etwas anderes verbogen sein.
Gruß Thomas
"Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du." Mahatma Gandhi
http://mentaltrainer.dyndns.org/
geht der slider da bei Dir? 10.0.1 und nur "Datei-URL" habe ich eine Subdomain drin.
Ja, da funktioniert er!
Ich setze die Seite nochmal neu auf, vielleicht ist bei der Übertragung des Backups nicht alles vernünftig rüber gekommen.
Gruß Thomas
"Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du." Mahatma Gandhi
Es hat nicht an der Seite gelegen, auch nicht an den Browsern.
Scheinbar gibt es ein Problem bei der Nutzung von xhtml.
Ich habe die Seite auf html5 umgestellt und alles funktionierte.
Leider bin ich noch zu faul, alles auf html5 umzustellen, demnach erstmal nach einer anderen Lösung suchen.
Gruß Thomas
"Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du." Mahatma Gandhi
Ich habe den Fehler nun gefunden!
Die Erweiterungen wurden nach dem Einspielen des Backups als aktuell angezeigt, waren es aber keineswegs.
Ich habe einfach mal alle Erweiterungen aktuallisiert und jetzt funktioniert es bestens.
Komisch ist das dennoch.
Gruß Thomas
"Zuerst ignorieren sie dich, dann lachen sie über dich, dann bekämpfen sie dich und dann gewinnst du." Mahatma Gandhi
1. Beim ersten Aufruf zeigt er bei meiner Seite http://www.nacktrodeln.org/ 84/100 und gibt mir bei Keep Alive 0/100
Wenn ich die Seite neulade oder eine Sub-URL anklicke, kreidet er mir das nicht mehr an und schreibt 95/100 - Ist das normal?
2. Javascript später parsen - Kann man das mit Contao umsetzen?
3. Gibt es keine einfachere Lösung für das "Problem" mit system/contao.css? Das ist ja ultra komplex http://www.contao-anleitungen.de/pos...ptimieren.html
Bei Holygrail gibt es an allen Ecken und Enden Probleme, die auftreten können... Für bereits bestehende Websites ist es überhaupt nicht zu empfehlen.
Und der Geschwindigkeitsvorteil ist nicht existent, die Werte beim Google Page Speed waren bei mir trotzdem bei 95, es gab keine Steigerung
Du willst dich bei mir bedanken?
Ich freue mich über Geschenke von meiner Amazon-Wunschliste.
Contao-Anwender seit 2008
Contao-Entwickler seit 2013, mehr als 50 Contao Erweiterungen programmiert
Mein Unternehmen aus Blankenburg (Harz): Fast & Media
http://dev.contao.org/issues/3609
Naja, ist eben eine CSS-Frage ob das Probleme gibt oder nicht :-D
Hi,
wo schalte ich die GZIP Komprimierung ein? bei 2.9.5 projekten funkt das.
Bei 2.10.1 steht dort "Skripte komprimieren", das habe ich auch gewählt, doch nix passiert. Muss man noch was irgendwo/irgendwie ändern (htaccess) ??
Danke
Daniel
Skripte werden standardmäßig "on-the-fly" mittels Deflate komprimiert. Wenn Du Gzip-komprimierte Dateien ausliefern möchtest, musst Du in der ".htaccess" den auskommentierten Abschnitt aktivieren:
Code:## # If you cannot use mod_deflate, uncomment the following lines to load a # compressed .gz version of the bigger Contao JavaScript and CSS files. ## #AddEncoding gzip .gz #<FilesMatch "\.js\.gz$"> # AddType "text/javascript" .gz #</FilesMatch> #<FilesMatch "\.css\.gz$"> # AddType "text/css" .gz #</FilesMatch> #RewriteCond %{HTTP:Accept-encoding} gzip #RewriteCond %{REQUEST_FILENAME} \.(js|css)$ #RewriteCond %{REQUEST_FILENAME}.gz -f #RewriteRule ^(.*)$ $1.gz [QSA,L]
Hi,
ok aber mein Server unterstützt das, so stehts zumindest in der info.php
Geändert von xkoy (07.12.2011 um 11:58 Uhr)
Dann ist ja alles bestens.
Ja eben nicht. Pagespeed meckert und http://www.gidnetwork.com/tools/gzip-test.php
Dort der test geht auch schief: www.mentales.at
Und wenn Du die Skripte als GZip-komprimierte Dateien auslieferst?
An und für sich sehe ich aber keinen Grund, wieso das nicht auch mit Deflate funktionieren sollte, wenn - wie Du ja sagst - das serverseitig unterstützt wird.
Irgendwie komm ich da nicht mehr mit.
Also: Ich lasse die standard htaccess so wie Sie ist, da ist es "deaktiviert". Dann wirds quasie "on the fly" von Contao komprimiert?
Wenn ich es "aktiviere" übernimmt der Server die gzip Kompression?
Aber beides funktioniert nicht. Pagespeed meckert bei beidem. Und der GZIP test gibt auch ein "NO" aus.
Kanns dann nur am Server liegen?
Weil ich eine 2.9.5 install habe dort geht die gzip Komprimierung.
Ich habe mal versucht, eine Homepage in Richtung CSS-Sprites zu optimieren (NABU Heidelberg), genauer gesagt, lasse ich mit Hilfe von jQuery alle Vordergrund-Bilder (img) auf der aktuell zu ladenden Seite, die ein bestimmtes Kriterium erfüllen, automatisch durch CSS-Sprites, also durch Hintergrundbilder zu ersetzen. Bei (Maus-)Hover oder beim Durch-Tabben (Fokuswechsel) werden die Bilder später entsprechend gewechselt, zum Beispiel durch eine "hellere" Bild-Version.
Falls Interesse der genau(er)en Lösung besteht, kann ich das gerne weiter ausführen (.js und .css-Code, Tutorial bzw. das ins Contao Wiki auslagern oder so...). Hier schon einmal einige Details zu Randbedingungen/Umsetzung/Implementierung:
- Es spielt keine Rolle, in welchem Kontext das zu ersetzende Bild auftaucht (also ob als/im Inhaltselement, Modul, Nachricht, Event, Gallery usw....). Es kann also wie gewohnt ("redaktionell") im Backend irgendwo ausgewählt und eingefügt werden.
- Alle diese Bilddateien müssen bereits sowohl den/einen normalen (oben bzw. center top) als auch den :hover bzw. :focus-Zustand (unten bzw. center bottom) beinhalten, sind also bereits die gewünschten Sprites-Bilddateien (also doppelte Höhe).
- Alle Vordergrundbilder, die automatisch durch Sprites ersetzt werden sollen, unterliegen der Konvention, dass sie mit -sprite vor dem letzten Punkt im Dateinamen enden müssen (also etwa ...-sprite.jpg bzw. ...-sprite.png usw...).
- Bei $(document).ready verpasse ich (mit Hilfe von jQuery) allen diesen Tags bzw. DOM-Knoten die Klasse '...-sprite' (addClass). Die Bilder werden zunächst versteckt.
- Später, erst bei $(window).load werden (per jQuery) alle Tags mit Klasse '...-sprite' mit dem entsprechenden Hintergrundbild (background-image) ersetzt (replaceWith). Bei ready wäre es zu früh, wie Tests per UTMS-Internet-Zugang oder mit mobilen Endgeräten gezeigt haben.
Sowohl bei :hover als auch bei :focus werden die Bilder gehighlightet bzw. das Hintergrundbild entsprechend verschoben. Das mit dem Fokus geht auch im IE(7/8), da ich die <img>- bzw. <a><img>-Tags durch <a>-Tags und nicht etwa durch <div>-Tags ersetze.
vg refalo
Geändert von refalo (02.01.2012 um 19:52 Uhr)
hi, ganz doofe Frage von mir, warum mit jquery? geht doch alles mit Background-position, wie hier www.mentales.at
oder hab ich was verpasst?
Ja genau, wenn es (bereits) Hintergrundbilder sind.
Wenn ich aber ganz "stinknormal", quasi als Redakteur im Backend z.B. Bilder intuitiv als Inhaltselement oder so einfüge, dann ja als Vordergrundbild (<img>), also nicht von Haus aus als CSS-Sprite.
habe das gleiche Problem wie xkoy
er meckert für 4 Dateien an, bitte mit gzip komprimieren...
Die Komprimierung der folgenden Ressourcen mit gzip könnte ihre Übertragungsgröße um 67,5 KiB verringern (Reduzierung um 69 %).
Durch die Komprimierung von http://st3.xyz-xyz.de/.../mootools-more.js könnten Sie 56,5 KiB einsparen (Reduzierung um 70 %).
Durch die Komprimierung von http://www.xyz-xyz.de/ könnten Sie 8,6 KiB einsparen (Reduzierung um 68 %).
Durch die Komprimierung von http://st2.xyz-xyz.de/.../MooMenu.js könnten Sie 2,1 KiB einsparen (Reduzierung um 66 %).
Durch die Komprimierung von http://st2.xyz-xyz.de/system/contao.css könnten Sie 347 B einsparen (Reduzierung um 45 %).
komischerweise habe ich in der htaccess mod_defalte aktiv und auch Gzip ist aktiviert wie beschrieben ...
im backend habe ich Gzip Standartkomprimierung eingestellt.
Die seite liegt bei strato und, da sollte mod_deflate verfügbar sein ... in der info.php steht zumindest: HTTP_ACCEPT_ENCODING gzip, deflate
habe ich irgendwas vergessen, oder ist das normal das er das nicht komprimieren kann?
Hi,
also bei mir funkt das jetzt immer, mit standard contao htaccess.
check mal hier: http://www.gidnetwork.com/tools/gzip-test.php
ob wirklich das vom Server aktiviert ist. Daran lags nämlich bei mir..
Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
Lesezeichen