Mobiltauglich - Mobilegeddon
Mit zunehmender Verbreitung der Mobilgeräte wird deren Einsatz auch zum Abrufen von klassischen Internet-Seiten zunehmen und vermutlich irgendwann auch den heute noch immer hohen stationären Einsatz des Abrufes von Internet-Seiten am PC nicht nur überholen, sondern langfristig sogar gänzlich ablösen.
Google drohte im Frühjahr 2015 allen Betreibern von Internet-Seiten mit dem neuen Update Mobilegeddon, das es tatsächlich zum 21. April 2015 einführte. Das martialisch klingende Wort Mobilegeddon, das an den Weltuntergang (Armageddon) erinnert, könnte für einige Betreiber von Internet-Seiten tatsächlich eine extreme Benachteiligung bedeuten.
In diesem Artikel erfahren Sie, welche extremen Anforderungen Google an Ihren Internet-Auftritt stellt, und wie Sie diese Anforderungen an Mobiltauglichkeit erfüllen können. Mit Praxisbeispielen zum Kopieren.
Responsive Design / Liquid Design / Fluid Design
Im Grunde genommen ist die Lösung dafür ganz einfach und wurde schon früher von Internet-Ergonomie-Spezialisten angewandt: Responsive Design / Liquid Design / Fluid Design. Hierunter versteht man ein Seiten-Layout, das sich der Breite des Monitors / Anzeigegerätes und des verwendeten Browser-Fensters automatisch anpasst. - Reduzieren Sie hierzu als Beleg doch einmal Ihr jetziges Browser-Fenster (vor allem in der Breite) und beobachten Sie, wie sich meine Seite darin automatisch anpasst.
Eigentlich wäre es das schon gewesen, wenn da nicht zwei Dinge hinzukommen würden. Erstens ist da die oft miserable Anbindung vieler mobiler Geräte (insbesondere Smartphones und Mobiltelefone in den USA) an das Netzt, mit Transferraten, welche einen an das Internet der 1990er Jahre erinnern und somit die heute überall verwendeten Fotos zum Problem werden lassen. Zweitens ist da die Unfähigkeit bzw. der Unwille Googles, realistische Standards und einheitliche Testmethoden zur Klassifizierung von Mobiltauglichkeit zu verwenden.
Googles Machtmissbrauch
Inzwischen dürfte jeder Besitzer von Internet-Seiten bereits die folgende E-Mail von Google mit dem Titel der E-Mail Fix mobile usability issues found on http://www...
erhalten haben. Google systems have tested ## pages from your site and found that ## % of them have critical mobile usability errors. The errors on these ## pages severely affect how mobile users are able to experience your website. These pages will not be seen as mobile-friendly by Google Search, and will therefore be displayed and ranked appropriately for smartphone users.
- Erstaunlich ist ferner, dass ich diese E-Mails sofort nach meiner in einem Artikel geäußerten Kritik an der durch Google praktizierten Zensur erhielt. - Honi soit qui mal y pense.
Abgesehen davon, dass diese E-Mail von meinem E-Mail-Programm als Phishing-/Betrugsversuch eingestuft wurde, können viele Deutsche wohl nicht so gut Englisch, um die weitreichenden Implikationen zu verstehen. Das klingt ja auf den ersten Blick auch nicht so schlimm. Denn nur selten erhält man diese E-Mail auf Deutsch. Dann lautet der Text: Beheben Sie Probleme der mobilen Nutzerfreundlichkeit auf http://www...
- Die Systeme von Google haben # Seiten auf Ihrer Website getestet und bei ## % dieser Seiten kritische Fehler in Bezug auf die Nutzerfreundlichkeit auf Mobilgeräten für Ihre Website erkannt. Die Fehler auf den # Seiten beeinträchtigen die Nutzererfahrung auf Mobilgeräten deutlich. Diese Seiten werden von der Google-Suche als nicht für Mobilgeräte optimiert eingestuft, und werden entsprechend in den Suchergebnissen für Smartphones-Nutzer dargestellt.
Google wird allerdings jede solche Einzelseite und damit vor allem auch den Gesamtauftritt bereits im Suchergebnis als ungeeignet
brandmarken. Die meisten unbedarften Nutzer dürften dies mit gefährlich
verwechseln, und folglich derartige Seiten meiden. - Die ist unabhängig von der nachträglich veröffentlichten Aussage Googles, dass man angeblich nur Einzelseiten abstraft, und nicht den gesamten Auftritt. De facto ist und bleibt es so, dass kein normaler Nutzer, einen Auftritt besuchen wird, zu dem er immer wieder für Einzelseiten den Hinweis erhält, das er ungeeignet sei. Hier handelt es sich um eine pauschale Rufschädigung. Schließlich denken Menschen auch nicht differenziert, wenn bekannt wird, dass bei einer Automarke bei einem Modell die rechte Hinterradbremse nicht geeignet ist, bei einem anderen Modell die Lenkung, bei einem weiteren Modell der Motor und bei noch einem Modell der Sicherheitsgurt. Der Schaden betrifft die gesamte Firma mit allen Produkten.
Im Internet kursieren Gerüchte, dass Google sogar Pläne haben soll, demnächst derartige Seiten nicht mehr bezüglich des Inhaltes zu ranken. D.h. auch wenn Sie den besten Inhalt der Welt besäßen, würden Sie nicht mehr auf der ersten Trefferseite von Google erscheinen. Bereits das Verschieben auf die 2. Trefferseite würde einen erheblichen Einbruch bezüglich der Abrufzahlen bedeuten. Spätestens ab Seite 5 schauen überhaupt nur noch wenige Menschen nach.
Im Internet kursieren ferner Gerüchte, dass Google sogar Pläne haben soll, später derartige Seiten überhaupt nicht mehr zu listen. Das würde bedeuten, dass Sie komplett ausfallen und nie mehr über Googles Suchmaschine gefunden werden könnten.
Seit 21. April 2015 hat Google begonnen, aus seiner Sicht für Mobilgeräte nicht geeignete Seiten schlechter zu ranken, also in Suchergebnissen wesentlich weiter unten anzuzeigen. Dies bedeutet, dass auf Mobilgeräten guter Inhalt weit hinter schlechtem Inhalt, preiswerte Produkte weit hinter teuren rangieren, seriösen Inhalte hinter kriminellen. Kriterium für die Anzeige bei Suchen auf Mobilgeräten soll nun in erster Linie die vage Mobiltauglichkeit von Google sein.
Und um dies gleich vorweg zu nehmen und Ihnen Anfragen dazu zu ersparen: Angesichts des bisherigen Verhaltens der Firma Google halte ich dies für nicht nur möglich, sondern für wahrscheinlich.
Wenn Google diejenigen Internet-Auftritte, welche die firmeneigenen Mobilitätsanforderungen erfüllen, mit einem grünen Stern etc. zusätzlich kennzeichnen würden, also einem Bonussystem, wäre hiergegen nichts einzuwenden. Aber so handelt es sich um eine Diskriminierung und Zensur.
Willkürliche Festlegungen Googles
Selbstverständlich kann eine internationale Dachorganisation - wie die ISO - International Organization for Standardization - weltweite Ergonomieregeln festlegen. Diese werden in vielen Gremien weltweit besprochen und ausgiebig diskutiert, bevor sie schließlich in einen Standard münden. Dieser ist manchmal durchaus anspruchsvoll und somit keineswegs der immer wieder behauptete kleinste gemeinsame Nenner. Denn diese Fachleute wissen durchaus, was sinnvoll, zeitgemäß und realistisch umsetzbar ist. Aber vor allem handelt es sich um einen demokratisch abgestimmten und durch die Staatengemeinschaft legitimierten Vorgang.
Bei Google ist das jedoch in allen Punkten anders: Google hat nichts und mit niemandem abgestimmt, sondern willkürlich alles selbst festgelegt. Google hält sich selbst nicht an einen Standard, sondern ändert die Regeln seiner Test-Tools für Mobiltauglichkeit laufend ab. Google besitzt und veröffentlicht unterschiedliche Test-Tools, welche völlig unterschiedliche Ergebnisse bezüglich der Mobiltauglichkeit einer Internet-Seite diagnostizieren. Google hält sich selbst noch nicht einmal an den seit Jahrzehnten weltweit geltenden HTML-Standard, sondern fordert explizit zum Verletzten desselben auf, nur um seine eigenen willkürlichen Forderungen zu erfüllen. Google erkennt zahlreiche seit Jahren angewandte Verfahren zur gerätespezifischen Auslieferung von Inhalten für Mobilgeräte nicht an, um dann die Seiten abzuwerten. Usw. Kurzum: Google definiert, was mobile-friendly bedeutet - und hat - wie sich bald zeigen wird - dafür knallharte kommerzielle Vorgaben und Eigeninteressen.
Im Folgenden finden Sie Belege dieser Statements mit Fakten und Erklärungen der weitreichenden Konsequenzen für Internet-Betreiber. Dazu liefere ich Ihnen jeweils Lösungsvorschläge und realistisch umsetzbare Empfehlungen.
Willkürliche Pixelbreite
Google hat die zu erfüllende Pixelbreite auf 320 festgelegt. D.h. alle Internet-Seiten, welche sich nicht auf diese Maß in der Breite zusammenschieben lassen, werden als untauglich eingestuft. Dazu wurde völlig willkürlich von Google als Grundlage das erste jemals von Apple hergestellte Mobiltelefon verwendet. Es mag sein, dass im mittleren Westen der USA irgendein armer Farmer noch so etwas benutzt. Aber mir ist kein Nutzer eines solchen Gerätes in Deutschland bekannt.
Man fühlt sich bei Googles willkürlicher Festlegung an den US-Unsinn der 1990er Jahre erinnert. Dort wurde damals immer behauptet, dass man Internet-Auftritt nur mit 640 Pixeln Breite erstellen dürfe, weil es in den USA angeblich noch derartige Monitore gab, während in Deutschland zur gleichen Zeit bereits 1.024*768 Pixel absoluter Standard und dank Aldi weit verbreitet war. Bereits damals litten die Internet-Auftritte unter dieser absolut unsinnigen, willkürlichen US-Festlegung, die nichts mit der eigenen Zielgruppe oder dem deutschen Markt zu tun hatte. - Bei Mobilgeräten geschieht nun dasselbe.
Google unterscheidet bei Mobilgeräten noch nicht einmal zwischen Smartphones und Tablets.
Ferner weigert sich Google zu akzeptieren, dass die meisten Nutzer auf kleineren Geräten sowieso bei Internet-Auftritten das Mobilgerät um 90 Grad schwenken, um noch mehr Inhalte in der Horizontalen zu sehen. Es wird also seit Jahren praktiziertes elementares Nutzerverhalten vorsätzlich ignoriert.
Überdies weigert sich Google, den technologischen Fortschritt und die Marktanteile der Geräte zu berücksichtigen. Moderne Tablets besaßen bereits 2015 eine Auflösung von bis zu 1.536 * 2.048 (iPad 3 und 4) oder 2.560 * 1.600 (Google Nexus 10 von Samsung). Das ist mehr als fast jeder Desktop-Monitor. 4-K-Tablets stehen kurz vor der Markteinführung und 8-K-Tabletts finden sich in den Entwicklungsabteilungen vieler Hersteller. Google schafft somit heute ein Problem, das derzeit überhaupt nicht mehr existiert.
Moderne Smartphones besaßen bereits 2015 eine Auflösung von bis zu 1.920× 1.080 (z.B. iPhone 6 Plus). Das ist so viel wie fast jeder Desktop-Monitor besitzt. Somit existierte das angebliche Problem bereits 2015 auch für Smartphones nicht mehr.
Um es nochmals klar zu sagen: Alle mir bekannten und heute tatsächlich noch benutzten Smartphones und Tablets bieten HD oder Full-HD und können im Format Landscape - also quer geschwenkt - jeden mir bekannten Internet-Auftritt problemlos darstellen. Es existiert somit überhaupt kein Problem für Mobilgeräte. Dieses wird einseitig von Google postuliert.
Für die deutsche Sprache ist es bereits aufgrund der langen Wörter unmöglich, einen für 320 Pixel geeigneten Text automatisch herzustellen. - Ein automatischer Wortumbruch für 320px existiert jedoch nicht in HTML. - Leider brechen auch nicht alle Browser und nicht alle Testsysteme den normalen Bindestrich / Trennstrich auch tatsächlich um (bei mir werden z.B. Zahlen, wie 25-50
, nicht umbrochen). D.h. - (- oder -) reicht nicht immer aus, damit dort auch wirklich getrennt wird. D.h. auch die nach Duden korrekten Wortkombinationen zwischen Fremdwörtern und Deutsch (z.B. Ultrahighspeed-Testprotokoll) werden nicht immer getrennt.
D.h. man muss manuell Trennstreiche (­ ­ soft hyphen sowie <wbr>) einfügen. In vielen Redaktionssystemen ist dies jedoch sehr aufwändig bzw. nicht vorgesehen.
Noch aufwändiger wird es bei mehrspaltigen Tabellen - ein in HTML zur Darstellung von Inhalten erlaubtes und bis heute verwendetes Element. Hier wird eine Reduktion der Schriftgröße erforderlich. Eine zu kleine Schrift führt jedoch sofort wieder zum Fehler bei Google. Bei mir wurden bisher jedoch 70% Schriftgröße noch erlaubt.
Ferner ist eine extreme Worttrennung innerhalb von Text-Tabellen meist unumgänglich.
Im Übrigen werden weder ­ noch <wbr> immer in Link-Bezeichnern akzeptiert. So weigerte sich Googles Test-System beharrlich, den Linkbezeichner Produktentwicklung
zu trennen. Obwohl es jeder Browser in allen getesteten Varianten) durchführte. Im Übrigen stellt dieses Wort auch keine Breitenbegrenzung dar, da das Wort bequem in 320 Pixeln passt. Schließlich blieb nur noch übrig, das Wort völlig mit Leerstellen zu trennen Produkt - Entwicklung
.
Fast immer zu Problemen führt der / (Schrägstrich über der Zahl 7), den man im Deutschen gerne ohne Leerzeichen verwendet (also LangesWort/LangesWort
). Er führt fast nie zur Trennung. Hier sollte man generell den / durch Leerstelle / Leerstelle ersetzen.
Vorsicht: Man darf keinen automatischen Wechselbefehl dafür einsetzen, da alle Links ebenfalls den / verwenden.
Selbst früher als ergonomisch sinnvoll angesehene Dinge, wie das Verbinden zweier Text-Elemente mittels geschützter Leerzeichen ( ), können nun zum Problem werden, falls man dadurch die 320 Pixel überschreitet.
Ganz schwierig wird die Sache übrigens, wenn der eigene Text die erlaubte 320-Pixel-Breite um 1 Pixel überschreitet. Hinweise zu einer zu großen Breite bietet Google meist nur bei sehr großen Verstößen an, wobei dies oft einzeln geschieht. D.h. man muss einen Fehler nach dem anderen beheben und jedes Mal erneut testen. Und optisch wird dies sehr mühsam.
P.S. der einzige PC-Browser, der zu einem optischen Breitentest verwendet werden kann, ist - rein zufällig - auch der von Google Chrome. Nur er lässt sich auf die geringen 320 Pixel Breite (inklusive Scroll-Balken) zusammenschieben.
Am Samstag, den 28.03.2015, war das System hingegen wieder einmal nachsichtiger und erlaubte auch überbreite Texte. D.h. man kann sich nie darauf verlassen.
Inwiefern der Fehler im Browser Google Chrome, der nicht mit nachgestellten Grafiken hinter Links klarkommt - z.B. a{background-image:url(/b/rechts.gif);background-repeat:no-repeat;background-position:100% .3em;padding-right:1.5em;}, sich auch auf die diversen Test-Werkzeuge auswirkt, bleibt unklar. Bisher wurden zumindest in meinen Tests Seiten deswegen nicht komplett abgewertet. Aber der horizontale Scroll-Balken in Chrome ist dennoch lästig. Chrome berechnet hier die notwendige Breite des Textes im Verhältnis zum Bildschirm falsch. Sicherheitshalber sollte man derartige CSS-Details mit nachgestellten Grafiken im Mobilteil entfallen lassen.
Für Google wäre es bereits bei der Suchanfrage eines Nutzers sehr wohl möglich, dessen (Mobil-) Gerät sowie dessen Bildschirmbreite (im Hoch- und Querformat) zu erkennen, und ihm dann die Seiten sowie Such-/ Trefferergebnisse individuell aufbereitet anzubieten. Nutzer mobiler kleinster Geräte würden dann eben weniger Seiten als optimiert für Sie angezeigt erhalten. Aber hier werden alle Mobilgeräte über einen Kamm geschoren, bzw. gnadenlos in ein von Google willkürlich dimensioniertes Prokrustesbett gezwängt.
Und der Gipfel der Unverfrorenheit ist, dass Google für die eigene Unfähigkeit auch noch jedem einzelnen Internet-Anbieter die Schuld in die Schuhe schiebt.
Seit April 2015 mehren sich Anzeichen und Gerüchte, dass Google diese Breite von 320 Pixeln bewusst gewählt hat, weil es selbst eine Armbanduhr (Wearable Internet) herausbringen möchte, die nur diese Breite als Anzeigefläche bietet. Selbstverständlich könnte man heute mehr Pixel auf eine derartige Fläche packen. Aber das wäre teurer. Und Google scheint offensichtlich mit einer relativ preiswerten Variante den Markt erobern und dominieren zu wollen. Dies wäre ein Machtmissbrauch sondergleichen. Eine Firma legt vorab willkürlich einen nur ihr passenden Standard fest, um dann anschließend ihre Marktmacht noch weiter ausbauen zu können. - Zum Verständnis: Würden keine Seiten oder nur wenige auf der kleinen Google Watch angezeigt werde, dann würde selbstverständlich kaum jemand diese Armbanduhr kaufen. D.h. hier wird der gesamte Weltmarkt dem eigenen Produkt angepasst, nicht das Produkt den Bedürfnissen der Welt.
Empfehlungen
Sie werden wohl oder übel, diese im Deutschen erforderliche Worttrennung manuell durchführen müssen. D.h. im Detail Sie müssen mit Googles Speedtest-Tool manuell jede einzelne Seite prüfen und so lange optimieren, bis sie auf 320 Pixel passt.
Konkret bedeutet dies: Verwenden Sie ­ ­ soft hyphen in Worten ohne Bindestrich (also z.B. Donaudampfschifffahrtsgesellschaftskapitän). Es fügt beim Umbruch einen Bindestrich / Trennstrich ein. Wenn Sie Ihren Browser deutlich schmaler einstellen, erkennen Sie diese von mir eingefügten fakultativen Trennstriche in dem obigen langen Wort.
Verwenden Sie <wbr> in Worten mit Bindestrich (also z.B. HTML-Standard
). Wordbreak (wbr) führt bei Bedarf einen Umbruch ohne weiteren Bindestrich / Trennstrich durch.
Entfernen Sie - im Zweifel durch pauschalen Wechselbefehl über alle Inhaltsseiten - die früher üblichen geschützten Leerzeichen ( ). Ansonsten müssen Sie das manuell auf jeder Einzelseite bei Bedarf durchführen.
Vorsicht: Falls Sie leere Tabellenzellen mit als Platzhalter verwenden, dürfen Sie keinesfalls alles automatisch ersetzen, sonst funktionieren Ihre Tabellen evtl. nicht mehr.
Ganz tückisch können Links sein. Da muss man dann im sichtbaren Teil des Links im Zweifel sogar Leerstellen einfügen, da sonst nicht umbrochen wird.
Die überstehenden Dinge (Text und Grafiken) findet man am leichtesten und schnellsten, wenn man den bei 320 Pixeln Bildschirmbreite unten sichtbaren horizontalen Scroll-Balken ganz nach rechts verschiebt und dann schnell die Seite vertikal durchscrollt. Beheben Sie immer zuerst das größte störende Element. Meist ist damit das Problem bereits behoben.
Sie benötigen 2 Layouts: Eines für breite Anzeigegeräte und eines für schmale, wobei es auch auf 320 Pixel funktionieren muss.
Ich würde für das schmale Layout weder allzu viel Zeit noch Geld investieren. Die meisten Mobilgeräte können sowieso das breite Layout darstellen. Es soll nur alles lesbar sein und funktionieren. Bei einem schmalen Layout muss man sowieso erhebliche Kompromisse eingehen.
Dazu sind im Head jeder Datei folgende Zusätze zwingend erforderlich:
Zuerst einmal wäre da: <meta name="viewport" content=
Dann foglt: <link rel="stylesheet" media="(max-width: 949px)" href="css/schmal.css" /> - Das legt die Grenze fest, bis zu der das schmale Layout verwendet wird. Sie können selbstredend eine andere Zahl und einen anderen Namen für das schmale Layout verwenden.
Danach benötigen Sie noch <link rel="stylesheet" media="(min-width: 950px)" href="css/breit.css" /> - Das legt die Grenze fest, ab der das breite Layout verwendet wird. Sie können selbstverständlich eine andere Zahl und einen anderen Namen verwenden. Aber die Zahl muss 1 Pixel größer sein als die Grenze für das schmale Layout.
Wo Sie die Grenze zwischen schmalem und breitem Layout legen, hängt von Ihren Inhalten ab:
Schauen Sie in Ihren Bildverzeichnissen deren Breite durch. Zumindest die maximale Breite des größten Bildes müssen Sie als Untergrenze setzen. Je nach Formatierungen rund um die Bilder (border, margin und padding) kommen dann noch Sicherheitszuschläge hinzu. Ich verwende meist 50 Pixel mehr als Puffer.
Wenn Sie Texttabellen verwenden (mehrspaltige Tabellen mit Textinhalten), müssen Sie diese einzeln vermessen. Dies kann sich bereits als ziemlich aufwändig erweisen.
Beides betrifft jedoch nur den Inhaltsbereich Ihrer Seiten. Falls Sie eine seitliche Navigation verwenden, müssen Sie deren Breite hinzuaddieren.
Bevor Sie stundenlang Details im neuen Layout abändern, empfehle ich Ihnen ganz oben im Body folgendes einzutragen: font-size:100%;line-height:175%; (Die line-height darf / kann / muss ggf. auch 150 oder 200% betragen. Das sollten Sie bitte selbst austesten.)
Nicht selten werden sonst kleinere Schriften und kleine Zeilenabstände verwendet, welche auf Mobilgeräten kaum lesbar sind und fast immer zu Fehlern im Testtool führen.
Mit dem großen Zeilenabstand lassen sich auch fast alle Probleme bei Links (insbesondere im Fließtext) umgehen, die auf den schmalen Displays sehr häufig direkt übereinander liegen, was aufgrund des fehlenden Abstandes bemängelt wird.
Für reine Navigationslisten mit vielen Links kann - je nach sonstigen Abständen (margin und padding) - sogar ein Zeilenabstand von 200% erforderlich sein.
Vergessen können Sie im Übrigen alle Wünsche nach Sonderschriften. Googles Test-Software verwendet sie nicht. Stattdessen wird eine fette, breite Arial verwendet, die oft das Layout sprengt. D.h. Sie müssen in vielen Fällen die Schriftgröße der Überschrift(en) reduzieren.
Fangen Sie bei der Umstellung Ihrer Einzelseiten mit der aller kompliziertesten an. Wenn dort das Layout laut Googles beiden Test-Werkzeugen als mobiltauglich angesehen wird, dann fallen die anderen Seiten meist relativ leicht.
Übertreiben Sie den Aufwand für das Layout der Mobilseite nicht. Mir sind Firmen bekannt, die über die Jahre hinweg gerechnet für Erstellung, Änderung, Pflege, Wartung etc. insgesamt 6- bis 7-stellige Summen dafür ausgegeben haben. Wenn Sie Ihre Zielgruppe klar bestimmt und das breite
Layout darauf abgestimmt haben, dann werden sicherlich weniger als 10 % der Nutzer jemals die schmale Seite überhaupt sehen. Und abschließend nochmals: Alle mir bekannten 320-Pixel-Layouts sehen m.E. niemals schön aus, sondern im Idealfall gerade noch funktional. Optimierungen daran fallen für umsatzorientierte Unternehmer eigentlich unter die Rubrik schöner wohnen
.
Zwei sich widersprechende Test-Werkzeuge
Man glaubt es kaum, aber Google bietet an und verwendet nebeneinander tatsächlich zwei sich ständig widersprechende Test-Tools: Test auf Optimierung für Mobilgeräte, dessen Forderungen man mit umfangreichen HTML- und CSS-Kenntnissen erfüllen kann. Aber die euphorische Meldung Großartig! Diese Seite ist für Mobilgeräte optimiert.
ist leider wenig wert.
Denn dann gibt es noch das wesentlich strengere PageSpeed Insights. Dessen Anforderungen waren zumindest zum Testzeitpunkt - im Frühjahr 2015 - von keinem größeren Fotoauftritt wirklich zu erfüllen.
Bereits das Layout des angeblichen Screen-Shots der Testseite unterscheidet sich: Bei PageSpeed Insights ist es deutlich länger als bei Test auf Optimierung für Mobilgeräte.
Zur Verwirrung wurden beide Werkzeuge in den Folgejahren immer wieder verändert sowie auch umbenannt und auf anderen Internet-Adressen angeboten.
Falsche Analyseergebnisse
Hinzu kommt, dass Googles Test-Software PageSpeed permanent falsche bzw. völlig irreführende Angaben macht.
Wenn Sie z.B. die Meldung erhalten: Optimale Größe von Links oder Schaltflächen auf Mobilgeräten einhalten
, dann liegt dies fast immer daran, dass Ihre minimale Bildschirmbreite größer als 320 Pixel ist. Dann rechnet Google alles einfach so klein, dass es in seinen Testmonitor passt. Es hat überhaupt nichts mit der Größe Ihrer Links oder Schaltflächen zu tun. Meist muss man dann zuerst überbreite Bilder oder zu lange (ungetrennte) Wörter behandeln.
Falls Sie z.B. die Meldung erhalten: Lesbare Schriftgrößen verwenden
, dann liegt dies fast immer daran, dass Ihre minimale Bildschirmbreite größer als 320 Pixel ist. Dann rechnet Google alles einfach so klein, dass es in seinen Testmonitor passt. Es hat überhaupt nichts mit der Größe Ihrer Links oder Schaltflächen zu tun. Auch dann muss man meist zuerst überbreite Bilder oder zu lange (ungetrennte) Wörter behandeln.
Wenn Sie z.B. die Meldung erhalten: Zielseiten-Weiterleitungen vermeiden
, dann liegt dies fast immer daran, dass es auf dem Server zu Umleitungen kam. Google mag dies nicht, auch wenn es erlaubt und üblich ist. Selbst RewriteRule [L,R=301], welche die Suchmaschinen-Abteilung von Google empfiehlt, werden von der Abteilung für Mobilitätstests moniert. So werden oft index.html etc. auf andere Seiten umgeleitet. D.h. Sie müssen zum Test die tatsächliche Endseite / Zielseite angeben. Das führt zum Paradoxon, dass Google die direkt angesprungene Seite als mobiltauglich einstuft, die identische mit Umleitung jedoch als ungeeignet.
Allerdings scheint dieses Umleitungsproblem auch tagesabhängig zu sein. An manchen Tagen wurde es von Google nicht moniert.
Wenn Sie z.B. die Meldung erhalten: JavaScript- und CSS-Ressourcen, die das Rendering blockieren, in Inhalten "above the fold" (ohne Scrollen sichtbar) beseitigen
,
Ihre Seite enthält 1 blockierende CSS-Ressourcen. Dies verursacht eine Verzögerung beim Rendern Ihrer Seite.
Keine der Seiteninhalte "above the fold" (ohne Scrollen sichtbar) konnten ohne Wartezeiten für das Laden der folgenden Ressourcen gerendert werden. Versuchen Sie, blockierende Ressourcen zu verschieben oder asynchron zu laden, oder laden Sie kritische Bereiche dieser Ressourcen direkt inline im HTML.
Dann liegt dies fast immer daran, dass das Test-Tool nicht in der Lage ist, auch ein absolut korrektes CSS zu interpretieren.
Normalerweise führt eine ausgelagerte CSS-Datei bereits zu 9% Abzug bei der Mobilitätstauglichkeit. Am Samstag, den 28.03. zog Google jedoch sogar 21% ab (Beleg: Screen-Shot) und machte eine identische Seite mit dem identischen CSS vom Vortag somit mobiluntauglich. Früher durfte man so etwas als reine Willkür bezeichnen. Kurze Zeit darauf wurde die identische Seite mit dem identischen css wieder mit den üblichen nur
9% bestraft (Beleg 2: Screen-Shot). Minimalste Dinge scheinen das Test-Tool zu irritieren.
Das Hauptproblem scheint für Google darin zu liegen, dass das CSS ausgelagert ist. Das ist jedoch HTML-konform und seit 15 Jahren erwünscht. Also lassen Sie es so.
Antwortzeit des Servers reduzieren
Auch die Angaben zu gelegentlich zu langen Antwortzeit des Servers können Sie ignorieren. Nur falls Sie einen eigenen Server für sich verwenden, auf dem sonst nichts anderes läuft und der Anschluss des Servers an das Internet sehr gut ist (bzw. sein sollte), sollten Sie Ihren Provider informieren. Die meisten Internet-Auftritte liegen jedoch auf gemeinsam genutzten Servern. D.h. die Antwortzeiten schwanken ständig, je nachdem, wie viel Last die 10, 20, 50 oder mehr anderen Auftritte momentan produzieren. Darauf haben Sie keinerlei Einfluss. Des Weiteren haben Sie keinen Einfluss auf die Wege, welche Ihre Anfrage nimmt: Im schlimmsten Fall geht die Anfrage über zahllose Server einmal um die Welt.
Hier der Link zur Auswertung der zu langen Antwortzeit - und hier der wenige Sekunden darauf durchgeführte identische Test mit üblicher Antwortzeit.
Wohlgemerkt gilt dies bereits für einen kurzen Text auf einem performanten Server bei einem wirklich guten Provider mit m.E. gutem Internet-Anschluss. Im Gegensatz zu anderen Dingen wählt hier Google keinerlei Puffer oder bildet einen Durchschnittswert etc., sondern bestraft gnadenlos eine einmalige Zugriffsverzögerung bei einer Einzelseite mit einer Total-Abwertung (minus 10-20% Strafe sind so schnell erreicht). - Selbst der performanteste Server mit der besten Internet-Anbindung (also die teuerste Lösung) kann somit davon betroffen sein.
Nachtrag: Im Übrigen zeigten sich die beiden Seiten der Test-Werkzeuge von Google auch mit ständig anderen Wartezeiten des Servers. Das erste Werkzeug zum Test der Mobiltauglichkeit war dabei oft derart langsam und träge, dass wir in den Tests zwischendurch andere Aufgaben erledigten. - Kein Mensch würde jedoch der Firma Google dafür pauschal die Mobiltauglichkeit absprechen. Verzögerungen sind im Internet systembedingt und somit nie völlig vermeidbar - noch nicht einmal treffsicher voraussagbar.
Zahlreiche Links zum Partnerprogramm von Amazon werden ebenfalls moniert:
Komprimierung aktivieren. Durch die Komprimierung der Ressourcen mit "gzip" oder "deflate" kann die Anzahl der über das Netzwerk gesendeten Bytes reduziert werden. Ermöglichen Sie die Komprimierung der folgenden Ressourcen, um die Übertragungsgröße um ## KB (## %) zu reduzieren.
. Aber darauf haben Sie selbst keinen Einfluss.
Falls Sie IFrames von Amazon einbinden (z.B. die klassischen Produkt-Suchfenster), so wird dort ebenfalls der Abstand des Submit-Buttons zu anderen Links und Schaltflächen moniert. Auch darauf haben Sie selbst jedoch keinen Einfluss. Selbst wenn Sie die Ende April 2015 vorhandenen aktuellen Vorlagen von Amazon (300*250 Pixel) verwendeten, wurden sogar 2 Fehler bemängelt.
Wenn Sie die von PageSpeed Insights angebotenen optimierten Daten verwenden: Sie können optimierte Bild-, JavaScript- und CSS-Ressourcen für diese Seite herunterladen.
Dann werden bei Bildern (JPEGs) die Copyright-Vermerke gelöscht. Das ist nicht akzeptabel.
Um auch einmal etwas Positives sagen zu können, sei darauf verwiesen, dass diese angebotenen Optimierungen für Laien für die Bereiche JavaScript, CSS und Grafiken (PNG) durchaus brauchbar sind und verwendet werden können. Wunder darf man sich davon jedoch nicht erwarten. Bei mir kam es dadurch meist nur zu einer Verbesserung der Gesamtnote um 1 Punkt.
Die andere Test-Software (Test auf Optimierung für Mobilgeräte) spielt jedoch die Mimose:
Wenn man durch die robots.txt etwas für den Google-Bot gesperrt hat, dann hält sie sich scharf daran und erklärt die Seite, welche derartige Inhalte aufruft, als nicht mobiltauglich.
Manchmal zertifiziert sie die Seiten jedoch als mobiltauglich und blendet Elemente einfach aus: Falls man den Ordner /css
vor der Durchsuchung durch Bots schützt, so wird das Layout nicht angezeigt. Es erscheint nur ein weißer Hintergrund. Und Die Software verwendet irgendwelche Standard-Schriften etc.
Falls man den Ordner /bilder
vor der Durchsuchung durch Bots schützt, so wird das Layout evtl. nicht korrekt angezeigt.
Falls man ganze Dateien in durch robots.txt gesperrten Verzeichnissen liegen hat, dann werden diese überhaupt nicht analysiert, bevor man diese Sperre nicht aufhebt.
Für den Google-Test auf Mobiltauglichkeit muss leider alles offen und zugänglich sein.
Im Laufe des April 2015 kam es immer wieder vor, dass die Software sich weigerte die CSS zur HTML-Seite zu laden, um dann nur unformatierten Text auf weißem Hintergrund anzuzeigen. Meist lässt sich dies dann mit einem oder mehreren erneuten Senden / Untersuchungen derselben Seite beheben.
Den Gipfel der Unfähigkeit erlaubt sich Google dann mit seinem Google Analytics Werkzeug, das zumindest im April und Mai 2015 angebliche Fehler auf Seiten meldete, die mit beiden anderen Tools von Google nachweislich weder vorher noch nachher auf der Seite waren. D.h. einmal von beiden Test-Tools zertifizierte Seiten werden von einem offensichtlich dritten in Google Analytics, das wohl anders arbeitet, übergangen. - Die meisten dieser Fehler dauerten auch Anfang 2016 an.
Komprimier-Werkzeuge
Wer die Pack- und Komprimier-Werkzeuge von Google nicht verwenden will findet hier einige kostenlose Tools.
CSS
Sie sollten auf Ihrem PC zu Hause (Off-line) eine oder mehrere klar lesbare und für Sie nachvollziehbare / sofort verständliche CSS verwenden. Legen Sie sich zusätzlich eine Kopie aller CSS in einem Unterordner komprimiert
an. Nur diese Dateien in dem Unterordner sollten Sie komprimieren und dann auf Ihren Server in das Internet stellen. Erfahrungsgemäß erbringt die Komprimierung ca. 1 Prozentpunkt auf Googles Bewertungsskala. Wunder darf man folglich nicht erwarten. Ein Kompressor mit vier Stufen ist csscompressor. Auch dieser verkleinert ihre CSS w3clubs online.
JavaScript - JS
Sie sollten auf Ihrem PC zu Hause (Off-line) eine oder mehrere klar lesbare und für Sie nachvollziehbare / sofort verständliche JavaScript-Dateien verwenden. Legen Sie sich zusätzlich eine Kopie aller JavaScript-Dateien in einem Unterordner komprimiert
an. Nur diese Dateien in dem Unterordner sollten Sie komprimieren und dann auf Ihren Server in das Internet stellen. Erfahrungsgemäß erbringt die Komprimierung ca. 1 Prozentpunkt auf Googles Bewertungsskala. Wunder darf man folglich nicht erwarten. Typische Komprimierwerkzeuge für JavaScript sind HTML Minifier und jscompress. Vorsicht: Nicht alle JavaScript-Dateien kann man packen. Manche Programme arbeiten danach nicht mehr korrekt. Die Funktionstüchtigkeit muss man nach dem Komprimieren unbedingt testen.
HTML
Lassen Sie von manuellen Komprimierungen der HTML-Seiten die Finger. Entweder macht dies Ihr Server automatisch, oder es ist mit zu viel Aufwand und Nachteilen für Sie verbunden.
Fotos und Grafiken
Grundprobleme Bildgröße, Bildqualität und Ladezeit
Fotos und Grafiken waren schon immer ein Problem im Internet. Je größer sie flächenmäßig sind und je höher die Bildqualität ist, umso höher steigt die Dateigröße und die Ladezeit nimmt zu.
Google katapultiert uns jedoch mit seinen Anforderungen wieder in die 1990er Jahre. Mehr als 1 hochwertiges Bild pro Seite ist gemäß Googles Testprogramm kaum mobiltauglich zu gestalten.
Wer ein Tablet im WLAN verwendet, leidet nicht unter Ladezeitproblemen. Und, wer sich das neueste Smartphone mit dem üblichen LTE-Standard oder 5G anschafft, ebenso wenig. Somit handelt es sich auch hier um ein von Google willkürlich und überflüssigerweise erzeugtes Problem, das de facto kaum jemand betrifft.
D.h. auch hier ist Google entweder zu faul oder inkompetent (oder weigert sich bewusst?), um die Datenleitung des Nutzers abzufragen und ihm dann die jeweils korrekten Auskünfte zu erteilen. Stattdessen erhalten alle Nutzer mobiler Geräte, oder solche mit stationären Geräten aber einem Browser, der sich irrtümlicher Weise falsch zu erkennen gibt, die völlig überzogene und in vielen Fällen falsche Auskunft, dass die meisten Internet-Auftritte der Welt nicht mobiltauglich seien und somit für Ihn ungeeignet wären.
Ferner entmündigt Google hier den Nutzer und zensiert die Auftritte, indem die Firma weder Nutzer noch Anbieter die Chance einräumt, auf eigene Anforderungen Einfluss zu nehmen. Jeder Nutzer, der sich einen Auftritt mit Fotos ansehen will, nimmt die etwas längeren Ladezeiten in Kauf. D.h. Ergonomie ist individuell abhängig. Aber das ignoriert Google bewusst.
Worin die Googlesche Logik bestehen soll, ist unklar. Kein Browser hält sich an die robots.txt. Dieser Text gilt nur für Spider. D.h. die Inhalte der robots.txt haben auf die Mobiltauglichkeit keinen Einfluss.
Hinzu kommt, dass Googles Testprogramme im Frühjahr 2015 alle mir bekannten Techniken zur optimalen Auslieferung von kleineren Bildern ignorierten oder falsch interpretierten.
Googles falsche Bild-Analyse
Googles Test-Tool PageSpeed Insights, das von Google selbst in den E-Mails und im Internet explizit zur Optimierung der Seiten auf Mobiltauglichkeit angepriesen wird, versagte in fast allen relevanten Punkten für Bilder.
Beim Testen funktionierte stundenlang das Speed-Tool nicht, ohne dass eine Fehlermeldung ausgegeben würde (z.B. Dienstag, 24.03.2015 den gesamten Vormittag). Stattdessen werden nur völlig unsinnige Testresultate geliefert - wohl gemerkt für unveränderte Dateien, die am Tag zuvor und einige Stunden später einwandfrei liefen.
Auffällig ist auch, dass die Werte für die identischen Bilder ständig variierten. Einmal werden ca. 10kB / ca. 25 % Optimierung festgestellt, ein anderes Mal bis zu 75 %. Darunter versteht der mathematische Algorithmus von Google den Optimierungsbedarf. Mit anderen Worten: Das Bild soll 75 % kleiner werden. Selbst Werte von weit über 80% Verbesserungspotential wurden zeitweise diagnostiziert.
Auch unter Weglassung aller sichtbaren und unsichtbaren Copyright-Vermerke (erstaunlich, dass Google dies offensichtlich verlangt und somit dem Fotodiebstahl aktiv Vorschub leistet) und Reduktion der Fotos auf eine für Menschen unerträglich niedrige Bildqualität, waren derartige Werte in Tests meist nicht erzielbar.
Ferner werden Bildmaße von Googles Testsystem falsch ausgewertet. Gibt man im Quelltext die Breite des großen Bildes an, wie man es früher immer mit height und width gewohnt war, um die Rendering-Zeit zu verringern (also den Seitenaufbau zu beschleunigen), so werden diese herangezogen und sprengen den Darstellungsrahmen des 320-Pixel-Referenz-Monitors. Die Maße des ausgelieferten kleinen Bildes werden hingegen ignoriert.
Sie können allerdings alle Angaben unterhalb von 320 Pixeln Breite bei Grafiken und Fotos belassen, da sie unterhalb des Rahmens des Test-Tools liegen.
Erstaunlich ist ferner, dass Googles Test-Tool diejenigen Seiten am besten bewertet - die Grafiken als am kleinsten und wenigsten störend einstuft -, an denen man an den alten großen Bildern überhaupt nichts ändert, sondern einen CSS-Trick verwendet. Beispiel-Seite mit einem einzigen korrekt eingefügten Bild nach Google (84% / 91% = mobil-untauglich) und dann mit den CSS-Trick (91% / 100% = mobiltauglich).
Als Programmierer würde ich mich schämen, so eine unausgereifte Bananen-Software auf die Kunden loszulassen. Reift beim Anwender
- Vielleicht in vielen Jahren.
HTML-5
Das Speed-Test-Tool entsprach noch nicht einmal dem modernen HTML-5-Standard und auch nicht den Fähigkeiten des hauseigenen Browsers Chrome (z.B. bezüglich der neuen Bildkennzeichnung <picture>, mit der man Bilder unterschiedlicher Größe für jedes Medium seit mindestens 2014 zur Verfügung stellen kann).
Das führt zu folgendem Fehler: Das Element <img src="###.gif, png oder jpeg"> liegt außerhalb des Darstellungsbereichs.
.
Der Seiteninhalt ist für den Darstellungsbereich zu breit, sodass der Nutzer gezwungen ist, horizontal zu scrollen. Passen Sie die Größe des Seiteninhalts dem Darstellungsbereich an, um eine bessere Nutzererfahrung zu bieten.
- D.h. das Test-Tool lädt das breite Bild an Stelle des schmalen.
Im Endergebnis macht dies je Bild schnell 4-10 % im Bereich Nutzererfahrung aus. Bereits bei nur 2-3 korrekt eingebundenen Bildern wird Ihre Seite somit als untauglich abgewertet.
Wie exakt Googles Test-Werkzeug Bilder abwertet, bleibt im Dunkeln. Mir scheint eine Abhängigkeit von der Bildbreite und der Dateigröße zu bestehen. Ferner hängt es de facto von der Tagesform der Software ab: Manche Seitenwerte schwankten bei allen Tests immer wieder etwas. Eventuell bastelten die Programmierer auch ständig an dem Algorithmus herum, während wir die Tests durchführten.
Team-Arbeit scheint ein Fremdwort bei Google zu sein. Dort weiß offensichtlich die linke Hand nicht was die rechte tut. - Im Klartext: Die Angaben mit Picture werden von Googles Test-Tool ignoriert. In allen Tests wurde immer das große Bild geladen und nicht das zur Verfügung gestellte kleine für Mobilgeräte, obwohl es vom Google-Chrome Browser korrekt geladen und auf schmalen Layouts angezeigt wurde.
Hierzu passt auch, dass sich Googles Programmierer nicht um den offiziellen HTML-Standard kümmern, sondern die Nutzer dazu auffordern, ihn zu verletzten, um Googles willkürliche Hausanforderungen zu erfüllen (siehe dazu auch weiter unten).
Adaptive Images
Da wundert es auch nicht mehr, dass Fremdprodukte, wie das millionenfach verwendete Adaptive Images zum Verkleinern und Ausliefern optimierter Bilder, ebenfalls weder erkannt noch unterstützt werden. Weder wird das auf einem Auftritt installierte Adaptive Images erkannt, noch wird es angesprochen, noch wird das kleine Bild für Mobilgeräte verwendet.
Mehrtägige Tests liefen völlig unbefriedigend ab. Google scheint Probleme mit dem JavaScript von AI zu haben und auch die Server-Anweisungen zu umgehen oder zumindest zu ignorieren.
Zur Klarstellung: Alle Browser aller Mobilgeräte weltweit führen dies korrekt durch und erhalten folglich die kleinen Bilder. Googles Test-Software zertifiziert den Internet-Auftritt dennoch als ungeeignet.
Wie bei so vielen Produkten, die Google als Konkurrenz oder gegen die eigene Firmenpolitik gerichtet betrachtet, wird man den Verdacht nicht los, dass Google dies bewusst so macht, um unliebsame Mitbewerber los zu werden. Es wäre nicht der erste Fall von Machtmissbrauch.
Empfehlungen
Im Ergebnis fällt es somit derzeit extrem schwer, Seiten mit mehr als einem schönen Foto von Google als mobiltauglich zertifiziert zu erhalten.
Zu Ihrer Beruhigung: Die Seiten der meisten Internet-Auftritte werden mobiltauglich ausgeliefert, aber der Google-Algorithmus kann das nicht erkennen.
Aufgrund solcher Ergebnisse kann man den Betreibern bei Google nur jegliche Kompetenz absprechen.
Zukunftssicher scheint die Umstellung auf Picture zu sein. Irgendwann muss auch Googles Test-Tool dieses unterstützen, erkennen und korrekt auswerten.
Konkret heißt dies für Sie als Anbieter allerdings:
Sie benötigen ein auf CSS-3 basierendes Layout - ohne sogenannte Layout-Grafiken im Inhaltsteil der Seite. Letztere werden bis heute gerne von Redaktionssystemen und schlechten Programmierern verwendet, um das Aussehen auf einem Anzeigegerät sicherzustellen.
Sie müssen jeden normalen img-Teil im Quellcode jeder Inhalts-Seite durch folgende Dinge ersetzen: <picture><source media="(min-width: 950px)" srcset="../
In Kurzform: In der 1. Angabe legen Sie die Breite des breiten Layouts und das große schöne Bild für das breite Layout fest. In der 2. Angabe legen Sie (mit srcset) das stark verkleinerte und verschlechterte Bild für das 320-Pixel-Layout fest. Die 3. Angabe dient als Sicherheit (neudeutsch: Fall Back) für Browser, die das Picture-Element noch nicht unterstützen. Dort tragen Sie das große Bild ein.
Height und width müssen entfallen. Korrekt gelesen. Dieser Standard wird von Google nicht unterstützt. Machen Sie dennoch Angaben für die Breite des großen Bildes, dann wird diese Zahl auch für das kleine Bild verwendet und sprengt den Darstellungsrahmen des Referenz-Monitors von Google.
Persönlich empfehle ich - solange picture noch kaum unterstützt wird - derzeit noch alles in <div class="bilder">###</div> zu setzen und eine dementsprechende Klasse in der CSS zu definieren. So kann man auch ohne zusätzliches JavaScript zur Kompatibilitätserzeugung zumindest das Layout garantieren.
Dennoch gilt für alle Internet-Auftritte noch immer: Große Fotos lassen sich auf Mobilgeräten mit kleiner Display-Fläche am besten im gekippten Format genießen. Ferner ist das Qualitäts-Niveau der Firma Google bezüglich Fotos inakzeptabel. Wenn man die Fotos in der von diesen Entscheidern geforderten Form qualitativ reduziert, werden sie unansehnlich. Praktisch kein moderner Auftritt kann heute noch auf hochwertige Fotografien verzichten. Da kann man keine pixeligen Bilder wie auf den Standard-Internet-Auftritten in den USA akzeptieren. - Im Klartext: Was US-Google für mobiltaugliche Fotos hält, ist in Kontinentaleuropa inakzeptabel. Entweder besitzen die dortigen Entscheider schlechte Augen, oder schlechte Monitore bzw. keinen Geschmack resp. keine Erfahrung. Kein Mensch will mehr zurück auf das Internet-Niveau der 1990er Jahre. Meine Fotos werden im Grafikprogramm z.B. bereits mit nur 50% Qualitätsstufe sehr klein abgespeichert. Wem die Ladezeiten zu lange sind, der kann das Laden und Anzeigen von Bildern in seinem Browser abschalten. Benutzen Sie weiterhin große Bilder in hoher Qualität - gleichgültig, was Google dazu meint. Ihre Kunden werden pixelige kleine Fotos nicht mehr akzeptieren. Angesichts der Unfähigkeit Googles, die Nutzer der Mobilgeräte in Ihrer Suchdatenbank adäquat zu versorgen, sollten die Beschwerden auch an Google gerichtet werden.
Google missachtet den HTML-Standard
Die Programmierer bei Google forderten tatsächlich (bis 2019), knallharte HTML-Programmierfehler in die Seiten einzufügen (wie hier). - Man beachte unten im Beispieltext das Style-Sheet, welches außerhalb von HTML geladen wird, um Googles Mobilanforderungen zu erfüllen. Derartige HTML-Fehler führen zu Fehler- und Warnmeldungen in jedem HTML-Checker und zu Fehlfunktionen in vielen Browsern.
Der Glaube daran, dass Google angeblich nur die besten Programmierer der Welt anstellt, wird so erschüttert. - Da man davon ausgehen darf, dass Google dies ableugnet und ggf. die Seite CSS-Bereitstellung optimieren
entfernt, habe ich sie gesichert und stelle sie hier als Screen-Shot zur Verfügung.
Google fordert sogar explizit, dass man wieder CSS-Formatierungen in die Textdateien einfügt, um diesem (von Google selbst verursachten) Problem vorzubeugen. Nachdem wir rund 15 Jahre benötigten, um im Internet endlich Inhalte von Layout zu trennen, und alle Browser dies beherrschen, stellt das einen von Google erzwungenen Rückschritt in die 1990er Jahre und einen eklatanten Verstoß gegen jede Programmierrichtlinie dar.
Empfehlungen
Folgen Sie auf keinen Fall derartigen Empfehlungen, gegen HTML-Regel zu verstoßen. Sie würden Ihren Auftritt für viele Nutzer unbrauchbar machen.
Lassen Sie auf jeden Fall alle Formatierungen in separaten CSS-Dateien. Die Pflege von in Inhalten befindlichen Handformatierungen ist heute kaum mehr bezahlbar, da der Aufwand jedes verantwortbare Maß übersteigt.
Googles Forderung nach versetztem Laden mittels defer und async
Da Googles Test- und Messwerkzeuge offensichtlich nicht mit Inhalten klarkommen, die nacheinander geladen werden, aber gemäß der Definition von Google früher benötigt werden, fordert Google das versetzte Laden mittels defer und async.
Das hat jedoch den Nachteil, dass keineswegs alle JavaScripte derart ausgelagert und nachträglich geladen werden können. Ebenso wenig funktioniert dies immer mit .css-Dateien für das Layout. Der Effekt ist dann oft, dass das Layout hoffnungslos zerschossen wird. Dies muss man auf jedem Browser und jedem Betriebssystem Ihrer Zielgruppe einzeln testen. Unterschätzen Sie hierzu den Aufwand nicht. Es existieren hierzu auch keine Test-Tools. Ich selbst habe in Tests dutzende u.a. vom W3C als korrekt zertifizierte CSS-Dateien mit defer und async getestet, und praktisch immer kam es dennoch zu Fehlern in den Browsern. Auch zahlreiche JavaScript-Dateien lassen sich nicht asynchron laden. Dies führt in vielen Fällen dazu, dass die benötigten Funktionen (oft für das Layout) nicht bereitgestellt werden.
Empfehlungen
Überlegen Sie sich die Verwendung von async und defer genau und testen Sie es auf wirklich allen Systemen Ihrer Zielgruppe.
M.E. ist es nicht zielführend alle funktionierenden CSS und JavaScript-Dateien umzuprogrammieren, nur dass sie auch noch mit async und defer zusammen arbeiten.
Cache und Proxy-Einstellungen
Fast jeder erhält die folgende Fehlermeldung Browser-Caching nutzen
- Das Festlegen eines Ablaufdatums oder eines Höchstalters in den HTTP-Headern für statische Ressourcen weist den Browser an, zuvor heruntergeladene Ressourcen über die lokale Festplatte anstatt über das Netzwerk zu laden.
Um Bonuspunkte bei Google zu sammeln. bzw. überhaupt als mobiltauglich zu gelten, muss man nun ganz spezifische Cache-Forderungen des Browsers erfüllen. Ohne Zugriff auf den Server oder zumindest die .htaccess ist dies jedoch Normalsterblichen unmöglich. Denn viele Provider bieten diesen Zugriff in preiswerten Pakten nicht an.
Und falls Sie syndizierte Inhalte verwenden, lässt sich dieses Cache-Management leider nicht auf den bezogenen Inhalt erweitern: Das hat zur Folge, dass man von Dritten eingebaute (Bild-) und sonstige Inhalte nicht selbst bezüglich des Cache-Verhaltens beeinflussen kann. Zwar denkt man dabei primär an die großen Internet-Portale, aber heute sind davon auch viele kleine Internet-Auftritte betroffen. Wer z.B. Wetter- oder andere Nachrichten eingebaut hat, kann bei Google keine optimale Mobilität erzielen. Punkt.
Das betrifft im Übrigen auch alle Autoren und Reporter in Deutschland, die über VG-Wort etc. eine kleine Zählgrafik verlinkt haben. Kurzum: Ich schätze die Zahl der Betroffenen alleine in Deutschland auf über 1 Million. Normalerweise führt bereits ein eingelagertes 1-Pixel-Bild von VG-Wort zu 1% Abzug bei der Mobilitätstauglichkeit.
Technisch ist das Problem übrigens von Google lösbar, indem die Firma ihre eigenen Grafiken im eigenen Statistikprogramm von dieser Mobilitätsberechnung ausnimmt. Dass man es bei anderen Zähl-Grafiken nicht macht, belegt, dass man es nicht will. Auch das ist kein Einzelfall.
Empfehlungen
Sämtliche Geräte - das hat mit Googles großspurig vertretenen Mobilitätskriterien überhaupt nichts zu tun - stellen Inhalte schneller dar, wenn sie bereits von früheren Aufrufen noch im Zwischenspeicher des eigenen Browsers abgelagert sind. Dazu kann es im Einzelfall von Vorteil sein, vieles lange dort speichern zu lassen. Fügen Sie deshalb auf Ihrem Server in der .htaccess folgende oder ähnliche Inhalte ein:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 day"
ExpiresByType text/html "access plus 1 day"
ExpiresByType text/php "access plus 1 day"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/x-javascript "access plus 1 month"
ExpiresByType application/javascript "access plus 2 months"
ExpiresByType image/x-icon "access plus 12 months"
ExpiresByType image/icon "access plus 12 months"
ExpiresByType text/xml "access plus 1 second"
</IfModule>
Google moniert fehlende oder zu geringe Werte. Abgelehnt wurden bei mir regelmäßig bei Bildern und CSS: second, minute, hour, day. Erst eine Woche (1 week) wird als ausreichend angesehen. Die Erhöhung auf month erbrachte jedoch keine weiteren Bonuspunkte. Bitte ausprobieren.
Man darf jedoch auch nicht einfach immer die Maximalzeit eintragen. Falls es zu Änderungen kommt, würden diese dann nicht oder zumindest nicht schnell genug beim Kunden sichtbar werden.
Es existieren deshalb keine Pauschalregeln. Jeder muss sich das selbst für seinen Auftritt genau überlegen. Grundsätzlich gilt: je schneller und häufiger Änderungen publiziert werden sollen / müssen, umso geringer sollte die jeweilige Cache-Zeit sein. D.h. vor allem für reine Testzyklen mit sofortiger Korrektur sollte man die entsprechenden Werte sehr kurz halten.
Sie müssen auch weder alle diese noch nur diese Zeilen eintragen. Das hängt jeweils von Ihrem Auftritt und den dort verwendeten Medien ab.
Das alles sieht komplizierter aus, als es ist. Die Regeln dazu finden Sie bei Apache. Singular und Plural der englischen Zeitbegriffe scheinen nicht so wichtig zu sein, da man auch viele gegenteilige Beispiele im Internet findet. Laut Apache kommt es sowieso nur auf die maximal ersten beiden Buchstaben jedes Wortes an.
Am 02.04.2014 bemängelte das Test-Tool jedoch selbst bei HTML-Dateien 24 Stunden / 1 Tag als zu kurz und gab sich erst bei 1 week zufrieden. Das ist jedoch entschieden zu lange für Seiten, die man aktuell halten will oder muss.
Hinweis: Einen wirklichen Einfluss auf die Nutzer haben Sie so jedoch nicht. Bei vielen - wie auch bei mir - wird beim Schließen des Browsers sicherheitshalber alles gelöscht. Das kann sich jeder Nutzer im Browser selbst konfigurieren. Aber es geht um Google und dessen angeblich so vorteilhafte Mobilitätsinitiative.
Komprimierung
Gute Provider komprimieren alle Daten automatisch beim Versenden. Bei anderen haben Sie oft keine Chance dies einzustellen, da dann meist auch der Zugriff auf die .htaccess fehlt.
Die Fehlermeldung bei Google lautet: Komprimierung aktivieren
Durch die Komprimierung der Ressourcen mit "gzip" oder "deflate" kann die Anzahl der über das Netzwerk gesendeten Bytes reduziert werden. - Ermöglichen Sie die Komprimierung der folgenden Ressourcen, um die Übertragungsgröße um # KB (## %) zu reduzieren.
Fügen Sie deshalb für deflate auf Ihrem Server in der .htaccess folgende oder ähnliche Inhalte ein:
# Deflate Compression by FileType
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE text/javascript
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/atom_xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-shockwave-flash
</IfModule>
Alternativ fügen Sie für gzip auf Ihrem Server in der .htaccess folgende oder ähnliche Inhalte ein:
<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>
Googles Arroganz
Wie sagte mir einmal ein Vorstandsvorsitzender eines großen Konzerns so treffend: Reichtum und Macht führen zu Arroganz, Faulheit, Dummheit, Unwissenheit und Unwillen.
Daraus darf man schließen, dass dieses Vorgehen wohl gezielt und von der Firmenspitze gewünscht und vermutlich sogar angeordnet ist.
Das Schöne an derartigem Verhalten ist jedoch, dass es bekannt wird, und Kunden sich einen Fremdanbieter suchen können. Google schadet sich so selbst. De facto werden - angesichts der Fehler in der Test- und Zertifizier-Software bei Google - fast alle derzeit existierenden Internet-Auftritte die willkürlichen und dazu noch ständig wechselnden Anforderungen Googles an Mobiltauglichkeit kaum erfüllen können. Als Ergebnis werden fast alle als nachteilig gebrandmarkt. Dazu sind derartige Kriterien jedoch nicht geeignet.
Wer ständig erfährt, dass für ihn angeblich ungeeignete Inhalte sich auf seinem Mobilgerät dennoch hervorragend darstellen lassen, wird Google nicht mehr glauben. Ein Vertrauensverlust ist im Internet jedoch gravierend.
Wird Google daraus Lehren ziehen? Nein. Großkonzerne tun sich schwer, Vorstandsentscheidungen zu revidieren.
Und es finden sich zahlreiche Belege dafür, dass Google schon seit Jahren jedes Interesse an Kundenmeinungen oder selbst Fehlerreparatur verloren hat. So weigern sich die Programmierer bei Google seit vielen Jahren auch, einen von mir mehrfach gemeldeten schweren Fehler im Browser Chrome zu reparieren.
Sinnvolle Optimierungen
Generell stellt sich die Frage: Wie weit soll man seine eigenen Internet-Seiten auf Googles Test-Werkzeuge hin optimieren.
Grundsätzlich benötigen Sie als fehlerfrei zertifizierte HTML-Seiten. Das führt nebenbei auch insgesamt zu einer höheren Platzierung bei Googles Suchmaschine.
Sie benötigen mehrere ausgelagerte und als fehlerfrei zertifizierte CSS-Style-Sheets für das Layout.
Sie sollten den neuen HTML-5 und CSS-3 Standard überall durchgehend verwenden. Für Bilder ist das Picture-Element und einer kleinen Bildvariante sinnvoll.
Die Seiteninhalte sollten derzeit auf 320 Pixel Breite zusammendrückbar sein - gleichgültig, wie das dann aussieht.
So können Sie - je nach Seite und Anzahl der Grafiken / Fotos darauf - bis zu über 90% Mobiltauglichkeit erzielen.
Da Google ständig an seinem Test-Werkzeug Änderungen vornimmt, kann ein Wert von 85% (gerade noch grün) bereits morgen als nicht mehr mobiltauglich gelten.
Sofern Sie jedoch mehrere Fotos auf einer Seite verwenden bzw. fremde Inhalte von extern laden, werden Sie niemals in der Lage sein, die 100% zu erreichen.
Meine Empfehlung lautet folglich: Merken Sie sich die am schlechtesten gerankte Seite Ihres Auftrittes mit allen Ergebnissen (am besten ein Screen-Shot erstellen) und vergleichen Sie die Testergebnisse einmal in der Woche oder im Monat mit den neuen Werten von Googles Test-Tool. Bei drastischen Verschlechterungen muss man nochmals Hand anlegen.
Dennoch konnte man 2015/16 aufgrund der vielen Fehler bei Google keine Seite mit vielen hochwertigen Fotos als mobiltauglich zertifiziert erhalten.
Und zur Relativierung der Zahlen: Bei mir führen bereits eine ausgelagerte CSS-Datei und eine 1-Pixel-Grafik von VG-Wort (beides eklatante Fehler des Google-Test-Tools) zu je nach Lust und Laune des Test-Werkzeugs ca. 10% Abwertung bei Google für die Mobiltauglichkeit. D.h. 90% und leicht darüber sind bereits Spitzenwerte.
Gesunder Menschenverstand
Wenn schon Google und deren Mitarbeiter in Punkto Mobilitätskriterien jeglichen Bezug zur Realität verloren haben, so behalten Sie ihn bitte.
Analysieren Sie Ihre Kern-Zielgruppe. Man muss nicht auch noch den ärmsten Interessenten irgendwo auf der Welt zufrieden stellen, der sowieso nie bei Ihnen einkauft. Erstellen Sie deshalb einen Auftritt für die Geräte und die Wünsche Ihrer Kern-Zielgruppe.
Verwenden Sie sauberes, als fehlerfrei zertifiziertes HTML 5 sowie CSS-3. - Vermeiden Sie auf jeden Fall fehlerhafte HTML-Anforderungen Googles.
Wenn Sie JavaScript verwenden, dann bitte nur wirklich weit verbreitete Standard-Tools, die von deren Herstellern weiterhin gepflegt werden. Altes JavaScript wird schnell zur Sackgasse oder Sicherheitslücke.
Wer sauberes HTML-5 und saubere CSS-3-Style-Sheets verwendet, benötigt oft kein oder nur wenig JavaScript für seine Kernzielgruppe.
Ignorieren Sie unsinnige Forderungen von Google.
Schalten Sie Ihr Gehirn ein, bevor Sie übereilt unsinnige Aufträge an Google erteilen. Ja, richtig gehört. Google bietet nämlich auf seinen Seiten mit den Fehleranzeigen Ihrer für Mobilgeräte angeblich katastrophalen Internet-Auftritte auch kostenpflichtige Hilfen an. Früher war so etwas in Deutschland verboten: Unsinn zu verbreiten bzw. angebliche Fehler erst selbst zu produzieren und dann für die Behebung dieser angeblichen Mängel Geld zu verlangen. Solche Fälle wurden früher von Eduard Zimmerman in seiner Fernsehserie Vorsicht Falle - Nepper, Schlepper, Bauernfänger
an den Pranger gestellt.
Runderneuerung
Allerdings gelten auch folgende Details:
Wenn Sie durch die E-Mails und Warnungen von Google beunruhigt sein sollten, so schauen Sie sich Ihren Auftritt unbedingt einmal an. Die meisten Eigentümer wissen tatsächlich nicht, in welch altem Zustand ihr Auftritt ist.
Falls Ihr Auftritt noch folgende überholten Kriterien erfüllt wie z.B. HTML-4 oder niedriger, keine ausgelagerten CSS-3 Style-Sheets bietet, kein als fehlerfrei zertifiziertes HTML verwendet, kein als fehlerfrei zertifiziertes CSS nutzt, hingegen Tabellen-Layout / Tabellen-Struktur, Tabellen zur Gestaltung des Layouts benutzt und sich Handformatierungen im Textteil finden - also kein getrenntes Layout vom Text-Inhalt existiert, dann sollten Sie ernsthaft über einen Relaunch nachdenken.
Derart alte Auftritte kann man nicht mehr für Mobilgeräte optimieren / reparieren. Aufwand und Kosten lägen höher als bei einem kompletten Neuauftritt.
Fehlerfreie, moderne Internet-Auftritte führen nebenbei grundsätzlich zu einer wesentlich höheren Platzierung bei Google und allen anderen Suchmaschinen.
Fragen
Ihren eventuellen Fragen schenke ich gerne meine Aufmerksamkeit.
Bitte haben Sie jedoch auch Verständnis dafür, dass ich Ihnen weder eine kostenlose Analyse Ihres Auftrittes, noch eine kostenlose Restrukturierung Ihres alten Auftrittes anbieten kann.
Ferner bitte ich alle Mitarbeiter(innen) von Google und deren bezahlte Schreiberlinge sowie Claqueure von den üblichen Flames, wie das kann nicht sein
, das stimme nicht
Google wäre wunderbar / perfekt
etc. abzusehen. Ich habe diese Dinge vor Zeugen wochenlang mit verschiedenen Systemen getestet.
Nachtrag: Mit den Jahren wurden die Fehler geringer. Jedoch erhalte ich bis heute E-Mails mit völlig unsinnigen Hinweisen, dass bestimmte (seit Monaten nicht veränderte) Inhalte plötzlich nicht mehr indizierbar etc. seien. Ignoriert man diese Falschmeldungen, dann werden andere Seiten moniert. Es ist dennoch völlig zwecklos, sich Sorgen zu machen oder diese sowieso immer korrekten Seiten zu verändern. Vorher wurden und auch danach werden sie wieder als korrekt indiziert.