Beiträge von Synonym

  • PageSpeed Insights - Chrome Dev Tools - Lighthouse

    So, die Geschwindigkeit einer Seite ist ja wichtig, aber Google scheint die Schraube immer weiter anzuziehen. Aktuell sind sie bei bestimmten Dingen bei 20ms! Derzeit am wichtigsten ist der FCP (First Contentful Paint), wird es aber wohl nicht mehr lange sein. Es gibt wohl einen Wechsel hin zu FID (First Input Delay). Die Begründung: Dem User sei es nicht so wichtig, ob schon alles geladen ist, der fängt auch schon an zu scrollen und lesen, wenn die Seite noch lädt. Genau das ist der FID, also der Zeitpunkt, wo eine Seite normal auf Eingaben, Maus-Scroll oder Wisch-Gesten reagiert, egal ob sie fertig geladen ist oder nicht.

    So, um das zu erfassen für sich als User gibt es die "PageSpeed Insights", da wird das aufgelistet. Seit einigen Wochen auch als Beta in der Google Search Console.

    Gerade beim FID ist Google aber nicht in der Lage, diese Daten per seinen Google-Bot zu erkennen, denn der scrollt oder wischt nicht, der ruft nur die Webseite ab. Die Daten stammen aus dem "Chrome User Experience Report", der seinerseits nichts anderes ist, als übermittelte Telemetriedaten von Chrome Desktop und Mobile.

    Warum ich das scheibe? Weil die "PageSpeed Insights" in dem Bezug schon veraltet sind. Die arbeiten noch mit Version 4, der "Chrome User Experience Report" mit dem in Chrome integrierten Lighthouse und das ist dort in Version 5. Und ich sehe deutliche Unterschiede. Anfangs dachte ich noch, mein FID von 620ms liegt am Rechner, am Browser, wegen der Auslastung, aber nein, denn das SEO-FOrum hat einen Wert von 120ms. Komisch bei mir. Selbst eine leere weiße Seite hat über 500ms.... Hm, muss da wohl mal suchen warum, habe keine Ahnung. Die Search-Consele gingegen, die Lighthouse v4 Benutzt, die sagt 20-80ms, also schon ein deutlicher Unterschied, wobei die anderen erfassten Werte quasi +-10ms bei beiden identisch sind.

    Was ich bisher weiß, um den FID zu senken, mal abgesehen von Server:

    CSS ausmisten und komprimieren (komprimieren alleine ist gut, aber reicht nicht)

    JS ausmisten und komprimieren (komprimieren alleine ist gut, aber reicht nicht)

    Im CSS auf Transition oder Transform verzichten (macht oft eh keinen Sinn. z.B. LazyLoad. Warum soll das Bild animiert geladen werden, wenn das doch eh im Hintergrund ist und keiner sieht?)

    Neu ist auch die Barrierefreiheit. Bisher bezog sich die auf Element-Größen, also Schriftgröße von Links, Buttons und so, also ob man die eindeutig anklicken kann oder vielleicht aus Versehen einen falschen Link erwischt.. Neu ist die Auswertung der Farben, also Hintergrund und Vordergrund, ob die passen, gut leserlich sind. Dazu dient aktuell der Standard "WCAG 1.4.3" (WCAG = "Web Content Accessibility Guidelines" oder auch zu Deutsch "Richtlinien für barrierefreie Webinhalte"). Erstaunlich, was da so alles bemängelt wird, wo ich selbst absolut kein Problem sehe und ehrlich gesagt nach der Änderung auch keinen Unterschied ?!

    Schön ist aber, dass sowohl Chrome als auch Firefox in der Console mit Inspektor oder Elements nun auch anzeigen, wie gut ein Farbwert ist. Wählt man also eine Farbe, dann kommt da ein rotes X für "schlecht", ein einfacher grüner Haken für "gut" und ein doppelter Haken für "sehr gut". Wie gesagt, ich habe meine Farbwerte nun auf einigen Seiten geändert und bin nun bei "gut". Lighthouse meldet eine bessere Barrierefreiheit, ich sehe aber nicht wirklich einen Unterschied.

    Ebenfalls neu die Auszeichnung von Links und vor allem verlinkten Bilder per "aria-label". Auch das geht aus dem WCAG hervor. Es dient der Vorlesung von Links oder eben der Beschreibung von Zielen für Screenreader. Auch das hat Lighthouse 5 nun neu in der Auswertung.

  • Lazy-Loading: Javascript, IntersectionObserver oder nativ per loading="lazy" Attribut?

    Mal als Anmerkung:

    Bei bLazy oder eben anderen individuellen Javascripten für Lazyload wird ein Bild so eingebunden:

    <img class="b-lazy" src="data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==" data-src="/bilder/webseite/geranium-zweifarbig-k.jpg" title="Geranium zweifarbig" alt="Geranie zweifarbig in weiß-rosa" width="300" height="225">

    Das im "src" ist in dem Fall eines der derzeit kleinsten Bilder (gif), das man inline einbinden kann. Ist bei allen Bildern eingebunden, muss also nur einmal geladen bzw. verarbeitet werden. Wenn das Lazy-Load-Script nun erkennt, dass das Bild in die Nähe des Viewports kommt, dann ersetzt es "src" mit "data-src" und das Bild wird eigentlich erst geladen. Der IntersectionObserver arbeitet genauso, ersetzt also auch, aber er ist auch eine native Browser-Funktion, die nicht ständig das "Scroll-Event" überwacht. Nur mal so als Beispiel: Ein kleiner Roll mit der Maus-Rolle ist in der Regel 60 bis 100 Pixel. Das Scroll-Event würde also 60 bis 100 Mal eine Zustandsänderung "abfeuern", nur für eine Rad-Bewegung. IntersectionObserver achtet nicht darauf, der achtet darauf, was im Browser wirklich im oder am Viewport ist.

    Für das neuen loading="lazy" Attribut schaut das HTML aber so aus:

    <img loading="lazy" class="b-lazy" src="/bilder/webseite/geranium-zweifarbig-k.jpg" title="Geranium zweifarbig" alt="Geranie zweifarbig in weiß-rosa" width="300" height="225">

    Die SRC ist also direkt angegeben. Der Browser, der das kann, der verhindert das Laden des Bildes, bis es in die Nähe des Viewports kommt. Wenn es in der Nähe ist, dann lädt der Browser erst mal mehr oder weniger die Meta-Daten des Bilder und nicht das Bild selbst. Meta-Daten nur, damit Breite und Höhe positioniert und gerendert werden können. Kommt es dann in den Viewport, dann lädt er das Bild. Das hat den Vorteil, dass das "Zucken" von Webseiten weg ist, denn der Browser weiß vorher, wie groß das eigentliche Bild ist. Das vom Platzhalter hat ja meist andere Dimensionen, in der Regel 1x1 und eben nicht 4x3 oder 16x9 oder sonst was.

    Da nun aber das Bild direkt im SRC steht gibt es anscheinend keine Möglichkeit, das mit Lazyload per Javascript zu kombinieren, als Fallback. Oder hat einer eine Idee?

  • Maus und Tastatur ausgefallen

    Das darfst Du mich nicht fragen. Ich hatte damals dann erst mal normale schnurgebundene dran gehängt. Dann den Dongel der Tastatur nach vorne an den Rechner. Nach ein paar Tagen ging die Funk-Tastatur plötzlich wieder. Dann die Maus per Kabel abgezogen und den Dongel von der dran. Ging dann auch wieder. Seit dem wieder keine Ausfälle.

    Ich habe also keinen Schimmer, was das war. Ich vermute nur immer noch irgendwas mit einer Funkstörung, die von außen rein kommt. War ja nicht das erste Mal. Nur sonst viel eines von beiden Geräten aus und nicht beide gleichzeitig.

  • Lazy-Loading: Javascript, IntersectionObserver oder nativ per loading="lazy" Attribut?

    So, mal wieder was aus dem Bereich Codes. Lazy-Loading von Bildern und Co. Was ist da denn derzeit so angesagt bzw. lässt sich kombinieren? Aktuell verwende ich eigentlich bLazy als fertiges Script. Performant ist das aber nicht wirklich, da es auf Scroll-Eigenschaften im Browserfenster reagiert und die somit ständig auswerten muss, ob ein Bild nun kommt oder nicht, er muss auswerten, wenn sich das Sichtfeld bewegt.

    Daher habe ich nun schon seit 2 Jahren IntersectionObserver am laufen, die eigentlich zu 90% funktionieren. Wenn nicht, dann gibt es einen Fallback zu Lazy-Loading mit Scroll-Überwachung.

    So, nun stößt Chrome und Opera vor und hat das ganze nun seit 3 oder 4 Versionen nativ im Browser, würde also gänzlich ohne Javascript funktionieren. Nur irgendwie scheitere ich da an einer Art Polyfill oder Abgrenzung, was wann wie genutzt wird. Klar, die Erkennung davon, was möglich ist, habe ich, das bringt aber nichts, weil Bilder rein HTML-technisch anders eingebunden werden müssen.

    Für das bisherige Lazy-Loading wird als "src" nur ein Platzhalter gesetzt und die eigentliche URL kommt in "data-src". Ist das Bild dann nahe dem Sichbareich, werden die beiden Angaben getauscht, das Bild geladen.

    Mit dem loading="lazy" Attribut muss die URL aber im "src" bleiben, nur dann kann sie geladen werden, sonst kommt nur der Platzhalter. Und genau hier scheitere ich gerade.

    Hat einer eine Idee?

    Klar könnte ich sagen, wenn loading="lazy" vorhanden ist, also ('loading' in HTMLImageElement.prototype) === true, dann soll das Script, das das Vorhandensein der Funktion testet, alle "data-src" nach "src" kopieren und den Rest dann dem Browser überlassen. So wie ich das aber bisher gesehen habe ist das einfache kopieren von "data-src" nach "src" von der Performance her schlechter, also es so zu lassen wie es ist und den IntersectionObserver machen zu lassen.

    Mir scheint fast, als ob da was auf dem Markt kommt, das absolut nicht abwärtskompatibel ist. Fakt ist, wenn das HTML dazu passt, dann ist das neue loading="lazy" schneller und belastet den Browser weniger. Nur wenn man sein HTML direkt so erstellt, dann hat man keine Chance mehr für einen Fallback.

    Einer eine Idee? Übersehe ich was?

  • Search Console: Leistung Bericht -> Klicks

    Diese Standard 3 Monate habe ich sonst auch. Und ich kam nie auf die Idee, die in der Liste mal zu summieren, da a) zu viel und b) da eh nur 1000 drinnen stehen. Aber bei kurzen Zeiträumen oder eben kleineren Seiten mit weniger Zugriffen geht das dann halt schon. Genau wegen den Zweifeln fragte ich hier ja nach, welcher Wert denn nun passender sein kann. Piwik wird mit der ganzen Datenschutzgeschichte ja immer ungenauer oder zählt teilweise gar nicht. Und die Quelle ist eben die Search Console. Hatte Google ja damals gesagt, als die Übermittlung der Keys aus den Serps so gut wie eingestellt wurde - man soll die Console nehmen. Aber das ist halt alles irgendwie alles andere als genau.

  • Search Console: Leistung Bericht -> Klicks

    Nee, das stimmt auch von hinten und vornen nicht. Bei einer anderen sagt er mir 153 und zeigt 42 an. Das kann man aber noch summieren per Hand. Wieder eine andere 1663 und in der Liste sind grob geschätzt 700-800. Stutzig macht mich nun aber auch der Wert 1663, denn die Domain hatte gar nicht so viele Seitenzugriffe, wie Google da an Klicks angibt und bei meinen erfassten Seitenzugriffen ist alles andere eben auch mit dabei, nicht nur Google.

  • Bedienungsanleitung SEO NW Forum

    Die Zitatfunktion aus den Buttons des Editors heraus funktioniert hier anders. Früher klickte man auf "Zitat" und dann tippte man in das Feld. Heute ist es umgedreht. Man muss erst tippen, den Text markieren und dann "Zitat" auswählen. Schreibt man erst und klickt dann Zitat an, ohne was zu markieren, dann wird der ganze eigene Post zum Zitat ;)

  • Forum bekommt neues Gesicht - WBB

    Ebenfalls ungetestet: Unterseiten der Foren.

  • Forum bekommt neues Gesicht - WBB

    Pagination an sich ist hier leider fehlerhaft bzw. habe ich einen Fehler gefunden. Es gibt z.B kein /forum/board/41-google-forum/?pageNo=64 , vorher schon, also Seite 64. Er zeigt nun aktuell die letzte Seite an, also Seite 41. Gleichzeitig ist aber der Canonical auf Seite 64 gesetzt. Also das System sollte entweder weiterleiten oder den Canonical auf die letzte Seite setzen, so ist das aktuell leider falsch, aber marginal, betrifft nur die letzte Seite.

  • Forum bekommt neues Gesicht - WBB

    Ungetestet !!!

    Soll nur die Hauptseiten der Foren weiterleiten. Unterseiten durch Pagination fehlen da.

  • Search Console: Fehlende interne Links + Spam Links eddiecheever.net & Co.

    Zitat von Alex07

    Das sind meine Spammer. Also Synonym, beim Melden kann ich dich unterstützen. Wäre cool wenn wir uns da absprechen könnten damit diese Spam Links entwertet werden bzw verschwinden.

    Gerne doch. Ich fing nun aber erst mal mit Cloudflare an, denn das ist einfacher. Da kann man eine Liste an Seiten senden. Bei Google muss man die zusammenbasteln und dann auch noch alles jeweils ausdrücklich erklären. Btw, hast Du den Post nachträglich geändert? Ich schrieb ja extra das mit dem DMCA und "kompliziert", weil ich das vorher bei Dir gar nicht gelesen hatte.

    Bei CF ging nun nur eine Zielseite von mir raus und als Quelle nur eddiecheever.net , eben mit denen wie diese eine Seite das Ziel ist. War am einfachsten, da einfach Search Console auf, Zielseite der Links öffnen und dann alle Links kopieren. Das ganze dann einmal erklären.

    Und ja Alex07 , das geht öffentlich und landet dann bei lumendatabase.org (bin da schon mehrfach vertreten). Die eigene Postanschrift nicht, aber der eigene Name / Firma, die Begründung, der URL des Kopierers und die des Originals.

    Die erste Meldung ging nun auch an Google raus:

    Ach ja, man muss auch nicht den Umweg über die Auswahlen von Dir gehen. Google hat dafür ein Dashboard: https://beispiel.rocks/www.google.com…/dmca-dashboard