Web Presence Builder - google fonts lokal einbinden

  • Hallo,


    ich benutze den Web Presence Builder, der Bestandteil meines Webhosting-Pakets ist. Soweit ich weiß sind die fonts dort dynamisch eingebunden. Es wäre wohl datenschutzrechtlich besser, diese lokal einzubinden. Kann ich das einfach bewerkstelligen? Kann ich dieses mit dem Web Presence Builder überhaupt machen?


    Gruß


    akapuma

  • ich würde diesen am besten gar nicht mehr einsetzen.

    Dar er so weit ich weiß ziemlich veraltet ist.

    Ich z.b. setze auf Wordpress + Gutenberg funktioniert so weit sehr gut - auf ein 4000er 89 Mobil Score bei Google und 100 Dekstop (Gtmetrix usw auch gut)

  • Tja, ich bin Anfänger. Mein Hobby ist es die perfekte Paella zuzubereiten und darüber zu schreiben. Für eine professionelle Website fehlen mir die Kenntnisse und vor allem die Zeit! Der "Homepagebaukasten" kam mir da sehr gelegen und war ein Kaufargument für das Webhosting-Paket. Davor hatte ich die Webseiten händisch mit Seamonkey erstellt. Nicht so schön, viel Arbeit, aber DSGVO-konform!


    Da wieder Abmahner unterwegs sind die nach dynamisch eingebundenen Fonts auf Webseiten suchen habe ich meine Website leider erstmal stillgelegt. Ein Hoch auf die DSGVO!


    Gruß


    akapuma

  • akapuma Spricht was gegen Wordpress?

    Das ist leicht zu installieren (ich würde nicht den fertigen Installer empfehlen sondern "von Hand" was auch nicht viel komplizierter ist) und wenns mal läuft ist Artikel (oder Seiten) schreiben ziemlich einfach.

    Wenn man nicht hunderte Plugins installiert ists auch schnell und sicher. Gerade wenn dir das Design nicht so wichtig ist wie der Inhalt (wie es imho sein sollte) dann bist du mit dem Standard Theme in 5 Minuten fertig für deinen ersten Eintrag.


    Ich helfe gerne, verlange aber viel, viel Paela dafür 😜

  • Tja, ich bin Anfänger. Mein Hobby ist es die perfekte Paella zuzubereiten und darüber zu schreiben. Für eine professionelle Website fehlen mir die Kenntnisse und vor allem die Zeit!

    akapuma Spricht was gegen Wordpress?

    Das ist leicht zu installieren (ich würde nicht den fertigen Installer empfehlen sondern „von Hand“ was auch nicht viel komplizierter ist) und wenns mal läuft ist Artikel (oder Seiten) schreiben ziemlich einfach.

    Das zeitnahe Einspielen von Updates usw. ist allerdings auch nicht immer trivial. Wenn es wirklich nur darum geht, den Inhalt zu transportieren (und dieser einen „überschaubaren Umfang“ hat), warum nicht einen Dienstanbieter wählen, welcher die Wartung der zugrundeliegenden Software übernimmt?

    Neben den üblichen Verdächtigen, welche in der Regel in den USA sitzen (Wordpress, Blogger) wäre gegebenenfalls auch die Nutzung von Wikis und Markdown-basierten Dokumenten eine Option, welche in einem Repository beispielsweise über GitHub kostenlos ausgeliefert werden (vgl. GitHub Pages).

    Das vorgenannte Beispiel ist sicherlich das bekannteste seiner Art und Microsoft wiederum in den USA, aber mit Gitea und verbundenen kostenlosen Hosting-Angeboten wie Codeberg gibt es eine hiesige, ebenfalls kostenlose Alternative! Navigation über Hyperlinks und die Einbindung von Grafiken ist hier kein Problem, auch wenn der Funktionsumfang noch nicht vergleichbar ist mit GitHub Pages …

    (Es gibt auch Generatoren wie Hugo, welche sehr ansprechende, einfache Designs und Workflows mitbringen, aber notfalls gänzlich ohne JavaScript auskommen, was für „unabhängige Inhalteanbieter“ sicherlich auch eine bessere Alternative zu Wordpress darstellt und mit dem letztgenannten Repository-Ansatz kombiniert werden kann. Ein Kriterium, welches ggf. nicht von Anfang an auf dem Schirm ist, aber eine Rolle spielen kann: Vorgenannte öffentliche, kostenlose Repositories können den Ersteller „relativ aufwandslos“ überleben; eine bezahlte Domäne mit zugehörender privater Onlinepräsenz erfordert entsprechende (testamentarische) Vorkehrungen …)

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    2 Mal editiert, zuletzt von m_ueberall ()

    Gefällt mir 1
  • Da wieder Abmahner unterwegs sind die nach dynamisch eingebundenen Fonts auf Webseiten suchen habe ich meine Website leider erstmal stillgelegt. Ein Hoch auf die DSGVO!


    Die DSGVO ist richtig und wichtig, da braucht man sich nicht abfällig zu äußern oder in Panik zu verfallen. Dass es auch unter Anwälten schwarze Schafe [1] (darf man das bei aller verlangten politischen Korrektheit noch sagen?) gibt, ist klar. Das repräsentiert aber weder den Berufsstand noch die Gesetzgebung zum Thema Datenschutz. Datenschutz ist ohne Frage wichtig für die Nutzer und die Einbindung von Schriften über einen Google-Server ist in der Regel halt ein Verstoß, da beißt die Maus keinen Faden ab. In den meisten Fällen ist das aber auch einfach vollkommen unnötig, da man die Schriften sowieso einfach lokal einbinden kann. Das ist dann sogar nicht gut für den Datenschutz, sondern auch für die Ladegeschwindigkeit der Website.


    [1] https://marketingrecht.eu/google-fonts-abmahnungen/ => Sehr interessanter Lesestoff, weil da im Detail darauf eingegangen wird, was es auch für Beweise dafür gibt, dass hier eine Betrugsmasche vorliegt.

  • Hay,

    da man die Schriften sowieso einfach lokal einbinden kann. Das ist dann sogar nicht gut für den Datenschutz, sondern auch für die Ladegeschwindigkeit der Website.

    Rechtlich 100% korrekt, technisch leider nicht ganz so...


    Die CDNs - also auch google fonts - sind ja dafür ausgelegt, dass die Chance, dass die Schrift schon im Cache ist, steigt, weil man sie schon von einer anderen Webseite geladen hat. Somit ist es für die Ladezeit eigentlich besser, wenn man sie von einem (virtuellen) zentralen Punkt aus lädt. Dasselbe gilt für jQuery, bootstrap und das ganze Gesocks, dass weltweit den Entwicklern die Arbeit leichter macht. Liegen sie auf einem anderen Server, muss die Dateien zumindest von diesem einmal runtergeladen werden - bei gutem, aktiven Cache-Management, bei keinem oder schlechtem häufiger bis immer.

    Dass so viele Schriften insgesamt im Spiel sind, dass die Wahrscheinlichkeit einer vorhanden Schrift (ungleich OpenSans, ungleich Roboto) gegen 0 geht, ist mir dabei allerdings bewußt. In dem Fall muss der eigene Server den Font immer noch schneller liefern als das CDN - das kann man aber im Browser gut messen.


    Trotz dieser technischen Einlassung sollte es aber keinen Dritten auf der Welt interessieren, dass Du dessen Dateien einsetzt und dafür eine IP und einen Browserfingerabdruck hinterlässt.


    Also ja, alles selbst zur Verfügung stellen.


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Rechtlich 100% korrekt, technisch leider nicht ganz so...


    Die CDNs - also auch google fonts - sind ja dafür ausgelegt, dass die Chance, dass die Schrift schon im Cache ist, steigt, weil man sie schon von einer anderen Webseite geladen hat. Somit ist es für die Ladezeit eigentlich besser, wenn man sie von einem (virtuellen) zentralen Punkt aus lädt. Dasselbe gilt für jQuery, bootstrap und das ganze Gesocks, dass weltweit den Entwicklern die Arbeit leichter macht. Liegen sie auf einem anderen Server, muss die Dateien zumindest von diesem einmal runtergeladen werden - bei gutem, aktiven Cache-Management, bei keinem oder schlechtem häufiger bis immer.


    Dein Wissen dazu ist überholt, jedenfalls längst nicht mehr für jeden modernen Browser zutreffend. ;) In Firefox nennt sich das Ganze Netzwerk-Partitionierung und ist ein standardmäßig aktives Datenschutz-Feature. Safari und Chrome besitzen ähnliche Features, wobei die Netzwerk-Partitionierung von Firefox das umfangreichste aller Browserhersteller sein soll - schrieb jedenfalls ZDNet, als Mozilla das vor 1 1/2 Jahren eingeführt hat. Die Netzwerk-Partitionierung isoliert folgende Dinge voneinander:


    Zitat
    • HTTP cache
    • Image cache
    • Favicon cache
    • Connection pooling
    • StyleSheet cache
    • DNS
    • HTTP authentication
    • Alt-Svc
    • Speculative connections
    • Font cache
    • HSTS
    • OCSP
    • Intermediate CA cache
    • TLS client certificates
    • TLS session identifiers
    • Prefetch
    • Preconnect
    • CORS-preflight cache


    Heißt im Klartext: Ein Website-übergreifendes Caching findet nicht mehr statt. Um mich selbst zu zitieren, als ich darüber geschrieben habe:


    Es wird erwartet, dass die Netzwerk-Partitionierung einen gewissen negativen Einfluss auf die Performance hat, da beispielsweise Schriftarten nicht mehr aus einem seitenübergreifenden Cache geladen werden. Mozilla nimmt dies für eine verbesserte Privatsphäre seiner Nutzer allerdings bewusst in Kauf.


    Wie gesagt, Chrome und Safari haben das ebenfalls. Für Chrome verweise ich auf ZDNet:


    Google hat den HTTP-Cache letzten Monat mit der Veröffentlichung von Chrome 86 ebenfalls partitioniert, und die Ergebnisse waren sofort spürbar, da Google Fonts einige seiner Performance-Metriken verlor, da es Schriften nicht mehr im gemeinsamen HTTP-Cache speichern konnte.

  • Hay,

    Ein Website-übergreifendes Caching findet nicht mehr statt.

    vielen Dank für den Hinweis. Da Fremdladen von Inhalten für mich eh' seit 2018 nicht mehr in Frage kommt, bin ich da nicht auf dem Laufenden geblieben :sleeping:

    Heißt also das eigene Caching gut im Auge zu behalten, HSTS Features & Komprimierung zu benutzen und CDN's, die die eigene Domain mitliefern und nicht (wie früher Akamai) die Files einfach nur über die CDN-Server verteilt und mit akamai-Domain nachladen. Gut zu wissen.


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

    Gefällt mir 1
  • Die CDNs - also auch google fonts - sind ja dafür ausgelegt, dass die Chance, dass die Schrift schon im Cache ist, steigt, weil man sie schon von einer anderen Webseite geladen hat. Somit ist es für die Ladezeit eigentlich besser, wenn man sie von einem (virtuellen) zentralen Punkt aus lädt. Dasselbe gilt für jQuery, bootstrap und das ganze Gesocks, dass weltweit den Entwicklern die Arbeit leichter macht. Liegen sie auf einem anderen Server, muss die Dateien zumindest von diesem einmal runtergeladen werden - bei gutem, aktiven Cache-Management, bei keinem oder schlechtem häufiger bis immer.

    Dieses Argument ist aber mit dem aus Privacy-Gründen bei den Browsern eingeführten Cache Partitioning hinfällig. Die Assets werden für jede besuchte Seite separat im Cache abgelegt.