Laut (Link nur für registrierte Nutzer sichtbar.) ist neben den offensichtlich recht lange ladenden Bildern und Design auch die Server-Performance eine Spaßbremse,.... Die Startseite ist auch sehr voll, Slider, zig Bilder, das ganze oben beschriebene Gemüse, da kommt dann unterm Strich einiges zusammen. Das würde ich etwas abmagern, notfalls die ganzen Produkte auf der Startseite in einen Slider bzw. wechselnde Angebote, das geht z.B. recht leicht mit der maximalen Anzahl an Top-Produkten auf der Startseite (z.B. 36Top-Produkte, aber es werden immer nur 12 angezeigt). Die einzelnen Produktseiten sind aber auch nicht viel schneller, Die Optimierung der Produktbilder zu modernem Format wie WebP bei GUTER Qualität ist da sicherlich schon sehr wirksam, einfach die Bilder verkleinern macht nur die Qualität kaputt. Wie wichtig Performance ist (Smartphone mit 3G-Geschwindigkeit...) und im Sommer wird, darüber wird viel geschrieben. Wenn Google da Dinge ankündigt und für wichtig befindet, versuche ich jedenfalls, die Empfehlungen umzusetzen, @Wilken.
P.S.: "...Ladegeschwindigkeit: Wir haben keine Korrelation zwischen der Geschwindigkeit beim Laden von Seiten (gemessen von Alexa) und dem Google-Ranking der ersten Seite gefunden. Dies könnte sich mit Einführung der „Page Experience“ als Ranking-Faktor aber ändern...." (Link nur für registrierte Nutzer sichtbar.)
@barbara du hast natürlich recht das wenn der Rest nicht passt ich trotzdem hinten dran steh. ABER wenn wiederum die Geschwindigkeit nicht passt und Google die Seite nicht für "ernst" nimmt, weil die Konkurrenz schnellere Seiten hat. Dann kommen wir auch nicht weiter, wir "verbrennen" zur Zeit täglich 100€ bei Google Ads und wunderten uns wieso wir trotzdem in unserer Region auf der 1. Ergebnis Seite bei der Google Suche ganz unten Erscheinen. Unser 1. Punkt ist nun die Seite schneller zu bekommen und danach Schritt für Schritt alles andere angehen. @Wilken (Gambio) Ja bald fließt die Geschwindigkeit noch mehr ins Ranking und da wollen vorbereitet sein, da kann es eben nicht sein das andere Shops weit über 80 Punkte (Prozente) bei PageSpeed haben und ich mit meinen 45 Punkten rumdümpel. Ja evtl. liegt es auch nicht komplett an Gambio , ich möchte aber auch nicht meine komplette Startseite ausdüngen und allen Artikeln nur 1 Bild zuordnen um besser zu Ranken, dann habe ich keinen Mehrwert für den Kunden. Ich wundere mich nur wieso es bei anderen Shops geht und bei den Cloudshops (oder Gambio allgemein) nicht. Ich würde gerne andere Bildformate nutzen wollen oder auch LazyLoading. Ich glaube da steckt noch potenzial drin. @deotest Okay, ich werde nochmals versuchen ein paar Sachen von der Startseite runter zu nehmen. Aber auch die Artikelseiten sind echt langsam. Ich weiß nicht wieso ? selbst ein Artikel mit nur einem Bild und kaum Text ist nicht viel schneller. Ich bin sehr dankbar für jede Hilfe und lasse mich auch gern belehren, wenn wir das zusammen hinbekommen könnten wäre ich eine große Sorge los.
Lazy Loading und WebP-Bilder soll meines Wissens bei Gambio bald kommen, wenn ich es richtig in Erinnerung habe. Schade, dass die Ladezeitoptimierung von Werbe-Markt.de nicht auf Cloud-Shops läuft, vor der Installation war meine Shop-Seite auch nicht besser, aber dank des Moduls jetzt wirklich gut geworden, und auch spürbar mehr Besucher und Bestellungen. Heute: GTmetrix Grade Performance 87% Structure 71% Web Vitals Largest Contentful Paint 1.5s Total Blocking Time 0ms Cumulative Layout Shift 0 Das ist noch nicht der Weisheit letzter Schluss, das honeygrid-Template lädt viel Zeug, was gar nicht benötigt wird, soweit ich das überhaupt beurteilen kann, und ein paar kleine Bremsen mit JS, links, Bildern usw. habe ich auch noch drin, aber ich bin aktuell sehr zufrieden damit.
Hier mal ein Beispiel, selber Artikel, selbe Beschreibung aber riesen Unterschied. WIESO? Quelle 1 : (Link nur für registrierte Nutzer sichtbar.) mein Shop : (Link nur für registrierte Nutzer sichtbar.) Speedtest Quelle 1 : (Link nur für registrierte Nutzer sichtbar.) Speedtest mein Shop : (Link nur für registrierte Nutzer sichtbar.)
@deotest Ja schade das das Modul nicht läuft in Cloudshops. ABER wenn es ein Programmierer schafft es mit einem Modul hinzubekommen, dann sollte es doch auch für Gambio möglich sein wenigsten die Grundlegenden Sachen zu optimieren. Mir nützen tolle Eigenschaften oder Attribute oder viele Zahlungsmöglichkeiten oder Versandarten oder oder oder sehr wenig wenn keiner den Shop findet. Ein Modul um mehrere Zahlungsarten oder Versandarten anzubieten für einen Shop der Tip Top rankt macht doch meiner Meinung mehr sinn. Das ist aber nur meine Sichtweise.
Die Antwort steht teilweise dort, die Bilder und die Schriften brauchen ewig zum Laden, da ist noch viel Optimierungsbedarf, der relativ leicht befriedigt werden kann.
@deotest wo lese ich das raus das z.b. die Schrift lange lädt? das mit der Schrift würde mir sogar gut einleuchten. Und Bilder ? ja muss ich wirklich jedes Bild soooooo verkleinern um den Shop Konkurrenz fähig zu halten? Ich setze mich mal ran und werde die Bilder mal verkleinern und Komprimieren bin zum maximum.
Wenn Du runterscrollst bei pagespeed, stehen dort ja die Änderungsempfehlungen, teilweise sehr pauschal. Bei gtmetrix in der Waterfall-Ansicht sieht man es sehr schön, wie lange jedes Bildchen usw. braucht. So oder so ist die Optimierung eine ganzjährige Daueraufgabe, ich würde da einfach auch Dinge ausprobieren und nach genügend caches leeren und etwas warten die Performance vergleichen. Das schwankt ja auch erheblich je nach Besucheranzahl bzw. Server-Last, ich habe auch nur webspace bei all-inkl.de und zur rush hour geht die Leistung auch in die Knie. Das müssen auch gar nicht Benutzer im eigenen shop sein, sondern auf dem gleihen Server angemietete Plätze, da kann man selber gar nichts dran machen, außer mal mit den Support sprechen, ob da evtl. ein Schräubchen gedreht weden kann (größerer cache pro Nutzer, SSD-Festplatte für Datenbank optional o.ä.)
Nochmal kurz ein paar unserer Sichtweisen: Uns ist Seitenladegeschwindigkeit ein Anliegen. Die finden wir wichtig, daran rüttelt niemand. Das Wort direkt ins Englische übertragen ist Pagespeed. Damit ist uns Pagespeed auch wichtig. Google hat ein Tool, das Seitenladegeschwindigkeit messen soll. Der Versuch sowas zu bauen ist ehrenhaft und richtig fürs Web, allerdings hat das Tool aus unserer Sicht massive Schwachstellenm, so dass dessen Ergebnisse häufig leicht bis sehr oft schwer unbrauchbar sind. Weil wir das so sehen, ist uns relativ egal ob da viel oder wenig Punkte rauskommen, uns fehlt die Aussagekraft. Wir optimieren also für Seitenladegeschwindigkeit. Wir optimieren nicht für Google Pagespeed Insights. Und wenn uns jemand sagt er ist da gut oder schlecht, dann führt beides bei uns nicht ganz selten zu einem Schulterzucken. Wir glauben auch: Bei jedem anderen Anbieter für so ein Tool als dem Google Konzern wäre den meisten Leuten gut erklärbar, warum das nichts taugt. Wenn irgendwo Google dransteht, vermuten aber viele insgeheim höchste Unfehlbarkeit und massive Rankingsauswirkungen. Beides ist in Wahrheit Unfug. Es macht auch keinen Unterschied für ein Seitenranking ob ich ein Iphone oder ein Android Handy habe. Oder für die organische Suche ob ich Google Ads schalte oder eben nicht. Es hängt nicht alles auf dieser Welt direkt und hart zusammen. Richtig ist: Die Google Oberen haben ausgegeben, dass Seitengeschwindigkeit ein Kriterium für Ranking werden muss. Das ist eine rationale und kluge Entscheidung. Das geht dann die Stufen in den Google Konzern hinunter. Zu den Crawler Leuten, die damit etwas zu machen versuchen. Zu den Leuten, die andere Projekte wie Google Pagespeed Insights bauen (die nicht die Crawler Leute sind...). Jeder macht seins draus. Alle haben die gleiche Losung, aber nicht zwingend eine synchronisierte Arbeitsweise oder Teilung der Ergebnisse am Exemplar. Seitengeschwindigkeit wird nun in Form der Webvitals in Mitte 2021 ein Rankingkriterium werden. Was die Webvitals sind, ist erklärt, zum Beispiel hier: https://t3n.de/news/web-vitals-googles-kennzahlen-1276677/ Die kann man ruhig mal messen. Mit denen kann sich ruhig mal Mühe geben. Man muss aber auch Wissen, wo bis heute Themen offen sind... Es geht bei Webvitals zum Beispiel hart um Zeit. Nur wie werden die gemessen? Auf welcher Basis? Ein erster Eindruck des Problems: Nehmt eine Seite und messt sie zweimal. Einmal auf der Pagespeed Insights Seite und einmal bei euch im Chrome Browser. Dort kann man F12 drücken, in der Konsole oben auf Lighthouse klicken und eine Seitenperformancemessung für Endnutzer direkt im Browser machen. Dann lädt der die Seite runter und misst sie auf eurem System. Die Pagespeed Insights Seite basiert aktuell auch zum allergrössten Teil auf Lighthouse, ihr werdet da aber sehr oft deutlich niedrigere Werte rausbekommen, zumindest wenn euer PC nicht Asbach Uralt ist und eure Internetleitung brauchbar. Für die Pagespeed Insights Webseite fragt ganz oft die Google Cloud von irgendwo überm Teich eure Seite ab, da bezahlt man allein die Transatlantikverbindung schon mit Ladezeit, die die Ergebnisse schmälern. Was gilt? Die Google Crawler für dier Suchmaschine stehen für hier stehen übrigens zum grossen Teil in Europa, weil das für Google kosteneffizient ist. Das vermeidet Unmengen an Traffickosten. Die Pagespeed Insights Webseite ist zu klein um die tausendfach geoglobal redundant und intelligent aufzubauen, also macht mans da nicht. Wie wird das also wohl fürs Ranking laufen? Abseits von diesem Problem gibt es viele weitere. Pagespeed Insights für zum Beispiel oft dazu, dass Leute blindhörig ihre Bilder so matschig komprimieren, dass dass Tool einen grünen Haken gibt. Jeder Kunde rennt aber schreiend weg oder versucht den Sender an seinem PC-Bildschirm neu einzustellen, damits scharf und einladend wird. Es werden vielfach auch Optionen vorgeschlagen, die nicht in allen Browsern laufen, damit könnt ihr auch super mögliche Kunden vergraulen. Und und und... Wer der Google Pagespeed Insights Webseite also blind hörig ist, ist aus unserer Sicht schlecht beraten. Es gibt da auch richtige Sachen, aber eben auch viele in ihrer Konsequenz glaubwürdig falsche Empfehlungen. Wir folgen einigen Dingen von da, anderen werden wir nie folgen. Das bedeutet, dass es komisch wäre, wenn jemand ganz miserabel abschneidet, weil etwas Schnittmenge wie gesagt da ist. Das bedeutet aber auch, dass niemand leicht sehr gut abschneidet, weil wir ein paar Sachen anders sehen und anders optimieren, darum werden immer Faktoren die da gesucht sind auf Gambio Shops nicht zutreffen. Der Rat wäre: Vergesst die Gesamtpunktzahl der Webseite da. Was da rauskokommt ist so wichtig für euch, wie ob ich Rewe Treuepunkte habe oder nicht. Seht euch die Einzelempfehlungen an, die das Ergebnis zusammensetzen. Jede einzelne davon kann man sich ansehen, gegenprüfen, hinterfragen und diskutieren. Einige sind gute Ratschläge, andere sind grottenschlecht. Darüber kann man gut diskutieren und sich was ziehen.
Ich bin zwar kein SEO-Experte, aber schau Dir mal den Footer aus dem Vergleichsshop an. Da sind keine Bilder die von irgendwo extern geladen werden. Dann wird kein weiterer Artikel angezeigt - bei Dir ist aber einer Es gibt keine social-Media-Button Und dann das, was ich gestern mit der Komprimierung meinte. Das Originale Bild bei Dir hat 37,6kb (bei 587 x 587px) Das Info-Bild hat 51.6kb (bei 350 x 350px) Das PopUP sogar 215kb Du musst die Bildkomprimierung im Shop einstellen, oder alle Bilder aus images/product_images/info_images/ images/product_images/gallery_images/ images/product_images/popup_images/ images/product_images/thumbnail_images/ manuell komprimieren.
@Wilken (Gambio) oft wird der Preload key requests im Lighthouse angemeckert die Ladezeit webfonts (so ca. 4,71s in der mobilen Ansicht auf der Startseite/ zum vergleich auf Desktop sind es 0,88s) Nun wurden bis Version 3.10.xx im Honeygrid diese Fonts "font-awesome" verwendet irgenwann hatte ich dann die "fontawesome-free" im Shop...wie kann man die optimieren?
Das ist ja einer der Knackpunkte, die bei Gambio bremsen und bei nicht superoptimalen Bildern, fonts laden aus dem web, langsamer Inet-Verbindung auf Smartphones etc. das Gambio-Erlebnis zum Abspringen des Kunden führen. Googles Pläne und Wilkens Wünsche und Meinungen hin oder her, das ist die Erfahrung vieler Nutzer, die Kunden rufen ja oft an dann.
Das ist doch eigentlich Dominik Spätes - Werbe-Markt.de Thema, habe schon länger nichts mehr von ihm hier gelesen, liegts an der Ausgangssperre in Bayern??
So steht das da bestimmt, aber so ist das auch grober Unfug behaupte ich. Schauen wir das mal an. Preload Key Requests bedeutet: Man zeichnet im HTML direkt weitere Elemente aus, die man gleich benutzen möchte, und erst in Folge geladen würden. Der Unterschied ist also: Man hat HTML, dadrin wird eine CSS Datei eingebunden. In der CSS Datei stehen dann zum Beispiel Schriften, die benutzt werden sollen, und dadurch verursacht wiederum nachgeladen werden sollen. Die tiefe der Kette ist also HTML lädt CSS lädt Schrift. Die Idee ist: Man lädt die Schrift im selben Moment wie das CSS, dann sind die dann pi mal Daumen gleichzeitig da. HTML lädt CSS und Schrift, CSS benutzt Schrift. Man vermeidet also den "im Gänsemarsch nacheinander-Effekt. Das gilt so nicht nur für Schriften, das kann man auch für Bilder machen, die durch CSS geladen werden. Oder Dinge wie ein Javascript, das immer anderes Javascript oder wieder Bilder oder JQuery oder weiss der Himmel was lädt. Das soll man nicht für alles tun, weil das einen gegenteiligen Effekt auslösen kann, aber für wichtige, grössere Dinger. Der gegenteilige Effekt entstünde dann wenn man das Parallelitätslimit des Browsers und der Verbindung übersteigen würde, und die wichtigsten Layoutelemente für die grobe Layoutarbeit damit eventuell erst später geladen würden, was die Seitenladezeit fürs Auge sichtbar erhöhen würde. Key Requets vorab zu laden ist grundsätzlich eine gute Idee, das könnten wir auch an einigen Orten machen. Wir habens bis heute nur dewegen nicht, weil uns der reale Effekt in der Praxis einfach nicht so hoch vorkommt, dass das schon jemand bei uns mal automatisiert gebaut hätte. Von Hand könntest du sowas zum Beispiel über die Trackingcodes für den Headbereich der Seite machen, wobei das für Google Fonts im Shop keinen Riesenspass macht, weil die Pfade im Fontcache nicht stabil sind, das war da nie Designkriterium... Jetzt messen wir aber mal an einem Praxisbeispiel etwas herum um die möglichen Gewinne einer Maßnahme zu bewerten. Ich nehme den Shop von Michael zum Benchmark, der hatte die Frage gestellt. Ich schliesse mein Android Mittelklassehandy per USB Kabel an meinem PC, öffne den dortigen Standardchromebrowser, verbinde eine Debuggerkonsole damit und schalte am Handy WLAN ab, damit sich das Ding alle Daten ausm Mobilfunknetz mit den dortigen Latenzen holt. Damit bewaffnet lade ich Michaels Startseite bei deaktivertem Browsercache. Das Ergebnis, das wir gleich etwas bewerten, sieht dann so aus. Das Ding bewerten wir jetzt mal etwas im Detail. Ale erstes bite ich wahrzunehmen, das oben "Disable Cache angehakt ist." Wir sehen also das, was ein Besucher sieht, der eine erste Seite des Shops zum ersten mal lädt. Werfen wir kurz einen Blick auf die Gesamtladezeit der Seite mit allen Elementen: Nach 2,26 Sekunden ist alles geladen, nach 2,84 Sekunden hat der Browser auch den letzen Rest verarbeitet und gerendert. Eine Optimierung soll nun 4,71s sparen. Kurze theatralische Stille. Darf da sein, finde ich. Damit würde die Seite also gegenüber meiner empirischen Messung hier in -1,87 Sekunden laden. Die Zahl die Google Pagespeed Insights da als möglichen Gewinn angibt ist eine komplette Mondzahl. Protestiere wer mag und Argumente hat, aber das ist schon hart daneben aus meiner Sicht. Machen wir aber nochmal etwas Wissenschaft. Wir wissen: Browser lädt HTML. HTML enthält Verweis auf CSS Datei, Browser lädt CSS Datei. CSS Datei enthält Links auf Schriften,Browser lädt Schriften. Wir sollen die Kette von 3 Stufen auf 2 Stufen kürzen, um schneller zu sein. Um zu wissen was wirklich herauskommen könnte, hilft der Wasserfall im Debugger. Das hier: Das kann man jetzt so lesen: 300ms nach dem Aufruf hat der Browser das HTML Dokument heruntergeladen und beginnt das zu verarbeiten. Dabei findet er heraus, dass er CSS laden muss, um die Seite anzuzeigen und startet den Prozess: Wir sehen: 526ms nach initialem Aufrufbeginn hatte der Browser die Idee zusammen, nach 529ms die Anfrage abgeschickt, musste dann 117ms warten bis eine Antwort vom Webserver mit dem Shop übers Netz einzutreffen begann, bis dann nach weiteren 63ms alles davon komplett da war. Der ganze Prozess hat 185ms gedauert. Der Browser verarbeitet nun das CSS, und stellt fest darin stehen Schriften, die zu laden sind. Macht der dann, sieht man im Wasserfall weiter oben, 3 Spalte, Type font. Man kann m Wasserfall auch gut sehen, dass alle 5 Schriftdateien gleichzeitig geladen werden. Der Beginn ist in den Graphen in einer senkrechten Linie. Für den Fall spannend ist hier eigentlich nur wann das herunterladen der Schriften begann, nämlich 852ms nach initialem Aufrufbeginn. Man kann ausserdem noch herauslesen, dass das dann 123,57ms von Beginn bis Ende gedauert hat. Alle Schriften dauern hier grob gleichlang. Ich runde die Beschaffungszeit für alle Fonts hier mal pessimistisch auf 150ms. Damit haben wir alle Zahlen um den möglichen maximalen Erfolg einer "Preload Key Requests"-Optimierung zu messen. Wir wollen die Schriften früher laden, damit wir dann nicht später auf diese warten müssen. Wir gehen vom bestmöglichen Fall aus: Würden wir die Schriften in Preload Tags einfügen, würde der Browser sein Parallelitätslimit nicht erreichen, und wirklich sofort beginnen die Schriften herunterzuladen. Wir behaupten das passt sofort in die Ausführung. Praktisch referenziert man normal auch immer Javascripte und Bilder in der Seite, die ebenfalls auf Bandbreite und Ausführung des Herunterladens warten, und ebenfalls für die Seite nötig sind. Wir gehen dazu von unendlicher Bandbreite aus, und nehmen an das Laden dieser Ressourcen, parallel zu anderen die geholt werden, erfolgt mit hoher Geschwindigkeit. Die Bandbreite der Verbindung reicht. Wir können unter diesen idealen Bedingungen tatsächlich, in der Zeit die wir brauchen das CSS zu laden und zu verarbeiten (ca 300ms), die Schriften schon holen (150ms). Aber: Das holen der Schriften selbst dauert eben ziemlich genau 150ms. Diese 150ms sind der maximale Gewinn. Nicht 4,71 Sekunden, sondern 0,15 Sekunden. Unter sonst guten Bedingungen. That's it. Und es kommt noch eine Einschränkung: In der echten Welt haben die Leute einen Browsercache. Einmal geladen, werden die Schriften darin 30 Tage lang vorgehalten und in der Zeit nicht mehr neu heruntergeladen. Das heisst bei jedem Aufruf einer Shopseite nach der ersten ist der mögliche Gewinn 0. Das was optimiert werden soll passiert da gar nicht mehr. Die Welt ist nun meist nicht ideal, wahrscheinlich kommen im praktischen real world Mittel für Erstbesucher tatsächlich 0,1 Sekunden heraus. Man bräuchte eine grössere Messreihe um da etwas Empirie zu erlangen, die hab ich gerade adhoc nicht vorzuweisen. Ich nehme an diese 0,1 Sekunden wollen wir früher oder später haben und werden dafür was machen. Bei dem denkbaren Gewinn drängt es sich nur nicht als Eilprojekt auf, sondern wandert normal durch unsere Schlange. So, damit hab ich jetzt mal das gemacht, was ich oben angemahnt hab: Ich habe ein Einzelergebnis des Tools genommen, gemessen, interpretiert, kritisch betrachtet. Liefert gerne eure Einwände dazu, aber jetzt steht hier erstmal was, was Diskussionsgrundlage sein kann. Mit allen anderen Einzelwertungen muss man aus meiner Sicht genauso wie hier verfahren, also fragen "Was will das, was bedeutet das, was kostet das, was kann das, was bringt das wirklich?". Dann kann man sich fragen "Brauch ich das, oder ist das Kunst?" Dann ist man viel weiter. (Ich hab übrigens nicht pauschal was gegen Kunst, aber manchmal präferiere ich Wissenschaft stark... )
Beides ist Font Awesome. Bei den neueren Versionen gibts eine kostenpflichtige "Pro"-Version. Der einzige Unterschied: Die enthält nochmal mehr Symbole in mehr Varianten. Das kann man kaufen, brauchten wir aber nie. Egal ob Version 3 oder 4, ob free oder pro: Die sind optimiert und bedürfen allein mangels weiterer Möglichkeiten keiner weiteren Optimierung.
Mal gucken ob ich es richtig verstanden habe: Zunächst wird die Schriftart vom HTML (Body) geladen die im Style-Edit unter Grundlagen / Typografie angegeben ist also diese: "Roboto, Arial, sans-serif" fonts.googleapis.com/css?family=Roboto:400,700,300,900" Dann werden die Schriftarten nachgeladen die im CSS erstellt wurden (wenn etwas angegeben) bzw. aus Content welcher mit dem Ckeditor erstellt wurde, bei mir ist es diese font-family: arial,helvetica,sans-serif; Ist das> "Roboto, Arial, sans-serif" das gleiche wie das >font-family: arial,helvetica,sans-serif;?
Nein. Das ist eine Webfont, dafür muss eine Schriftartdatei geladen werden. In Sekunde 0 ist beim Erstaufruf nicht da. Webfonts lösen im Kern 2 frühere Probleme: Anno dazumal konnte man nur Schriften auf Webseiten benutzen, die auf dem jeweiligen System schon ab Haus vorhanden waren. Windows brachte andere Schriften mit als Apple OS X. Die wiederum als Linux, die wiederum als Android. Die Folge war: Webseiten sahen auf allen Geräten etwas unterschiedlich aus. Seiten sollten aber überall gleich aussehen. Und die Schnittmenge der Schriften, die es auf allen Systemen gab, war minimal. Bestenfalls waren das 1-2 Schriften. Man hatte also sehr wenig Gestaltungsfreiheit. Die Folgeidee: Man emanzipiert sich von Systemschriftarten und bringt die in Webseiten einfach mit. Und zwar Schriften soviele und wie man will. Das tun Webfonts. Roboto ist eine gebräuchliche, elementare Webfont. Die wird eigentlich immer nachgeladen. Du siehst erst kurz wahrscheinlich aber Arial. Das verweist eher aus Systemschriften mit den alten, klassischen Problemen, darum macht man das normal nicht mehr so. Da steht benutz Arial, wenn die nicht da ist helvetica, wenn die nicht da ist sans-serif. Meistens fällt das auf Arial. Das kannste jetzt wahrscheinlich puzzlen oder?
Es würde auf jeden Fall keinen Sinn machen eine Schrift zu laden, wenn du Sie dann nicht benutzt. Wenn im Fontpfad für Google Roboto geladen wird, ein im css folgendes "font-family: arial,helvetica,sans-serif;" die aber nicht inkludiert, dann wär da was über. Webfonts generell: Grossartige Erfindung. Endlich sehen Webseiten überall grob gleich aus, auch bei den Clowns die Comic Sans MS als Systemschrift eingestellt haben. Ich würde den initialen Ladezeitnachteil, um Roboto einmalig zu laden und einzubinden, immer in Kauf nehmen um das Problem zu lösen. So gross ist der nicht, wir haben das oben gemessen und gerechnet. Du lädst auch immer die Symbolschriften, die brauchts nunmal. Üblicherweise holt der Browser zeitgleich auch andere Webfonts. Der Ladezeitunterschied mit und ohne Roboto ist damit oft 0. Er wäre grösser 0, wenn die Datenmenge durch eine sehr schmale Verbindung muss. Dafür braucht man miserables Handynetz oder eine ganz schlimme DSL-Leitung. Bei einer Webfont reden wir oft über 50kb Daten pro geladener Schriftart beim ersten Seitenaufruf. DSL 1000 kann 125kb/Sekunde. Das heisst bei einer DSL 1000 Leitung würde die Seitenladezeit um 0,4 Sekunden verlängert. Auch vergleichend mit der üblichen "Bildlast" (Dauer für herunterladen der eingebunden Bilder) ist das recht klein. Wenn man eine nicht ganz unübliche 3MB Startseite hat, würde die dort nicht in 24 Sekunden laden, sondern in 24,4 Sekunden. Und nur um das auch mal gesagt zu haben: Es würde lästig, wenn du exobitant viele Webfonts gleichzeitig einbindest, weil die Datenmenge dann natürlich steigt. Neben den Symbolschriften aber 2-3 weitere Schriftsätze laden? Nobody really cares. Auch die Nutzererfahrung leidet unter den wenigsten Fällen irgendwie spürbar, dafür müsste die Seite sichtbar langsamer laden. Dafür kriegste Gestaltungsmöglichkeiten. Und ums auch gesagt zu haben: Das kostet dann ein paar Punkte bei Google Pagespeed Insights. Das ist so. Praktische Bedeutung hat das aber eben keine.