Du bist nicht angemeldet. Der Zugriff auf einige Boards wurde daher deaktiviert.

#1 19. Januar 2011 20:24

piratos
Gast

[GELÖST] 1 Request Web's im Standard möglich

Mit der kommenden Version von Pcms sind grundsätzlich dynamische Web's mit einem einzigen Request möglich.

Das sind Techniken, die man auch bei CMS/ms einsetzen könnte, wenn die Herrschaften sich mal rühren würden.

Habe ich bei mir bereits im Einsatz (Startseite):

http://www.webpagetest.org/result/110119_A0_JAF/

#2 19. Januar 2011 22:12

nhaack
Server-Pate
Ort: Bonn
Registriert: 12. Dezember 2010
Beiträge: 171
Webseite

Re: [GELÖST] 1 Request Web's im Standard möglich

Interessanter Ansatz. Man vermeidet durch das Data URI Schema für Grafiken die entsprechenden Header. Wenn die Einbettung automatisiert ist, ist das echt ganz cool. Hab' ich bis jetzt sehr selten gesehen. Schönes Fallbeispiel.

Der einzige Nachteil der mir jetzt spontan einfällt wäre, dass das Caching von Grafiken dadurch nicht möglich ist. Wobei das erst mit dem Ansehen von mehreren Seiten mit gleichen Grafiken relevant werden würde.

Nette Idee.

Offline

#3 19. Januar 2011 22:45

piratos
Gast

Re: [GELÖST] 1 Request Web's im Standard möglich

Es wird automatisch umgesetzt und dazu auch noch Browserabhängig, d.h. IE7 und solche Krücken bekommen Normales vorgesetzt.

Caching wird eingesetzt.

Die in base64 codierten Images werden gecacht, entweder in File oder wenn vorhanden mittels memcache (Pcms unterstützt im Standard Memcache auch wenn das nur High End Anwender in der Praxis nutzen) - d.h. einmal codieren und wieder verwenden. im Wiederholfall wird lediglich das gecachte File eingebunden, das dauert weniger als 1 ms.

Mit Google Chrome liegt übrigens die Seitengeschwindigkeit ab zweitem Besuch der Seite bei unter 170 ms - das mal nur am Rande.

Hat Vorteile.

Beitrag geändert von piratos (19. Januar 2011 22:52)

#4 20. Januar 2011 23:45

piratos
Gast

Re: [GELÖST] 1 Request Web's im Standard möglich

nhaack schrieb:

Hab' ich bis jetzt sehr selten gesehen. Schönes Fallbeispiel.

Noch ein Wort dazu -  ich bin ja schon etwas länger dabei Pagespeed  programmtechnisch zu unterstützen.
Die Pagespeedentwickler haben das vor einiger Zeit bei mir gesehen und das in den Katalog für Pagespeed ab 2.X aufgenommen.
Ab 2.X weil die dann voraussichtlich existierenden Browser damit Null Probleme haben werden.

Beitrag geändert von piratos (20. Januar 2011 23:50)

#5 20. Januar 2011 00:27

nhaack
Server-Pate
Ort: Bonn
Registriert: 12. Dezember 2010
Beiträge: 171
Webseite

Re: [GELÖST] 1 Request Web's im Standard möglich

Very Nice (das Serverseitige). Mit Caching meinte ich jedoch Caching der Bilder im Browser. Die sind doch fest in jede einzelne Seite eingebunden und die muss der Client ganz runterladen ... oder versteh ich da was falsch?

Funktioniert das eigentlich auch in CSS? Dann könnte man die Grafiken als base64 codiert doch in der CSS Datei vorhalten. Dann habe ich zwar einen zusätzlichen Request am Anfang (1 Request Ziel nicht ganz erreicht), halte die Grafiken jedoch in einem zentralen und client-gecachtem Objekt für alle Seiten vor. Bei vorhandenen mehrseitigen Sessions würde man hier doch auf Dauer insgesamt weniger Daten als bei der 1 Request Variante versenden, oder? Man nutzt die Request-Vermeidung zumindest weitestgehend und kreuzt sie mit Volumenvermeidung ... setzt aber voraus, dass das auch geht ...

[== php ==]

base64_encode($bild)

... mit ein wenig Caching-Mechanic drum herum oder?

Grüße
Nils

Offline

#6 20. Januar 2011 01:31

dc2
arbeitet mit CMS/ms
Registriert: 26. November 2010
Beiträge: 140
Webseite

Re: [GELÖST] 1 Request Web's im Standard möglich

Ja, das kann man auch direkt im CSS nutzen, etwa so:
background-image: url(data:image/png;base64,Bilddaten);

Und da CSS zwischengespeichert wird und im Prinzip für jede Seite gleich ist (es sei denn, es wird seitenspezifisches CSS genutzt), gibt es da im Prinzip auch keinen Nachteil gegenüber dem Einbinden als externe Datei.

Offline

#7 20. Januar 2011 11:37

piratos
Gast

Re: [GELÖST] 1 Request Web's im Standard möglich

Zum Imagecachiing - Nein, die Seite wird komplett geladen.
Das eingesetzte Caching für bereits base64 Images ist sinnvoll, da man sich damit den erneuten Aufwand des codierens einspart - der Verwaltungsaufwand dafür ist niedriger als eine jeweils neue Aufbereitung.

Das normale Browsercaching aber ist unterm Strich völlig uninteressant, da Request's-Zeiten  und Abprüfzeiten Cache ja oder nein erheblich höher liegen als der Transferaufwand.

Request-Zeiten sind zudem relativ stabil, kommt also jemand mit High-Speed daher oder nicht, verlieren alle ca. die gleichen Zeiten.
Wenn man also als Rechenbeispiel davon ausgeht das 0,02 Sekunden pro Request auftreten mal 30 Request's dann liegen wir bei 0,6 Sekunden.
Habe ich ein 8 Mbit Leitung kann ich in der Zeit locker 500..600 KB durch die Leitung drücken.
Bei meiner persönlichen High-Speed Anbindung locker sogar über 3,3 MB netto.
Und das alles geht bei dieser Technik in einem Rutsch, da wird so richtig gesaugt.

Im Klartext - man belohnt Leute mit einer schnellen Anbindung mit jeweils einem noch schnelleren Empfang der Seite.

Nehmen wir mal die besagte Startseite - die hat rund 40,6 KB mit allem, davon wird wegen gz Nutzung nur noch 21,8 KB durch die Leitung gedrückt , das sind nur rund 54% der Gesamtmenge.

Die base64 codierten Images liegen ja als Text vor und auch der wird enorm komprimiert.

Die einzigen Hemmnisse sind die Browser der Klasse Internet Explorer.
IE bis Version 7 können da rein nichts, IE 8 ist auf 32 KB pro Image beschränkt, Rest wird abgeschnippelt, IE9 hat keine Probleme ebenso wie alle anderen einigermaßen aktuellen Browser.

Man muss also abprüfen was für einen Eumel man da hat und dem entweder Normalkost anbieten oder die Fast Food Version - das aber ist kein Problem, läuft automatisch.

Die Auswirkungen kann man übrigens ganz toll erkennen, wenn man mal eine Seite im ohne base64, im Mischbetrieb und voll base64 laufen lässt - je mehr base64 desto schneller.

Base64 setzen wir schon länger ein, was neu ist ist der Einsatz der CSS als Inline CSS - das hat den letzten Request und Schub gebracht.
Da die CSS unverändert bearbeitet werden kann (wie bei CMSMS auch)  hat man keine Nachteile sondern nur Vorteile.

Man kann sich mit dieser Technik auch helfen, wenn man bestimmte Dinge auf dem Zielserver nicht machen kann und somit einen schlechten Wert im Pagespeed  einhandelt und real tatsächlich langsam ist.

#8 20. Januar 2011 18:05

piratos
Gast

Re: [GELÖST] 1 Request Web's im Standard möglich

So sieht es übrigens aus, wenn man den Test mit 20 Mbit macht.

Da wird ganz klar der schnelle Platzhirsch bevorzugt, der über normale Anzahl von Request's in's stottern kommt und nun die Strecke per Bleifuss durchfahren kann:

http://www.webpagetest.org/result/110120_SQ_QE0/

Die Wirkung ist natürlich für Leute mit solcher Anbindung verblüffend  - zack und bumm.

Macht mal sich ein Dummyweb mit 10 Seiten immer den gleichen Lorem in die Ohren Text bemerkt man den Wechsel nur noch, weil sich der Hintergrund der Navigationsleiste wegen der geänderten aktuellen Seite ändert - anonsten zuckt sich da nichts.

#9 22. Januar 2011 12:44

piratos
Gast

Re: [GELÖST] 1 Request Web's im Standard möglich

Hier noch kurz auf das Thema Caching von Images eingehend.

Caching nutzt etwas wenn man die 1 Request Technik nicht verfolgt oder verfolgen kann.

Caching hat aber keine Chancen gegenüber der 1 Request Technik.

Bei nachfolgendem Test hat die Seite  immer einen Pagespeed 100/100, was aber auch rein nichts aussagt über die tatsächliche Leistung.

Uri-data wird in abhängig von den Broswerfähigkeiten geschaltet und zwar automatisch.

Hier mal die Wirkung  der automatischen Umschaltung von  uri-data  in html und in der inline css.

1.  http://www.webpagetest.org/result/110122_EF_10Q1/

Hier wir der IE 7 angesprochen der nichts mit URI Data am Hut hat.

2. http://www.webpagetest.org/result/110122_JP_10QC/

Hier wir der IE 8 angesprochen, der uri-data kann, allerdings nur bis 32 KB pro uri-data Image, deshalb haben wir hier einen automatischen Mischbetrieb vorliegen, der aber auch enorm etwas bringt.

Da der IE 9 in den Startlöchern steht  und der keine Begrenzung von 32 KB hat hier mal eine Zeitaufnahme mit dem IE 9 Preview 7 der allerdings bei webpagtest.org nur in Dulles VA USA möglich ist, deswegen sind die resultierende Zeiten höher.

http://www.webpagetest.org/result/110122_H5_10SV/

#10 23. Januar 2011 00:33

piratos
Gast

Re: [GELÖST] 1 Request Web's im Standard möglich

Das sagen übrigens die Google Entwickler dazu :

http://groups.google.com/group/page-spe … 345c994041

#11 23. Januar 2011 14:50

nhaack
Server-Pate
Ort: Bonn
Registriert: 12. Dezember 2010
Beiträge: 171
Webseite

Re: [GELÖST] 1 Request Web's im Standard möglich

also ich bin auf jeden Fall neugierig geworden. Ich hab da sogar einen Fall, wo ich mir die Technik sehr gut vorstellen kann. Das wäre eine "Liste" mit vielen kleinen PNG Icons (zwischen 500 und 3.000 Byte pro Icon, bis zu 100-200 Icons). Da zwackt der Seitenaufbau nämlich genau an der begrenzten Anzahl an parallelen Requests.

Ich hab überlegt da wie folgt ranzugehen, da würd' ich gerne mal euer Feedback hören.

1) Im Seitentemplate Dateinamen/Pfad des Bildes an Smarty Plugin übergeben.
2) Plugin prüft User-Agent
3) Wenn Unterstützung vorhanden, bild codieren und einbetten (entweder auf cache zugreifen und von dort nehmen oder neu erzeugen).
4) Ansonsten Bildpfad ausgeben (on error, nicht eindeutig kompatibel etc pp)

Grüße
Nils

Offline

#12 23. Januar 2011 17:00

piratos
Gast

Re: [GELÖST] 1 Request Web's im Standard möglich

So läuft das im Prinzip.
Ich erzeuge jedoch grundsätzlich immer ein base64 (wenn es nicht im Cache-Verzeichnis vorliegt)  und lege das im Cache-Verzeichnis ab.
Bei einem IE Browser kann nur ab 8 aufwärts base64 verwendet werden.
IE 8  darf die base64 nur 32 KB groß sein.
IE9 frisst das komplett.

Also Abfrage ob IE 8, wenn ja und base64 > 32000 Bytes dann base64=false und danach base64 abfragen und entweder ausgeben oder normalen images - link.

Man muss darauf achten das die Fähigkeiten anderer Browsertypen älterer Bauart entweder voll da sind oder nicht.

#13 23. Januar 2011 18:45

nockenfell
Moderator
Ort: Lenzburg, Schweiz
Registriert: 09. November 2010
Beiträge: 2.807
Webseite

Re: [GELÖST] 1 Request Web's im Standard möglich

nhaack schrieb:

also ich bin auf jeden Fall neugierig geworden. Ich hab da sogar einen Fall, wo ich mir die Technik sehr gut vorstellen kann. Das wäre eine "Liste" mit vielen kleinen PNG Icons (zwischen 500 und 3.000 Byte pro Icon, bis zu 100-200 Icons). Da zwackt der Seitenaufbau nämlich genau an der begrenzten Anzahl an parallelen Requests.

Da könntest du allerdings auch ein Sprite draus machen. Damit könntest du auch einige Requests sparen.


[dieser Beitrag wurde mit 100% recycled bits geschrieben]
Mein Blog  /   Diverse Links rund um CMS Made Simple
Module: btAdminer, ToolBox

Offline

#14 23. Januar 2011 19:44

cyberman
Moderator
Ort: Dohna / Sachsen
Registriert: 13. September 2010
Beiträge: 6.878
Webseite

Re: [GELÖST] 1 Request Web's im Standard möglich

nhaack schrieb:

2) Plugin prüft User-Agent

http://www.cmsmadesimple.de/forum/viewt … d=278#p278

wink


1. Wie bekomme ich hier schnelle Hilfe?
2. HowTo: Fehlersuche bei CMS/ms
---
„First they ignore you, then they laugh at you, then they fight you, then you win.“ Mahatma Ghandi

Offline

#15 23. Januar 2011 20:10

NaN
Moderator
Ort: Halle (Saale)
Registriert: 09. November 2010
Beiträge: 4.137

Re: [GELÖST] 1 Request Web's im Standard möglich

nockenfell schrieb:

Da könntest du allerdings auch ein Sprite draus machen. Damit könntest du auch einige Requests sparen.

Naja, aber die eine Anfrage für das Sprite bleibt.
Und durch base64 könnte man sogar diese noch einsparen.

Und was ist, wenn es automatisch generierte Thumbnails aus einer Bildergalerie sind?
Dann müsste man jedesmal, wenn man eine neue Datei hochgeladen hat, ein neues Sprite erstellen.

Offline

#16 23. Januar 2011 20:16

cyberman
Moderator
Ort: Dohna / Sachsen
Registriert: 13. September 2010
Beiträge: 6.878
Webseite

Re: [GELÖST] 1 Request Web's im Standard möglich

Wenn du es cachest, dann aber auch nur einmal ... oder die Thumbnail-Erzeugung so umschreiben, dass das base64-"Bild" / Datei gleich mit erzeugt wird.


1. Wie bekomme ich hier schnelle Hilfe?
2. HowTo: Fehlersuche bei CMS/ms
---
„First they ignore you, then they laugh at you, then they fight you, then you win.“ Mahatma Ghandi

Offline

#17 23. Januar 2011 22:03

nockenfell
Moderator
Ort: Lenzburg, Schweiz
Registriert: 09. November 2010
Beiträge: 2.807
Webseite

Re: [GELÖST] 1 Request Web's im Standard möglich

NaN schrieb:
nockenfell schrieb:

Da könntest du allerdings auch ein Sprite draus machen. Damit könntest du auch einige Requests sparen.

Naja, aber die eine Anfrage für das Sprite bleibt.
Und durch base64 könnte man sogar diese noch einsparen.

Und was ist, wenn es automatisch generierte Thumbnails aus einer Bildergalerie sind?
Dann müsste man jedesmal, wenn man eine neue Datei hochgeladen hat, ein neues Sprite erstellen.

Klar sollte das Sprite danach auch base64 codiert werden. Da nhaak von Icons geschrieben hatte, nehme ich an, dass diese mehr oder weniger statisch sind. Für Thumbnails (welche normalerweise nicht PNGs sind) ist die Sprite Technik nicht interessant. Mal überlegen und testen ob dies auch mit einem Prefilter umsetzbar ist.


[dieser Beitrag wurde mit 100% recycled bits geschrieben]
Mein Blog  /   Diverse Links rund um CMS Made Simple
Module: btAdminer, ToolBox

Offline

#18 24. Januar 2011 10:29

piratos
Gast

Re: [GELÖST] 1 Request Web's im Standard möglich

Sprites sind nur dann interessant wenn nur eine kleine Anzahl von Komponenten enthalten sind, ansonsten benötigen Browser mehr Zeit diese zu verarbeiten als der Gewinn dadurch wäre.

Ich verwende aus dem Grunde überhaupt keine Sprites mehr.

#19 24. Januar 2011 12:16

nockenfell
Moderator
Ort: Lenzburg, Schweiz
Registriert: 09. November 2010
Beiträge: 2.807
Webseite

Re: [GELÖST] 1 Request Web's im Standard möglich

piratos schrieb:

Sprites sind nur dann interessant wenn nur eine kleine Anzahl von Komponenten enthalten sind, ansonsten benötigen Browser mehr Zeit diese zu verarbeiten als der Gewinn dadurch wäre.

Ich verwende aus dem Grunde überhaupt keine Sprites mehr.

Aha. Rekapituliere ich: Ich habe z.B. eine Seite mit einer Dateiauflistung und vor jeder Datei ein Icon. Sagen wir mal 20 verschiedene Dateien/Icons. Hier ist es dennoch besser einzelne Dateien statt einem Sprite zu verwenden?


[dieser Beitrag wurde mit 100% recycled bits geschrieben]
Mein Blog  /   Diverse Links rund um CMS Made Simple
Module: btAdminer, ToolBox

Offline

#20 24. Januar 2011 12:33

NaN
Moderator
Ort: Halle (Saale)
Registriert: 09. November 2010
Beiträge: 4.137

Re: [GELÖST] 1 Request Web's im Standard möglich

So wie ich das verstanden habe kommt es darauf an, wie die Icons den Weg ins HTML Dokument finden.
Sind sie via Sprite im CSS oder als IMG Tags mit einer URL verlinkt, dann hat man eben diesen einen Request, der das Sprite laden soll.

Sind die Icons aber Base64 kodiert im CSS oder IMG Tag eingebettet, dann fällt der Request weg.
Ein Sprite macht hier dann meiner Meinung nach auch keinen Sinn mehr, weil das komplette Bild im CSS oder im IMG Tag enthalten ist. D.h. bei einem Sprite hättest Du ein riesen Bild für jedes Icon eingebettet, wovon Du aber nur einen kleinen Ausschnitt zeigts. Die Datenmenge wäre dann Exponentiell größer, als wenn Du einzelne kleine Base64 kodierte einbetten würdest.

Du hast für diese Icons dann garkeine Anfragen an den Server mehr. Und darum geht es doch hier: Einen Request, um die Seite anzufordern und das war's. Keine src oder url Attribute, die irgendwohin verlinken und damit weitere Requests verursachen.

Im Prinzip könnte man alles direkt ins HTML Dokument packen (CSS, Javascripts, Bilder ...). Die Datenmenge, die insgesamt übertragen wird, ist die gleiche, als wenn alles extern ausgelagert wird.

Der Brosercache spielt laut Piratos nur eine kleine Rolle. Bei DSL Breitbandanbindung ist die Seite mit einem einzelnen Request insgesamt schneller geladen als wenn der Browser erstmal gucken muss, ob denn evtl. irgendwas gecached wurde. Denn selbst wenn etwas gecached wurde, der Request an den Server bleibt. Denn der Browser lädt Dinge erst aus dem Cache, wenn er vom Server die Antwort bekommt, dass die Ressource nicht verändert wurde. Der Browser Cache dient also nur dazu, um die zu übertragende Datenmenge gering zu halten, nicht aber dazu, um Requests einzusparen.

Offline

#21 24. Januar 2011 13:23

piratos
Gast

Re: [GELÖST] 1 Request Web's im Standard möglich

nockenfell schrieb:

Aha. Rekapituliere ich: Ich habe z.B. eine Seite mit einer Dateiauflistung und vor jeder Datei ein Icon. Sagen wir mal 20 verschiedene Dateien/Icons. Hier ist es dennoch besser einzelne Dateien statt einem Sprite zu verwenden?

Ideal für Uri - Data.

Sprites kann man normal nur als Backgroundimage einsetzen - Problem Nummer 1.

Und - das Hauptproblem - die Browser benötigen was die Positionierung und Auswahl über CSS betrifft eine abnorme Zeit - bei vielen Einheiten kann das derart extrem werden, das sogar normal (also  ohne Uri) , aber gecacht (Browser) die Sache noch erheblich schneller wird trotz der Request's.

#22 24. Januar 2011 21:37

nhaack
Server-Pate
Ort: Bonn
Registriert: 12. Dezember 2010
Beiträge: 171
Webseite

Re: [GELÖST] 1 Request Web's im Standard möglich

Den Fall kann man als Directory-Listing mit Fileicons ganz gut übersetzen. Also ich kenne z.B. 250 verschiedene Icons. Pro Seite brauche ich aber nur eine bestimmte Auswahl an Icons (zwischen 1 und 250 verschiedenen Icons, vom Seitentyp können aber alle 250 Icons irgendwie auftauchen ... Nun kann das gleiche Icons aber öfters pro Seite auftauchen. Weil z.B. in dem Directory 20 XLS Dateien liegen (+10 DOC + 5 JPG etc pp) ... je nachdem, was halt drin ist. Ich weiß aber im Script, welche und wieviele das jeweils sind.

Jetzt leuchtet mir ein, dass es wenig Sinn macht, die Icons jeweils am Einsatzort als base64 einzubetten. Dann bette ich das gleiche Icon ja 20 mal ein ... das ist ja auch nicht Ziel der Übung. Oder fällt das bei Komprimierung nicht so ins Gewicht, weil der String identisch ist und geschickt in der Compression "verschwindet" ... kann das jemand beantworten? Dann könnte man quasi "rumsauen".

Bliebe sonst als Altenative, das über CSS zu machen. Und da entweder über Sprites (ein 40kilopixel Icon), Inline im head (base64) oder eigene CSS Datei mit kodierten Bildern. Für ersteres wurde gerade das Performance-Argument Browser Rendering angeführt (hab ich das richtig verstanden?).

Dann bliebe noch 250 Klassen mit den Icons zu erstellen (ich würde das einfach einmal vorab machen, da ändert sich ja so schnell nix) und die Icons entweder in einem einzigen eigenem CSS (da würd ich dann alle reinpacken) speichern oder jeweils das benötigte CSS im Quelltext der Seite (wobei das auch 250 werden können).

Das ganze ist ein privates Spassprojekt wo's um nix geht. Ich aber gerne rausholen möchte, was mit vertretbarem Aufwand (neben den anderen 100 Baustellen an der Site) machbar ist. Externes CSS hört sich da so "Plug-and-Play" an big_smile.

Ich vermute, das Optimum ist erreicht, wenn ich die Icons selektiv als CSS einbette, ich scheu' aber zugegeben doch ein wenig den Aufwand des zusätzliche Prüfens, welche Icons ich einbetten muss. Die Frage hierzu: gibt es bei der Variante externes CSS einen gravierenden Nachteil, den ich ggü. dem selektiven Einbetten übersehe (abgesehen von dem extra Request) .... obwohl ... je länger ich drüber nachdenke ... so wild kann das selektive Einbetten garnicht sein ...

... dann würd's doch Sinn machen, wenn ich die base64 Inhalte (jeweils vollständiges CSS) als Text-Snippet auf dem Webserver ablege und mir dass nach Bedarf reinlade (DB riecht hier nach zu viel Overhead).

Auf der Seite würd ich dann z.B. sowas machen:

[== Smarty ==]
<head>
...
<style type="text/css">
{foreach from=$file_list->icons item='icon'}
  {$icon->base64_snippet}
{/foreach}
</style>
...
</head>
<body>
...
{foreach from=$file_list->files item='file'}
<div class="listing">
  <div class="{$file->extension}">{$file->name}</div>
</div>
{/foreach}
...
</body>

Grüße
Nils

Offline

#23 25. Januar 2011 00:04

piratos
Gast

Re: [GELÖST] 1 Request Web's im Standard möglich

Jetzt leuchtet mir ein, dass es wenig Sinn macht, die Icons jeweils am Einsatzort als base64 einzubetten. Dann bette ich das gleiche Icon ja 20 mal ein ... das ist ja auch nicht Ziel der Übung. Oder fällt das bei Komprimierung nicht so ins Gewicht, weil der String identisch ist und geschickt in der Compression "verschwindet" ... kann das jemand beantworten? Dann könnte man quasi "rumsauen".

1. daran denken Images base64 codiert im Cache ablegen, damit man nicht jedes mal bzw. ein Besucher jedes mal die Codierung anwirft.
2. Was die Dateigröße betrifft - Icons haben Micky Maus Format - uninteressant, auch wenn die 50 x eingebunden werden.
3. Sprites - Aufwand groß, Nutzen klein , bei Mengen geht der Schuss wahrscheinlich nach hinten los.


Bei mir gehe ich sogar soweit das ich z.B. Images die von Fremdseite stamme (z.B. Google Wetter) in den Cache ablege und zusätzlich als base64 .

Das Kunststück eines "Gesamtkunstwerks" ist es statt 100% dynamische Generierung zu einer Hybridversion zu werden, in dem sich statische Elemente (Cache) und dynamische die Arbeit teilen.
Das muss vom Ansatz gut überlegt sein, damit es prima funktioniert.

Ich habe meinen Leuten mitgeteilt, das wir mit der nächsten PCMS -Version soweit sind, das wir die Verantwortung über maximale Power den Besuchern überlassen.
Die haben nur dann maximale Power wenn sie mit einem aktuellen guten Browser heran gehen.

Testseiten zeigen den krassen Unterschied - 1 Request bei einem Goodbrowser,  50 Request's beim IE8 und 113 bei dem IE 7 - von Zeiten müssen wir da nicht mehr reden - nichts und niemand kann gegen eine solche Seite anstinken - was die Geschwindigkeit betrifft.
Einfluss nach aussen - Null mit Ausnahme einer Hinweismöglichkeit auf einen Scheiss-Browser.

Die Technik ist seit nun fast 4 Wochen im Dauereinsatz bei einer ziemlich dicken Site die damit reichlich Kohle einsparen - die aufwendigen Kosten für CDN können vollständig entfallen.

#24 29. Januar 2011 03:32

nhaack
Server-Pate
Ort: Bonn
Registriert: 12. Dezember 2010
Beiträge: 171
Webseite

Re: [GELÖST] 1 Request Web's im Standard möglich

Hab's jetzt mal wie folgt testweise aufgesetzt ...

Kleines Plug-in, dem ich sag, welches Icon ich brauche. Das Plugin bekommt als Parameter mitgegeben, ob der Browser kompatibel ist und gibt einen fertigen IMG-Tag mit Pfadnamen (nicht Kompatibel) oder Bild als data-URI zurück (wenn vorhanden aus Cache sonst erzeugen).

[== smarty ==]

{dataurl}

{foreach from=$file_list->files item='file'}

  {base64_file_icon file_extension=$file->extension compatible=$good_browser}

  {$file->name}

{/foreach}

Beim ersten Aufruf (CMSMS Cache inkl. base64 -> leer) braucht die Installation bei 50 Icons die jeweils einmalig vorkommen zum Ausführen etwa 0.24 Sekunden (Zeit-Angabe von CMSMS). Bei nachfolgenden Aufrufen etwa 0.12 Sekunden. Das Plugin überprüft allerdings auch den Mime-Type des Bildes, was etwas mehr Zeit kostet. Wenn man natürlich weiß, dass es immer image/png ist, oder man den mime-type mitgibt, kann man hier sicherlich noch ein bei Zeit einsparen.

Komplett ohne base64-Plugin liegen die Werte bei etwa 0.13 und 0.12 ...

Der erste Besucher nach dem Leeren des Cache muss zwar 0.11 Sekunden länger warten als ohne Einsatz des Plugins, aber ansonsten kann man den "Performance-Verlust" wohl ruhigen Gewissens als minimal bezeichnen, wenn überhaupt irgendwie relevant vorhanden (habe leichte Schwankungen bei beiden Werten die sich überlagern).

Damit kann ich gut leben big_smile

Ohne Plugin ist die Seite 29kb groß, mit 44kb (vorab hatte ich die PNG allerdings nochmal mit PNGOUTWin optimiert). Mit den extra 15kb kann ich ebenfalls gut leben ... das ist wirklich schnuppe ...

In diesem Tesfall habe ich 50 Requests auf der Seite eingesparen und 6 Page-Speed Punkte gewonnen. In Summe also ein sehr gut gelaufen Experiment. Das geht sicherlich noch ein wenig performanter und eleganter, überzeugend find ich's jetzt schon.

Grüße
Nils

Beitrag geändert von nhaack (29. Januar 2011 03:33)

Offline

#25 29. Januar 2011 11:13

piratos
Gast

Re: [GELÖST] 1 Request Web's im Standard möglich

Daran denken Pagespeed sagt nichts über die reale Geschwindigkeit aus und das ist genau die, welche Google für seine Bewertung feststellt.

Am einfachsten ist es immer mit webpagetest.org einmal vorher und einmal hinterher zu messen.

Und so läuft's bei mnir:

<?php

#Smarty Function dimage
#PowerCMS (c)2010 by Jan Czarnowski  (czarnowski@powercms.org)
#This project's homepage is: http://powercms.org
#
#This program is free software; you can redistribute it and/or modify
#it under the terms of the GNU General Public License as published by
#the Free Software Foundation; either version 2 of the License, or
#(at your option) any later version.
#
#This program is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#GNU General Public License for more details.
#You should have received a copy of the GNU General Public License
#along with this program; if not, write to the Free Software
#Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA

function smarty_function_dimage($params, &$smarty) {
    global $goodbrowser, $browser,$config, $memcache,$version;
    $image = isset($params['image']) ? $params['image'] : '';
    $style = isset($params['style']) ? $params['style'] : false;
    $cachetime = 3600;
    if ($image <> '') {
        if ($goodbrowser && !defined('RSS')) {
            $parts = pathinfo($image);
            $image2 = str_replace('../../', '', $image);
            if (isset($parts['extension'])) {
                
                $ext = $parts['extension'];
                $extklein = strtolower($ext);
                $filename = $config['previews_path'] . '/dimage_gd_' . md5($image);
                if (!$memcache) {
                    if (is_file($filename))
                        $data = @file_get_contents($filename);
                    else {
                        $data = base64_encode(file_get_contents($image2));
                        file_put_contents($filename, $data);
                    }
                } else {
                    $data = $memcache->get(md5($filename));
                    if (!$data) {
                        if (is_file($image2))
                            $data = base64_encode(file_get_contents($image2));
                        if ($data)
                            $memcache->set(md5($filename), $data, MEMCACHE_COMPRESSED, $cachetime);
                    }
                }
                if (strlen($data)>32000 && $browser=='msie' && $version < 9.0)
                    $data='';
                if ($extklein == 'jpg') $extklein='jpeg';
                if ($data)
                    echo ' <img src="data:image/' . $extklein . ';base64,' . $data . '" ' . $style . ' />';
                else
                    echo ' <img src="' . $image . '" ' . $style . ' />';
            }
            else
                echo ' <img src="' . $image . '" ' . $style . ' />';
        }
        else {
            if (strpos($config['root_url'], $image) === false) {
                if ($image[0] == '/')
                    echo ' <img src="' . $config['root_url'] . $image . '" ' . $style . ' />';
                else
                    echo ' <img src="' . $config['root_url'] . '/' . $image . '" ' . $style . ' />';
            }
            else
                echo ' <img src="' . $image . '" ' . $style . ' />';
        }
    }
}
?>

Ein UDT ist für solche Sachen übrigens nicht sehr gut geeignet - kann ich nur davon abraten so etwas einzusetzen wenn es um Performance geht.

Beitrag geändert von piratos (29. Januar 2011 11:38)