Das asynchrone Laden von Inhalten aber bietet, da wo man es einsetzen kann, immer Vorteile.
Wenn man weiß, das ich z.B. bei meinem Angebot seitenreport.info streckenweise bis zu 40 externe Websites gleichzeitig abklappere, Informationen hole, diese Filter und dann darstelle, dann ist man erstaunt wie fix das geht.

Das Thema ist eigentlich mehr parallele Verarbeitung und weniger lazy loading.

Es gibt ganz sicher auch Einsätze bei denen man ruhig nach einem Event nachladen kann.

Ansonsten sind wir recht schnell bei Themen Session Storage, Local Storage und IndexedDB mit dem sich noch enorm etwas anstellen lässt (könnt ihr mir ungesehen glauben, setze ich nämlich bei ganz bestimmten Anwendungen ein).

Diese Techniken sind nicht neu - sind sie doch HTML5.
Aber welcher Webdesigner denkt über eine etwas andere Deklaration und ein paar breit besprochene Möglichkeiten an solche Dinge, die aber ohne Zweifel Designsachen sind.
Design besteht eben nicht  nur aus schönen Webseiten sondern eben auch im Entwurf der Funktionalitäten, Erfordernissen und unter Berücksichtigung der aktuellen Techniken.

Auf der Programmiererseite gibt es tatsächlich mit Ausnahme bei gewerblichen Produkten verdammt wenige Titel bei denen diese Dinge überhaupt ein Thema sind.

Was Application Cache betrifft z.B. wird im Netz darüber fast nur im Sinne von komplett lokal ablaufenden Applikationen geredet,  da erkennen einige überhaupt nicht was man damit noch alles anstellen kann.
Ich bin z.Z. mit meine Titeln der einzige der das als Jedermann CDN und Extremcache verwendet und das im Zusammenhang mit Xajax zudem auch noch voll dynamsich ist ( 0 Request Web).

Volleinsatz der bekannten Pagespeedmethoden ist angesagt wie auch Volleinsatz der weniger bekannten und das erfordert in einigen Core - Bereichen Eingriffe z.B. verfeinerte Cachingmethoden, Xajax - Schnittstelle.

Da hätte ich mal noch eine Idee, die mancheiner vielleicht schon gesehen oder gar angewendet hat: "Lazy Loading". Aber diesmal nicht für irgendwelche Scripte, sondern für den Content.

Ich kann zwar alles (Stylesheets, Javascript und Bilder) direkt ins HTML Gerüst packen um die Requests zu minimieren, aber dann kommt mitunter ein riesen Batzen Info durch die dünne Leitung mobiler Geräte. Das Einsparen der einzelnen Requests alleine wird da nichts bzw. nicht das beste Ergebnis bringen. Bei DSL Verbindungen macht das warscheinlich nicht so viel aus, ob da 500kB in 4 Requests oder mit einem einzigen ausgeliefert werden, aber bei mobilen Geräten schon eher. D.h. sowohl die 4 Requests (die alles extrem langsam machen würden) als auch der ganze Batzen auf einmal (der aufgrund der dünnen Leitung eben nicht in einer Sekunde da sein kann), würden hier zu keinem optimalen Ergebnis führen.

Wenn man den Inhalt allerdings in einzelne Blöcke aufteilen könnte, von denen jeweils nur die geladen werden, die gerade sichtbar sind (z.B. mit Xajax & Co. z.B. in Abhängigkeit von der Position des Scrollbars), könnte man die Datenmenge und somit die Zeit bis zur ersten Reaktion auf dem Display noch mehr verkürzen. Gerade bei Mobilen Geräten stelle ich mir das recht praktisch vor. D.h. es wird erstmal nur ein Grundgerüst geladen (ein "Framework") und die Inhalte kommen dann erst nach und nach. Und zwar NUR die Inhalte. Nichts anderes. Die Blöcke könnte man dann evtl. auch wieder im AppCache ablegen, sodass man nicht die gesamte Seite cached, sondern selektiv einzelne Teile. (Man weiß ja selber, welche Teile sich häufig ändern und welche nicht)

Man könnte darüber hinaus, was einige Browser bereits nativ anbieten, im Vorraus laden und ebenfalls cachen. Rufe ich eine Seite auf, wird der Rest der Seite noch während ich lese heruntergeladen und im AppCache gespeichert.

Diese Ideen und Techniken sind alle nicht neu. Daher wundert es mich regelrecht, dass man sowas nicht häufiger im Web antrifft.

So, DAS ALLES jetzt in ein möglichst flexibles Standard-Layout sowie ein schönes, einfach zu konfigurierendes Modul (mit sinnvollen Default-Einstellungen) gepackt und wir hätten ein echtes "Killer-Modul".

Ich freu mich das dieses Thema  als ein wirklich wichtiges erkannt wird .
In der Tat kann es auch für das Überleben eines ganzen Titels entscheidend sein.

Aber - darauf möchte ich nochmals hinweisen - die  angepasste Auslieferung von Inhalten ist eine Sache, der Erfolg im Einzelfall ist bei den Mobilen ganz besonders auch eine Sache wie man den Powerverlust Desktop vs. mobile Einheiten ausgleicht. Die sind nun mal 3..10 mal langsamer als Desktops, was an der minderen Prozessorleistung aber auch an den wesentlich aufwendigeren Wegen der Request - Übertragung liegt.

Volleinsatz der bekannten Pagespeedmethoden ist angesagt wie auch Volleinsatz der weniger bekannten und das erfordert in einigen Core - Bereichen Eingriffe z.B. verfeinerte Cachingmethoden, Xajax - Schnittstelle.

Diesen Bereich darf man nicht aus den Augen verlieren.

Für ein Ultimate Modul fehlts noch ein wenig, wäre aber mal ne gute Grundlage.

Das trifft sich ja gut. Ich hatte doch tatsächlich vor, heute hier im Forum anzufragen ob jemand Lust hat auf so ne Art "task force" ... :-)

Ich bekomme immer mehr Anfragen von Kunden die nach einer "App" fragen. Meine Antwort: Meist nicht sinnvoll, wenn man eh nur die gleichen Inhalte wie auf der Website reinpacken will. Da ist ne Web-App die bessere Lösung.

In dieser Richtung muss tatsächlich etwas passieren, allerdings werde ich das alleine wohl nicht hinbekommen.

Die grundsätzlichen Überlegungen wurden ja schon genannt.

Was mir vorschwebt ist die Entwicklung eines Moduls o.ä. welches an mobile Endgeräte angepasste Seiten ausliefert bzw. eine sogenannte Web-App bereitstellt.

Für Wordpress zb. gibt es sowas ähnliches:
http://wordpress.org/extend/plugins/wptouch/

Die Basis sollte HTML5 sein:
http://diveintohtml5.org/
http://net.tutsplus.com/tutorials/html- … -be-using/

Für Videos brauchts ne HTML5-Lösung mit Flash-Fallback. Gibts aber AFAIK.

Was die Auflösungen angeht: da bietet CSS3 mit @media einen Ansatz, etwa

/* --- iPad Portrait --- */ @media screen and (max-width: 880px) {zoink: blafasel;}

Mit anderen Worten - man kann an unterschiedliche Auflösungen unterschiedliches CSS ausliefern.
Hab ich schon im Test, sieht IMO vielversprechend aus.

Zum Thema Web-App:
http://sixrevisions.com/web-development … phone-app/
http://www.whatwg.org/specs/web-apps/cu … fline.html

So, DAS ALLES jetzt in ein möglichst flexibles Standard-Layout sowie ein schönes, einfach zu konfigurierendes Modul (mit sinnvollen Default-Einstellungen) gepackt und wir hätten ein echtes "Killer-Modul".

Macht jemand mit?

Servus,
Alex

Stimmt. Und das nicht nur vor dem Fernseher. Ich habe ja schon öfter darüber geklagt, dass ich bei meinem 15" Macbook mit einer Auflösung von 1680x1050 kaum eine Webseite lesen kann, ohne die Kiste 30cm vor mir auf dem Schoß zu haben oder jede Webseite erst 3-5 mal vergrößern zu müssen. Außer mit Javascript kenne ich da leider keine Möglichkeit, auch die Schriftgröße in Abhängigkeit von Fenstergröße oder Auflösung anzupassen.

Naja ... lassen wir Lieschen mal Lieschen sein und konzentrieren wir uns lieber darauf, wie wir das bei der Ausgabe hinkriegen. Lass Lieschen doch riesige Bilder einfügen o.ä. Das kann uns doch sowas von egal sein, wenn wir beim Speichern oder besser erst bei der Ausgabe diese Bilder auf die Größe, die gerade tatsächlich gebraucht wird, runterrechen und evtl. auch noch base64 kodiert einbinden (und cachen). Das Thema Bilder dürfte hier weniger das Problem sein, denn da sehe ich viele Möglichkeiten wie man als Webdesigner dafür sorgen könnte, dass sie für das jeweilige Gerät optimiert sind.

Komplizierter wird es meiner Meinung nach tatsächlich erst beim Layout. Auch hier dürften Bilder oder Formatierungen weniger das Problem sein. Grafische Spielereien könnte man bei mobilen Endgeräten weglassen und stattdessen einfach nur mit Hintergrundfarben oder den Möglichkeiten von CSS3 arbeiten. Formatierungen (Schriftgrößen, Abstände, Breite etc.) passt man dem Gerät an bzw. verwendet Prozent-Angaben. Und natürlich muss man auf den korrekten Media-Type achten.

Was die Aufteilung der Webseite angeht (Spalten, Positionen etc.) das ist der Punkt an dem es meiner Meinung nach komplizierter wird, weil man das nicht unbedingt nur mit einem angepassten Stylesheet hinbekommt. Da muss dann mitunter auch mal ein dynamisches Template her, oder man hat eben mehrere Templates.

Ich glaube jedenfalls nicht, dass das alles nur eine Frage eines einzigen omnipotenten Layouts ist - ohne irgendwo einen Kompromiss eingehen zu müssen. Ich glaube eher, da muss man schon ein wenig mehr programmieren oder zumindest (in Hinsicht auf CMSms) mit Smarty-Logik arbeiten.

Das Problem ist allerdings, dass man serverseitig nur sehr bedingt alles für die Ausgabe vorbereiten kann. Man kann sich dabei natürlich auf den User-Agent stützen, aber ob man dadurch 100%ig weiß welches Gerät mit welchen Fähigkeiten tatsächlich dahinter steckt, ist fraglich. Ich glaube, ohne irgendeinen Kompromiss geht das garnicht zu machen. Sei es in optischer Hinsicht oder in Sachen Speed. Man kann meiner Meinung höchstens einen Mittelweg finden, mit dem dann vielleicht 70-80% zufrieden sein werden.

Was man alles auf Client-Seite tun könnte ... da kann man mit Sicherheit noch einige Techniken mehr einsetzen, die in einem einzigen Layout für alle Geräte verwendet werden können. (Javascript, App-Cache, Ajax - allerdings braucht man dazu auf dem Server auch wieder die entsprechenden Schnittstellen) Aber dafür ist gerade zu schönes Wetter als dass ich mir an einem sonnigen Sonntag noch mehr Gedanken darüber machen will

Interessant ist diese Frage nach einer Technik mit der man so einfach wie möglich so viel wie möglich abdecken kann allemal.

Wieso sollte jemand Inhalte doppelt pflegen sollen, nur weil er auch Mobile Endgeräte berücksichtigen ... ? Das ist doch nicht Aufgabe des Content-Erstellers, sondern des Webseiten-Erstellers. Die Webseite muss so aufgebaut sein, dass sie je nach Client die Inhalte in entsprechender Form wiedergeben kann. Aber das verstehe ich wiederum unter "zwei oder mehr Webs aufbauen".

Natürlich ist es die Aufgabe zunächst vom Webseiten-Ersteller, aber Lieschen Müller muss sich u.U. an bestimmte Dinge halten und wenn es nur die Größen von verwendeten Images sind.

Und natürlich ist Lieschen auch dafür mit verantwortlich ob eine bestimmte Leistung erreicht wird oder nicht.

Und der Aufbau einer Darstellung kann sich verändern, was z.B. vorher in drei Spalten nebeneinander lag, kommt jetzt untereinander - das muss bei den Inhalten berücksichtigt werden.
-------------
Manche kommen auf die Idee das ihr Web auch so von den Mobilen verarbeitet werden.

Das ist tatsächlich bei den meisten aktuellen Geräten der Fall, aber dann wird eine Seite auf dem kleineren Display entweder soweit verkleinert das es da rein passt oder es wird so genommen das man Fingerspiele machen muss.

Das Thema Leistung wird dabei absolut nicht berücksichtigt.
Verkleinerte Seiten sind meist nicht lesbar.
Die Navigation ist für Fingerbetrieb unbrauchbar.

Ein solches Vorhaben bewirkt nur eines - die Besucher kommen nicht wieder.

---------------

Nun haben wir ja noch die andere Seite - die des Surfens über Fernseher.
Gute Fernseher haben da mindestens 1920 x 1080 Pixel.

Verwendet man ein fixes Layout hat man u.U.den Klex auf dem Bildschirm.

Nimmt man Fluid hat man u.U. einen Streifen auf dem Bildschirm, der Rest ist Hintergrund.

Auch da gibt es Haue vom Besucher - die kommen nicht wieder und insbesondere dann, wenn die Familie vor der Glotze sitzt und einer fängt an zu meckern.

Zum anderen haben wir da ja auch noch einen ganz anderen Sichtabstand.

Man müsste also ein Konzept finden bei dem das alles vernünftig gesteuert werden kann.

Wie bringen wir diese Zahlen jetzt in Übereinstimmung mit Deiner Liste?

Man muss mit gleicher Technologie und Rahmenbedingungen und gleicher Empfangsstelle und gleichen Browser vergleichen.

Einfach base64 erzeugen für alle das funktioniert nicht, da nicht alle Browser das überhaupt oder nur teilweise verarbeiten können.

Das soll nun kein Grundkurs für Pagespeed - Anfänger werden, aber man kann es sich vielleicht vorstellen, das man diesen Imageteil vom Browser abhängig ausführt.

Nehmen wir mal den ersten Test - Frankfurt IE9

http://www.webpagetest.org/result/110903_2Z_1G72Q/

und nehmen wir mal einen weiteren Test Frankfurt IE 7, der IE 7 hat absolut keinen Schimmer von Base64, deswegen bekommt er alles als normalen Imagelink vorgesetzt.

http://www.webpagetest.org/result/110904_B2_1GA4Q/

Und wenn man sich die Werte ansieht hat man eine ziemlich klare Vorstellung von dem was base64 bringt - nämlich nur Vorteile.

Was bei dem http://www.blaze.io/mobile/result/?test … SZ&src=wpt  niemand aufgefallen ist   0 Request, 0 Bytes übertragen - erstaunlich.

Und dennoch 0,84 Sekunden beim ersten Durchlauf für die Darstellung, dann aber 0 Sekunden beim zweiten.

Nun liegt die Teststelle in Kanada, das muss man so hinnehmen, ansonsten käme da eine sehr viel kleinere Zeit heraus.

Was man in dem Test sieht ist das 0 Request - Web.

Das Speed unabdingbar ist - völlig klar, denn Smartphones und Tabs sind 3..10 langsamer als ein Desktop.

Das ist eine Herausforderung und wegen der Verbreitung der Mobilen eine schwerwiegende.

Das Web muss gefallen, aber es muss ausreichend schnell sein und es muss funktionabel sein für Desktop wie auch für Mobile.

Das ist die Herausforderung und nicht die Aufklärung einzelner wie Pagespeed und Speed - Methoden funktionieren.

Nachtrag:

Wenn man sich den mobilen Check ansieht, der allerdings weit weg in Kanada läuft kann man die Problematik erkennen, auch wenn die Zeiten bei dem geballten Inhalt und für Kanada nicht schlecht sind, sie reichen aber in der Praxis nicht aus.

Nicht vergessen - hier werden nur die Request's über base64 reduziert, ansonsten keine Tricks verwendet:

http://www.blaze.io/mobile/result/?test … pt#testube

Mach doch mal eine Rechnung wie auf wie deine Bilanz bei http://www.webpagetest.org/result/110903_2Z_1G72Q/  ohne base64 ausehen würde.

Inhaltlich mag das ne interessante Geschichte sein, haste da vlt. paar Testcases dazu? Mag mir grad die Grafiken da nich rauspulen.
Das Webpagetest-ding, nunja, Firebug sagt mir was anderes. Wenn ich da bspw. trash-wissen.de vergleiche, wo nix inline und nix grossartig optimiert ist, wo jede Menge Müll mitgeladen wird und zig Requests am Werkeln sind, macht Deine Referenz den 2. Platz:
Erster Aufruf:
trash-wissen.de:
24 requests: 1,91 Sek
tagungshotels.com/..suche
6 requests: 2,78s

2. Aufruf:
trash-wissen.de:
24(2×200ok) requests: 2,17 Sek (warum auch immer für 12,5kb Text)
tagungshotels.com/..suche
6(1×200ok) requests: 2,74s

Wie bringen wir diese Zahlen jetzt in Übereinstimmung mit Deiner Liste?

@piratos: Kompliment. Deine Seiten sind schnell. Aber sie sind - mit verlaub - keine Eye-Catcher. Auf Smartphones & Co ist das völlig okay. Aber auf einem riesen Display (wo hinten noch ein Quad-Core Superduper Rechner dranhängt) ist das wirklich nur bissel Fließtext mit paar Bildchen und daher nicht sonderlich aufregend.

Versteht mich nicht falsch, ich stehe auf Seiten die übersichtlich und auf das wesentliche reduziert sind. Noch mehr stehe ich dabei allerdings auf Seiten die noch dazu interessant gestaltet sind. Und da bin ich nicht alleine.

In den letzten 20 Jahren haben sich Webseiten von reinen langweiligen Dokumenten mit Querverweisen hin zu interessanten Applikationen oder Kunstwerken entwickelt. Eine einzige Seite für alle Geräte zu machen, würde bedeuten, auf allen Geräten einen ganzen Schritt zurück zu gehen. Ich glaube nicht, dass das wirklich einen Vorteil bietet. Da erstelle ich doch lieber eine Seite, die je nach Gerät entsprechend reduziert oder aufgebläht ist.

Es kommt natürlich immer auf den Geldbeutel an. Aber hier kommt der Punkt an dem ich bereits sagte: Manchmal muss man einfach Kompromisse machen. Entweder der Kunde bezahlt für ein hochoptimiertes aber dafür einfaches Design für alle Geräte oder er zahlt für mehrere ja nach Gerät optimierte aber dafür (für einige Geräte) etwas anspruchsvollere Designs.

Das muss man meiner Meinung nach von Fall zu Fall entscheiden. Eine allgemeingültige Musterlösung gibt es da nicht und wird es vermutlich auch nie geben.

Nee, ernshaft: Mittags schon Eierlikör?

Schon vergessen wer damit angefangen hat ?
Das ist dein Niveau und das liegt in Wirklichkeit offenbar noch niedriger als ich vermutet habe.

Einem dem man erst einmal nachweisen muss wie es um mobile Aktivitäten steht, der davon also vorher nicht so richtig etwas gewusst hat, und dann völlig unqualifiziertes Zeug von sich gibt.

Mach doch mal eine Rechnung wie auf wie deine Bilanz bei http://www.webpagetest.org/result/110903_2Z_1G72Q/  ohne base64 ausehen würde.

irgend jemand erkennbar ohne einen blassen Schimmer  auf den Putz haut und von Dingen reden will von denen er absolut wissensfrei ist,

Quelle?

Quelle? Davon ab: kannst Du da ein paar Infos zum Thema nachschieben, statt zu hyperventilieren?

Quelle?

Oh, es geht wieder mit persönlichen Beleidigungen los. Weiss grad nicht, warum ich ich bisher Deinen rechnerischen Unsinn oben und Dein Statistikbildchen-fetisch nicht als Mumpitz bezeichnet habe. Werde mir in Zukunft mehr Mühe geben, mit Dir auf Deinem Niveau zu diskutieren.

sei doch ein bißchen entspannter ;=)

Ein paar Images mehr =
http://www.blaze.io/mobile/result/?test … T9&src=wpt

Jede Menge Images ?
Kein Thema nimmt man halt eine andere Seite http://www.webpagetest.org/result/110903_2Z_1G72Q/ , da sind massig base64 enthalten aber keine sonstigen Tricks.