Web-Performance ist entscheidend, aber in letzter Zeit hatte ich das Gefühl, dass das Thema nur von Frontend-Entwicklern angesprochen wird und erst am Ende eines Projekts diskutiert wird. Folglich, wann immer ich von Lösungen höre, um große Websites zu optimieren, kann ich nicht anders, als das Gefühl zu haben, dass dies bloße Vorschläge oder Tricks sind, die Entwickler und Ingenieure nach dem Start des anfänglichen Designprozesses anwenden sollten.
Welche Designthemen beeinflussen die Performance? Nun, jede Frage, die sich ein Designer stellen könnte. Zum Beispiel diese:
- Wie viele Schriftarten sollten wir verwenden?
- Welche Art von Bildern sollten wir verwenden?
- Welche Analyseskripte benötigen wir?
- Wie scrollt ein Benutzer durch unsere App?
- Wie wirkt sich diese komplexe Komponente auf unser CSS aus?
- Wie sollten wir überhaupt CSS schreiben?
- Welche Frameworks sollten wir wählen?
Meistens führen diese Fragen zu mehr Code, mehr Komplexität und mehr Ballast in einem Designsystem, da...
- Je mehr Schriftarten wir hinzufügen, desto länger lassen wir unsere Benutzer warten.
- Die Art der Bilder, die wir für ein Projekt wählen, beeinflusst, welche Bildformate wir verwenden.
- Wenn wir eine verrückte Anzahl von Analyse-Tools auswählen, kann das auch die gesamte App verlangsamen.
- Das Hinzufügen einer komplexen Komponente in CSS, die nur einmal in der App verwendet wird, führt zu Code-Ballast und verlangsamt die Zeit bis zum ersten Rendern weiter (wenn auch nur geringfügig).
- Die Entscheidung, welches Framework wir verwenden, hat einen enormen Einfluss auf den kritischen Pfad.
Kurz gesagt, Designteams sollten ihren Erfolg anhand wichtiger Web-Performance-Metriken messen, da jede Entscheidung, die sie treffen, schließlich zu drastischen Änderungen dessen führt, was an den Endbenutzer gesendet wird.
Und wie ich angefangen habe, darüber nachzudenken, ist es so: Jede Diskussion über Design ist auch eine Diskussion über Web-Performance. Ich versuche mich daran zu erinnern, dass die beiden untrennbar miteinander verbunden sind und ich als Webdesigner von Anfang an eines Projekts auf diese Probleme achten sollte, nicht erst am Ende.
https://pathtoperf.com/
Beste Ressource aller Zeiten! Sie haben gerade die zweite Staffel gestartet! Gut gemacht, Chris!
Die Performance von Anfang an zu berücksichtigen, ist gut. Allerdings gibt es bei jedem Projekt Kompromisse. Der wichtigste Faktor meiner Meinung nach ist die Markteinführung. Als Nächstes muss sichergestellt werden, dass es wartbar ist. Ich finde, wenn man am Anfang zu viel über Performance nachdenkt, beginnt man mit verfrühter Optimierung, die das Projekt verlangsamt und zum direkten Gegenspieler des wichtigsten Faktors werden kann – der Markteinführung.
Gut gesagt, Robin — ich könnte nicht mehr zustimmen. Wie Brad Frost sagte: „Der Weg zu besserer Performance beginnt nicht bei Entwicklern oder Technologie-Stacks. Er beginnt mit einem gemeinsamen Interesse aller Beteiligten, ein blitzschnelles Produkt zu schaffen.“ Link
Ein großartiger Beitrag! Danke für den Link, Jon.
Welche Art von Fragen muss man stellen, damit ein Designer berücksichtigt, dass (sagen wir mal) ein komplexes 20 MB Parallax-Scrolling-Design vielleicht nicht die beste Lösung für seinen Kunden ist? Wie beurteilt man solche Kompromisse?
Gut, versuchen wir, den Artikel zu verbessern.
Hier sind einige Fragen, die meiner Meinung nach den Artikel verbessern könnten:
Was ist mit Fallback-Bedenken? Progressive Enhancements? Geräte-spezifische Hacks? Wie sollte ein neues Element auf einer Seite gerendert werden? Was ist mit Animationen? Wie wird das Responsive mit dem aktuellen Design umgesetzt? Wie ist die Performance bei deaktiviertem Javascript? Ist das überhaupt ein Anliegen? Was sind *die* Anliegen, die wir haben? Ist das eine Marketing-Website, eine Web-App, E-Commerce, Single-Page, etc.? Müssen wir uns um Lokalisierung kümmern? Hat das aktuelle Design Zugänglichkeitsbedenken?
Und hier sind meine Probleme mit dem Artikel, Zeile für Zeile.
Wo arbeiten Sie? Mögliche Performance-Probleme werden fast immer angesprochen, bevor überhaupt mit der Arbeit begonnen wird, und unbekannte Unbekannte werden später entdeckt und behoben. Unbekannte Unbekannte werden nur mit mehr Erfahrung „bekannt“. Je erfahrener Ihr Team ist, desto weniger unbekannte Unbekannte werden Sie antreffen.
Fast alle „Optimierungen“ großer Websites beziehen sich darauf, wie Assets ausgeliefert werden, wie optimiert Javascript ist und ob clevere Tricks angewendet werden können, um es zu „faken“. Sie befassen sich mit den Mikro-Optimierungen, die nur große Websites jemals in Betracht ziehen müssen.
Ich habe das Gefühl, wir haben nie wirklich über Grafikdesign gesprochen...
Vielmehr ist *wichtig, welche* Schriftarten Sie verwenden. Verwenden Sie Google Fonts? Aus persönlichen Tests gibt es einen vernachlässigbaren Unterschied bei den initialen Ladezeiten zwischen 3 Schriftarten und 10 Schriftschnitten und 2 Schriftarten mit 4 Schriftschnitten. Wenn Ihr Design mehr als 2 Schriftarten und 5 Schriftschnitte verwendet, könnte es sich lohnen, mit Ihrem Designer darüber zu sprechen.
Was?
Vielleicht ist es meine eigene Unwissenheit – aber können Sie mir mehr als 3 Arten von Analysetools nennen, die nicht völlig redundant sind?
Geht es hier um Web-Performance oder App-Performance? Sprechen wir jetzt über Websites (erste Zeile: „...große Websites optimieren...“) oder Apps? Vielleicht Web-Apps? Versucht dies, eine Entscheidung für den Benutzer zu treffen, oder werden Analysetools wie Hotjar verwendet, um zu sehen, wie Benutzer tatsächlich mit der Web-App interagieren? (Ich gehe davon aus, dass wir jetzt über eine Web-App sprechen.)
CSS-Optimierungen sollten Ihre geringste Sorge sein, es sei denn, Sie haben so viel Traffic wie Google oder Facebook.
„Nun“? Dies ist keine Optimierungsfrage – dies ist eine Frage des Toolings. Es sei denn, wir sind von Web-Performance zu Entwickler-Performance gewechselt.
Ebenfalls ein Problem des Toolings.
Wir sind von Webdesign zu App-Design zu Systemdesign und Tooling übergegangen.
Die Größe der Schriftarten ist wichtiger als die Anzahl der HTTP-Anfragen.
Aha! Endlich eine rein designbezogene Optimierungsfrage: „Sollte dieses Bild ein JPG oder ein PNG sein? Vielleicht kann es sogar ein SVG sein.“ Glücklicherweise ist das eine sehr einfache Frage zu beantworten und sie lässt sich leicht messen.
Siehe meinen früheren Kommentar. Auch, warum wählt das Design die Analysetools aus? Die ausgewählten Analysetools hängen weitgehend davon ab, was für das Marketingteam getrackt werden muss. Wenn es eher web-app-ähnlich ist, könnten Sie versuchen, Benutzer zur Fehlerbehebung zu tracken.
Ja! Dies wurde vom Rest des Artikels überhaupt nicht angesprochen. Vielleicht, wie eine Diskussion über die Überarbeitung der Komponente oder deren Vereinfachung? Sie sollten auf dieses Thema mehr eingehen.
Das sind wörtlich drei Schlagworte, die aneinandergereiht wurden. Können Sie „kritischen Pfad“ definieren? Wie ich ihn typischerweise sehe, hat er meistens mit „alles über der Falzlinie“ zu tun, und jedes Frontend-Framework, das Sie letztendlich verwenden, hat wenig damit zu tun, wie die ersten Bytes Ihrer Website ausgeliefert werden.
Was sind diese „wichtigen Web-Performance-Metriken“, die in diesem gesamten Artikel überhaupt nicht erwähnt wurden? Sie versuchen, etwas zusammenzufassen, das noch nicht einmal da ist.
Alles, was Code berührt, wird irgendwann eine Sorge um die Optimierung und Performance dieses Codes sein.
Jemand ist schlecht gelaunt aufgestanden.
Danke.
http://www.fahriyevcen.com
Was die Web-Performance angeht: Wenn man diese Seite vergrößert, ruckelt sie (Safari auf einem frühen 2015er Macbook Pro 13″ 10.11.6)