nicht angemeldet
Aber ich bezog mich … auf die Inhalte, die im HTML Code stecken, um bei (volumenmäßig) großen Inhalten ggf. anfangs nur einen Teil auszuliefern, sodass der User auf Wunsch jeweils den Rest per AJAX nachladen kann.
Ich sehe das Problem nicht, das du serverseitig lösen wilst. Nahezu jeder Browser, einschließlich Mobilbrowser, unterstützt JavaScript, also kann man problemlos Inhalte mit JavaScript nachladen. Das Promille, das kein JavaScript unterstützt, bekommt halt eine sehr kurze Startseite, aber die restlichen Inhalte sind per Links zugänglich, sofern man vernünftige Web-Apps schreibt.
Na ja, ich dachte da halt eher an Szenarien wie sehr viel Text und Bilder auf_einer_Seite. Wenn man jetzt halt nicht pauschal jedem direkt quasi die komplette Seite inklusive aller Bilder ausliefert ...
Aber man könnte natürlich dann trotzdem für User ohne JS einen Link einbauen, der die komplette Seite anfordert.
Momentan hat man natürlich die Qual der Wahl, entweder möglichst viele Inhalte die erste Response zu packen oder sie dynamisch nachzuladen. Das eine ist performant bei High-Latency-Verbindungen, angenommen der User liest die verschiedenen übertragenen Inhalte auch. Es erzeugt aber viel Datenverkehr, der die User meistens kostet. Das andere ist performant und sparsam, angenommen der User liest nur die initialen Inhalte.
Da sich die Datenpreise schneller verringern als die Latenz und die Netzwerkprotokolle sich verbessern, würde ich für einen westlichen Markt eher mehr Inhalte über die Leitung pushen, sodass beim Wechseln zwischen Inhalten weniger Request gesendet werden müssen.
Da wirst du wohl Recht haben.
Obiger Fall macht imho insbesondere dann Sinn, wenn man zusätzlich noch Infos über die Art der Verbindung und die (Device) Viewportsize hätte (im Hinblick auf Mobile Devices mit kleinerem Display und ggf. "langsamen" GSM Verbindungen).
Außerdem könnte man sich so auch ggf. irgendwelche "umständlichen" Fallbackszenarien bezüglich der einzubindenden Images (Stichworte "Retina Displays" und "Image Size") ersparen.
Von der Verbindungsgeschwindigkeit abgesehen gibt es dafür ausgereifte clientseitige Lösungen, die weitaus besser funktionieren als eine potenzielle serverseitige Erkennung, die Caching, Skalierbarkeit und damit Frontend-Performance unterminieren würde.
Letztlich müssen es clientseitige Lösungen sein, weil sich diese Parameter zur »Laufzeit« ändern können.
Clientseitige Lösungen haben halt aus meiner Sicht immer den Nachteil, dass man jedem Client immer erst mal alles rüberschaufeln muss.
Hier geht es also vorrangig auch immer nur um den ersten Request auf eine bestimmte Website. Wobei man ja auch nie weiß, auf welche Seite der Site dieser erfolgt.
Und ob sich bestimmte Parameter zur »Laufzeit« ändern können oder nicht, hängt ja u.a. auch von dem verwendeten Gerät ab.
Wobei ein Viewport aber eigentlich nie größer sein kann, als die maximale Auflösung des jeweiligen Displays (ich weiß, das ist auch nicht zu 100% korrekt, reicht mir aber). Insofern gäbe es hier durchaus "Einsparpotenzial" durch serverseitige Generierung des "passenden" Codes. Aber vermutlich "lohnt" das auch wieder nicht, da es wie gesagt ja eigentlich nur für den jeweils ersten Request von Belang ist.
Also vergiss' meinen Einwurf ...! ;-)
Gruß Gunther