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

#26 20. Januar 2018 22:55

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

Re: Schnellere mobile Seiten mit Googles AMP (Accelerated Mobile Pages)?

...und die Seite wird schneller.

Es geht aber darum, trotz Performance eben nicht auf den ganzen Schnickschnack verzichten zu müssen


Module: GBFilePicker, AdvancedContent
Sicherheit: Beispiel .htaccess-Datei
CMSms 1.12 unter PHP 7:
cmsms-1.12.3.zip (inoffiziell - komplett inkl. Installer)
CMSms 1.12 unter PHP 8:
cmsms-1.12.4.zip (inoffiziell - komplett inkl. Installer)

Offline

#27 23. Januar 2018 15:47

Pepe
hat von CMS/ms gehört
Registriert: 30. August 2017
Beiträge: 15

Re: Schnellere mobile Seiten mit Googles AMP (Accelerated Mobile Pages)?

Achso ok verstehe...


Niveau sieht nur von unten aus wie Arroganz.

Offline

#28 04. Februar 2018 17:30

Andynium
Moderator
Ort: Dohna / SN / Deutschland
Registriert: 13. September 2010
Beiträge: 7.017
Webseite

Re: Schnellere mobile Seiten mit Googles AMP (Accelerated Mobile Pages)?

Damit es noch schneller geht, will Google jetzt sogar ein neues W3C- und IETF-standardisiertes Webpaket-Format erschaffen. Vorteil der Lösung soll sein, dass über die Paket-Lösung die Quell-URL angezeigt wird, was auch der am häufigsten geäußerte Wunsch der am AMP-Projekt Beteiligten ist.

https://amphtml.wordpress.com/2018/01/0 … amp-pages/

Wir nehmen Änderungen an der Funktionsweise von AMP in Plattformen wie Google Search vor, die es ermöglichen, dass verlinkte Seiten unter den URLs von Publishern anstelle des URL-Raums von google.com/amp angezeigt werden, während die Performance- und Datenschutzvorteile von AMP Cache Serving erhalten bleiben.

Als wir zum ersten Mal AMP in Google Search starteten, machten wir einen großen Kompromiss: Um die Benutzererfahrung zu erreichen, die uns die Benutzer sagten, dass sie es wollten, mussten wir die Seite laden, bevor der Benutzer klickte. Wie wir letztes Jahr in einem Deep-Dive-Blog-Post ausführlich dargelegt haben, ist es aus Datenschutzgründen grundsätzlich unmöglich, die Seite vom Server des Herausgebers zu laden. Verleger sollten erst dann wissen, was sie interessiert, wenn sie aktiv auf ihre Seiten gehen. Stattdessen werden AMP-Seiten aus dem Google AMP Cache geladen, aber mit diesem Verhalten wurden die URLs so geändert, dass sie das Präfix google.com/amp/domain enthalten.

Wir sind selbst große Fans von aussagekräftigen URLs und erkennen, dass dies nicht ideal ist. Viele von euch sind sich einig. Es ist sicherlich die Nummer 1 der Rückmeldungen, die wir über AMP hören. Wir haben versucht sicherzustellen, dass diese URLs an möglichst wenigen Stellen angezeigt werden. Im Laufe der Zeit begannen unsere nativen Google Search-Apps auf Android und iOS damit, die URLs der Publisher anzuzeigen, und wir arbeiteten mit Browser-Anbietern zusammen, um die URL des Publishers eines Artikels zu teilen, wo immer dies möglich war. Wir konnten jedoch nicht den Status der URLs dort festlegen, wo er am wichtigsten ist: im Web und in der URL-Leiste des Browsers.

Wir haben eine mehrmonatige Arbeit begonnen und sind heute endlich zuversichtlich, dass wir eine Lösung gefunden haben: Wie vom W3C TAG empfohlen, beabsichtigen wir, eine neue Version des AMP Cache Servers auf Basis des neuen Web Packaging Standards zu implementieren. Basierend auf diesem Webstandard können AMP-Navigationen von Google Search die Vorteile des Vorladens und der Performance von Googles Servern nutzen, während URLs so bleiben, wie der Publisher es beabsichtigt und der primäre Sicherheitskontext des Webs, der Ursprung, intakt bleibt. Wir haben einen Prototyp auf der Basis des Chrome Browsers und einer experimentellen Version von Google Search entwickelt, um sicherzustellen, dass er tatsächlich sowohl die gewünschte UX als auch die Performance in realen Anwendungsfällen liefert. Dieser Schritt gibt uns die Zuversicht, dass wir eine vielversprechende Lösung für dieses schwierige Problem haben und dass es bald die Art und Weise sein wird, wie Benutzer auf AMP-Inhalte im Web stoßen werden.

Die nächsten Schritte gehen in Richtung der vollständigen Implementierung des neuen Webstandards in Webbrowsern und im Google AMP Cache. Unser Ziel ist es, dass Web Packaging in möglichst vielen Browsern verfügbar wird (schließlich hat Web Packaging spannende Anwendungsfälle jenseits von AMP wie Offline-Seiten, ES6-Module laden und Ressourcen bündeln). Insbesondere beabsichtigen wir, die bestehenden Arbeiten an WebKit auf die Implementierung von Web Packaging auszudehnen, und die Implementierung des Google Chrome-Teams ist in vollem Gange.

Wir freuen uns riesig, dass wir diese Arbeit in Angriff nehmen können, und wir erwarten, dass die Änderungen in der zweiten Hälfte des Jahres 2018 die ersten Anwender erreichen werden. Vielen Dank für Ihr Feedback zu diesem Thema und wir werden Sie alle über den Fortschritt auf dem Laufenden halten, genau hier in diesem Blog!

Übersetzt mit www.DeepL.com/Translator

Das dahinter stehende Prinzip wurde Mitte vergangenen Jahres auf dem internationalen IETF Meeting in Prag vorgestellt, damals allerdings noch mit Fokus auf die Offline-Verfügbarkeit von Internet-Inhalten, was sich jedoch auch für die AMP-Pakete einsetzen lassen soll.

Offline