Google führt JavaScript aus
molily
Google führt JavaScript aus
molily
Google macht Fortschritte bei der Indizierung von Inhalten, die mit JavaScript geladen werden:
http://googlewebmastercentral.blogspot.de/2014/05/understanding-web-pages-better.html
Mathias
-
Hallo Mathias und alle Mitleser!
Google macht Fortschritte bei der Indizierung von Inhalten, die mit JavaScript geladen werden:
http://googlewebmastercentral.blogspot.de/2014/05/understanding-web-pages-better.htmlDanke für die Info! :-)
Das sind ja durchaus positive Neuigkeiten.Jetzt fehlt nur noch, dass der Browser per Header übertragen würde, ob (zum Zeitpunkt des Absenden des Requests) JS aktiviert ist oder nicht.
Gruß Gunther
-
Hi,
Jetzt fehlt nur noch, dass der Browser per Header übertragen würde, ob (zum Zeitpunkt des Absenden des Requests) JS aktiviert ist oder nicht.
Wieso sollte diese Information serverseitig interessant sein?
Entweder du codest einen Fallback für Clients, die JavaScript nicht ausführen. Der lässt sich mit bewährten Techniken einbinden (Progressive Enhancement). Dann braucht der Server nicht zu wissen, ob der Client JavaScript ausführt. Entweder der Client lädt die Scripte herunter und führt sie aus, oder eben nicht.
Oder du bietest keinen Fallback, weil die Anwendung ohnehin JavaScript benötigt. Dann braucht der Server nicht zu wissen, ob der Client JavaScript ausführt, denn der Server setzt es stillschweigend voraus und es gibt auch keinen Alternative.
Mathias
-
Hi,
Jetzt fehlt nur noch, dass der Browser per Header übertragen würde, ob (zum Zeitpunkt des Absenden des Requests) JS aktiviert ist oder nicht.
Wieso sollte diese Information serverseitig interessant sein?
Entweder du codest einen Fallback für Clients, die JavaScript nicht ausführen. Der lässt sich mit bewährten Techniken einbinden (Progressive Enhancement). Dann braucht der Server nicht zu wissen, ob der Client JavaScript ausführt. Entweder der Client lädt die Scripte herunter und führt sie aus, oder eben nicht.
Oder du bietest keinen Fallback, weil die Anwendung ohnehin JavaScript benötigt. Dann braucht der Server nicht zu wissen, ob der Client JavaScript ausführt, denn der Server setzt es stillschweigend voraus und es gibt auch keinen Alternative.
Ja, das ist natürlich alles völlig richtig.
Aber ich bezog mich (dem Kontext des Threads entsprechend) 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.Für diesen Fall wäre mir zumindest keine (sinnvolle) Fallback-Lösung bekannt. Aber ich bin natürlich immer erpicht darauf, Neues zu lernen.
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.
Gruß Gunther
-
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.
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.
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.
Mathias
-
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
-
-
-
-