Wie sieht es mit der Web-Performance auf Ihrem Hauptprojekt aus? Zur Vereinfachung, aber auch zur breiten Abdeckung, habe ich es in fünf Auswahlmöglichkeiten unterteilt, die von "niemand kümmert sich" bis "jeder kümmert sich" reichen. Es geht nicht darum, *wie gut* Sie bei der Performance abschneiden, sondern *wie sehr* sie Teil der Kultur Ihres Projekts ist.
Um abzustimmen, befindet sich die Umfrage in der Seitenleiste (große Bildschirme) oder irgendwo weiter unten (kleine Bildschirme).
Es wird interessant zu wissen, oder? Performance ist heutzutage ein so heißes Thema, macht es einen Einfluss, so dass die meisten Teams voll und ganz dabei sind? Oder ist es immer noch ein Kampf? Vielleicht ist es den meisten Leuten immer noch egal? Wir werden es herausfinden.
Wenn man Designer und das Management fragt, ob sie gute Performance wollen, sagen sie ja.
Aber dann spezifiziert der Webdesigner die gesamte Website mit Webfonts, und dann macht ein anderer Designer eine Infografik mit einer anderen Schriftart mit 10 Varianten – dann kaufen sie die Webversion, damit sie die Infografik responsiv und zugänglich machen können.
Und dann erfährt der Entwickler davon.
Also wollen die Designer und das Management im Grunde, was sie wollen, und es fällt ihnen nicht ein, dass es die Performance beeinträchtigt.
Es ist nicht so, dass es ihnen egal ist, sie verstehen nur die Kompromisse nicht.
Das.
Es ist in einer Branche selten, dass jemand sagt, Performance sei egal. Aber die meisten Leute betreiben nur Lippenbekenntnisse.
Mindestens 7 von 10 Mal gewinnt die Ästhetik über die Performance. Das Laden von Retina-Bildern, benutzerdefinierten Schriftarten, HD-Videos wird als wichtiger erachtet als Schnelligkeit. (Und mir ist bewusst, dass Performance vs. Ästhetik keine binäre Entscheidung ist, aber bei der Umsetzung unter Zeitdruck mit Leuten, die Performance nicht wirklich schätzen, ist das Ergebnis oft so.)
Ich habe einige Arbeiten zur Reduzierung der Ladezeiten durchgeführt, oft mit sehr guten Ergebnissen, indem ich einfach "Low-Hanging Fruits" gegriffen habe. Ich habe einmal die Forschung dazu vorgestellt, die Arbeit gemacht, die Zahlen verbessert und sogar eine kleine Firmenpräsentation dafür gehalten; ich wurde applaudiert und alle sprachen darüber, wie wichtig Performance wirklich ist. Zwei Wochen später war es wieder der Standardablauf.
(Ich habe versehentlich für Bob unten gepostet, mit einem Anfall von Dummheit. Hätte hier gepostet werden sollen. Entschuldigung.)
Sie lassen es so aussehen, als wären Entwickler die Rosenblätter der Performance und Designer einfach schlecht.
Blinder voreingenommener Kommentar.
Ich habe mit vielen Entwicklern gearbeitet, die kein Interesse, keine Ahnung oder kein solides Wissen über Performance haben. Ich gebe ihnen sauberes HTML und CSS, und das Nächste, was ich sehe: leere Tags überall auf der Website im Endergebnis, weil der Content Creator keinen Inhalt in das CMS für diesen Bereich eingefügt hat. Anstatt den Tag nicht einzufügen, weil kein Inhalt da ist, fügen sie einen leeren Tag ein, weil kein Inhalt da ist.
Und dann sieht man diejenigen, die in Bootstrap verliebt sind. Das ganze Framework.
Und dann sieht man diejenigen, die noch nie von SVG gehört haben, geschweige denn damit gearbeitet haben. Stattdessen nach PNGs fragen… und nein, nicht mal als Sprite, sondern als separate Dateien.
Es ist nicht so, dass es ihnen egal ist, sie verstehen nur die Kompromisse nicht.
@Ricardo,
Sprich für dich selbst.
Ich spreche lediglich über meine Situation und verallgemeinere nicht über alle Designer oder alle Entwickler.
Die meisten Designer hier sind immer noch print-orientiert und betrachten das Web als nachträgliche Überlegung. Die Tatsache, dass sie überhaupt den Kauf einer Webfont in Erwägung gezogen haben, um Infografiken responsiv und zugänglich zu machen, ist eigentlich ein ziemlich großer Schritt nach vorne für sie.
Ich habe nie gesagt, dass die Entwickler schuldlos sind. Verdammt – wir benutzen Foundation. Aber wir tun, was wir können – einschließlich des Versuchs, andere über diese Kompromisse aufzuklären.
Glauben Sie mir – ich mache das seit den 90er Jahren. Die Technologie ändert sich, aber das Tauziehen zwischen Ästhetik und Performance ändert sich nie.
RioBrewster und Bradley machen einige ausgezeichnete Punkte.
"Es ist nicht so, dass es ihnen egal ist, sie verstehen nur die Kompromisse nicht." trifft den Nagel auf den Kopf.
Ich bin seit Mitte der 90er Jahre im Web dabei. Da sich das Web weiterentwickelt hat, müssen sich die Menschen mitentwickeln. Wir sehen immer noch viele Print-Leute, die das Web so behandeln, als wäre es nur ein weiteres Print-Medium, bei dem die Form über der Funktion steht. Kunden wollen immer noch die volle Kontrolle über ihre WYSIWYG-Editoren, und Leute stellen immer noch Websites mit Lorem-Ipsum-Text online, weil sie mehr auf das Design als auf den Inhalt achten.
Vieles davon ist einfach Bewusstsein und Verständnis. Wir *können* beides haben, aber es wird Kompromisse geben; der Unterschied, der den Unterschied macht, sind die richtigen Kompromisse für diese spezielle Website zu dieser speziellen Zeit.
Manche Designer erkennen einfach nicht/kümmern sich nicht darum, dass ihre eng gesetzten Mockups und Farbwiedergaben nicht perfekt sein werden… und das ist in Ordnung. Man erkennt sofort, wer sich kümmert und wer nicht – jeder, der "pixelgenau" in seine Beschreibung von gutem Webdesign aufnimmt, ist Teil des Problems.
Weiß nicht, wie man ein Dokument formatiert? Machen Sie es einfach in Photoshop und speichern Sie es als JPEG. Problem gelöst! Meiner Meinung nach sind diese rotierenden Heldenbanner deshalb immer noch so beliebt – sie sind die letzte Zuflucht des Desktop- und Print-orientierten Designs. Hier ist die Größe des Banners, können Sie es füllen? Blabla… Das Web war nie, niemals eine perfekte Wiedergabe der Photoshop-Leiste, und wie kann es das sein?
Wie Bradley angedeutet hat, behandeln andere Leute die Web-Performance einfach so, wie manche Kunden SEO behandeln… können Sie nicht einfach etwas einmalige, magische Feenstaub auf den Code streuen, Schlüsselwörter und Meta-Tags einfügen, und jetzt ist unser Performance-Problem gelöst?
Tut mir leid, Leute, so funktioniert es nicht. Doch es gibt viele Leute, die dem Kunden sagen "sicher, wir können alles tun, was Sie wollen" oder vielleicht gibt es ein Wettrennen nach unten, und Sie bekommen Leute, die einfach nicht qualifiziert sind, es richtig zu machen.
Genau wie beim Branding, wenn niemand die Performance einer Website kontinuierlich überwacht, um sicherzustellen, dass alles auf dem neuesten Stand ist, wird sie den Bach runtergehen. Genau wie Designer, die ihre Website an den Kunden übergeben und 2 Monate später sind die Farben und die Marke verwaschen; es ist nicht anders.
Es gibt nur eine richtige Antwort. Wenn Sie nicht "Jeder kümmert sich und arbeitet aktiv daran, die Web-Performance Ihres Hauptprojekts aufrechtzuerhalten und zu verbessern" gewählt haben, dann verlieren Sie Geld. Wenn Ihr Chef nicht hinter Performance-Verbesserungen steht, gibt es jede Menge Forschung online, die Sie Ihrem Chef präsentieren könnten, die erklärt, warum es Geld kostet, nicht Performance-first zu gehen. Wenn Ihnen Geld egal ist, kümmern Sie sich dann um: Leser? Besucher? Angeberei? Sie verlieren all das, wenn Sie nicht Performance-first gehen.
Fast die einzigen Situationen, die mir einfallen, in denen Performance nicht an erster Stelle stehen muss, sind persönliche Projekte, die man nicht unbedingt anderen zeigen möchte, und Regierungswebseiten, die Leute benutzen müssen, wenn sie etwas erledigt haben wollen.
Ich habe schon lange das Argument der "geschlossenen Zielgruppe" im Hinblick auf Performance, Ästhetik und Barrierefreiheit gehasst. Ich habe einmal für ein Callcenter gearbeitet, bei dem das Einsparen von 1 Sekunde pro Anruf jährlich 140.000 Dollar einsparte, doch wir wurden oft gebeten, ein Produkt zu liefern, das um 10-15 Sekunden schneller gemacht werden könnte, indem man einfach Primärschlüssel auf einer Tabelle setzt oder die SQL-Abfrage optimiert, ganz zu schweigen von den Optimierungen in der Benutzeroberfläche. Geld wurde liegen gelassen. Das andere Argument, das wir bekamen, war, dass wir keine Arbeitsersparnis beim Kunden einreichen wollten, weil sie kein Personal abbauen wollten. Oft sind es politische Spielereien, die die Entwicklung vorantreiben, anstatt eine begründete und gemessene Strategie.
Bei meinem Hauptjob, dem Ninja Forms WordPress Plugin, ist Performance eine Teamangelegenheit. Aber das muss es irgendwie sein, da wir ein weit verbreitetes Plugin pflegen. Es ist nicht auf allen über 200.000 Installationen perfekt, aber es ist definitiv ein Hauptfokus des Teams.
Allerdings habe ich an anderen Projekten gearbeitet, bei denen Performance gewünscht wird, aber schnell andere Designästhetiken bevorzugt werden.
Performance vergisst man leicht, bis sie einem ins Gesicht schlägt. Es ist ein langsamer Schlag, aber er tut trotzdem weh.
Es ist noch nicht veröffentlicht, aber The Web Ahead #106 ist ein #MustListen vor jeder Diskussion über "Performance" im Zusammenhang mit Webtechnologie.
http://thewebahead.net/
Als Ingenieur bin ich mit Herz und Seele FÜR Performance. Kunden wollen sie auch (wenn es jemals zur Diskussion kommt), aber sie erkennen oft nicht, dass einige ihrer Designentscheidungen und Wünsche die Performance stark beeinträchtigen könnten. Selbst wenn sie sich des Einflusses bewusst sind, bleiben sie vielleicht bei ihrer ursprünglichen Designidee, es sei denn, es handelt sich um einen großen Engpass.
Was am häufigsten passiert, ist, dass ich "stillschweigend" etwas mehr Zeit in die Optimierung investiere, um alle glücklich zu machen.
Performance ist für unser Unternehmen von entscheidender Bedeutung. Wir haben ein Team, das sich ausschließlich mit der Verbesserung der Client-seitigen Performance beschäftigt. Das reicht vom Time-to-First-Byte, der Verbesserung der wahrgenommenen Seitenladezeiten, der Render-Optimierung usw. Alle anderen Teams, die am Front-End-Code arbeiten, sind natürlich auch mit dabei :-)
Ich denke, es ist Design von Performance und an diesem Punkt kann ich RioBrewster und Bradly nicht zustimmen. Wenn Ästhetik und Performance absolut getrennte Dinge sind, könnte einer dieser Parameter unnötig erscheinen.
Ob Sie zustimmen oder nicht, das ist die Realität für viele Agenturen.
Wenn eine Person sowohl Design als auch Code macht, oder wenn beide Funktionen im selben Team stattfinden, dann haben Sie wirklich keine Entschuldigung.
Aber in vielen Situationen – auch in unseren – sind die Funktionen nicht integriert und Entwickler haben kein Vetorecht bei Designentscheidungen.
Wie Zoki schon sagte, tun wir, was wir können, um das gewählte Design so schnell wie möglich laden zu lassen.
Am Ende des Tages kommt es auf Menschen und Persönlichkeiten an – unabhängig davon, was wir Technik-Nerds gerne denken.
Allgemeiner Kommentar – Ich bin mir nicht sicher, ob dies als Performance-Optimierung gilt oder nicht, aber ich bin überrascht, wie viele Websites da draußen (Unternehmen jeder Größe), die immer noch Multi-Megabyte-Home-/Child-Seiten (4 MB+) für mobile Geräte ausliefern. Zählen Sie Bandbreitenüberlegungen zur Performance oder ist das ein separates Thema? TTFB ist entscheidend, aber ich denke, dass man auch Rücksicht auf den Datenplan des Endbenutzers nehmen sollte.
Ich habe das Gefühl, dass viele der Performance-Probleme, auf die wir stoßen, darauf zurückzuführen sind, dass es immer noch eine massive Kluft zwischen Design und Entwicklung gibt. Zumindest dort, wo ich gearbeitet habe, wissen die Designer wenig darüber, was zur Erstellung einer Website gehört, und selbst einige der Entwickler dachten nicht viel über Performance nach. Wie andere schon sagen, Ästhetik gewinnt, weil man sieht, wie sie aussehen, im Gegensatz zur tatsächlichen Auswirkung der Verwendung großer Bilder und der Nichtberücksichtigung realer Nutzungsbedingungen.
Wir werden zu bequem mit unseren schnellen Arbeitsinternetverbindungen, es ist wichtig, dass wir unsere 4G-Verbindungen nutzen und unsere Desktop-Geräte drosseln, um zu sehen, was in der realen Welt wirklich passiert.
Ich denke, es ist wichtig, eine Möglichkeit zu haben, die Auswirkungen zu quantifizieren, denn die meisten Leute sehen im Arbeitsalltag nicht, wie der durchschnittliche Benutzer ihr Produkt nutzen wird. Etsy macht das großartig, sie haben ein Dashboard, das ihre Ladezeiten über Geräte/Standorte hinweg anzeigt.
Ich glaube, Sie würden feststellen, dass Sie mit jedem Mal benutzerdefiniertem Code viel mehr Performance sparen, als sich auf ein Framework zu verlassen.
Jede Umgebung ist anders.
Angesichts der Größe unserer Website, der großen Anzahl von Mitwirkenden, der Anzahl der täglichen Updates, der Größe und der breiten Palette von Fähigkeiten unseres Entwicklungsteams, der erforderlichen schnellen Bearbeitungszeit und der Vielfalt der Plattformen und Browser, die wir unterstützen müssen, ist ein Framework für uns sinnvoll.
Das gesagt, wir tun alles, was wir können, um den Overhead zu minimieren.
Ich stimme dem ersten Kommentator zu. Performance-Bewusstsein beginnt beim Geschäft, dann kommt das visuelle Design, und erst dann kommt der Entwickler. Unter der Annahme des Best-Case-Szenarios, dass der Entwickler Performance-orientiert ist, steht er immer noch vor einem mühsamen Kampf gegen Geschäfts- und Designentscheidungen.
Eigentlich reicht Bewusstsein nicht aus. Entscheidungen zu treffen und im Interesse der Performance zu handeln, ist das, was benötigt wird, und das ist auf allen Ebenen sehr schwer zu erreichen. Selbst angesichts rationaler Daten und eines Geschäftsvorhabens ist es eine schwierige Sache.
Die Steigerung der Web-Performance war in den letzten Monaten eine ziemlich aufregende Sache für mich. Früher dachte ich, dass die Verwendung von gzip für CSS, JavaScript und HTML genug wäre. Was für die kleineren Websites, die ich bei meinem letzten Job betreute, auch ausreichte.
Jetzt, da ich für nur ein Unternehmen arbeite, konnte ich Zeit damit verbringen, unsere Website zu beschleunigen, indem ich fortgeschrittenere Funktionen hinzufügte, einschließlich benutzerdefinierter Caching verschiedener Website-Funktionen, Vorladen von Seiten, wo zutreffend, und generell die Anzahl der ausgelieferten Elemente zu reduzieren, wo immer möglich.
Ich habe gtmetrix.com zur Bestätigung verwendet, dass unsere Ladezeiten sinken, sowie einige selbstgemachte RUM (Real User Monitoring), denn wissen Sie, die Nutzung anderer Server, das ist eine weitere DNS-Abfrage und weitere 0,1-0,3 Sekunden Ladezeit ;P
Es hat auch meine Art zu codieren und externe APIs zu integrieren verändert. Durch die Anwendung einer Cache-Policy, wo immer ich kann, konnte ich die Anzahl der Roundtrips und Elemente reduzieren, die pro Seite geladen werden. Außerdem, falls ein externer Dienst ausfällt, haben wir immer noch einen Daten-Cache, den wir schnell ausliefern können.