• Entwicklung/Architektur
  • Methoden
  • Programmiersprachen
• Betrieb
  • Datenbanken
  • Server
  • IT-Security
  • Speicher
  • Netzwerke
  • Virtualisierung
  • Verfügbarkeit
  • Künstliche Intelligenz
• Management und Recht
  • Projektmanagement
  • Digitalisierung
  • IT-Recht
  • IT-Selbständige
• Aktuelles
• Termine
• IT-Jobs

• Entwicklung
• Betrieb
• Management und Recht
• News
• IT-Jobs
• Newsletter

Dies ist der zweite Teil des Artikels. Lesen Sie den ersten Teil hier.

Ich weiß, ich höre mich an wie ein Spielverderber, aber wollen wir nicht alle eine performantere Website? Ein beliebtes Spielzeug sind Timer und genau deren Einsatz sollten wir tunlichst reduzieren (wenn nicht gar vermeiden). Timer wecken die CPU. JavaScript Timer erweisen sich als guter Einstiegspunkt für uns Entwickler, um mit dem Optimieren zu beginnen.

Wir alle lieben es doch, wenn es blinkt und glitzert! Aber auch an dieser Stelle ist weniger oft mehr. Kontinuierlich animierte Inhalte, wie animierte GIFs und automatisch abspielende Videos ziehen fortwährend (oft unnötigen) Strom. Das kleine Spinner-GIF löst im Browser fortwährend Malerei aus, auch wenn wir es nicht sehen können.

Wenn wir Animationen benötigen, sollten wir nach Möglichkeit deklarative Animationen (CSS-Animations und -Transitions) verwenden. Der Browser kann diese wegoptimieren, wenn das animierte Element nicht sichtbar ist, und sie sind effizienter als skriptgesteuerte Animationen. Allerdings sind CSS-Animationen auch limitierter als ihre großen JavaScript-Pendants.

Wenn möglich, sollten wir es vermeiden, Eigenschaften zu animieren, die Layout- oder Paint-Events auslösen. Das bedeutet allerdings die Animationen auf opacity oder transform zu beschränken [1] – beides kann der Browser in hohem Maße optimieren [2].

Wenn es um die Nachhaltigkeit einer Website geht darf man sich gerne einmal in Verzicht üben bzw. die opulente Animation ein wenig reduzierter deklarativ mit CSS konstruieren.

.box {
  
  /* Animation verbinden */

  animation-name: boxSlider;



  /* Dauer setzen */

  animation-duration: 1300ms;



  /* Wiederholungsrate */

  animation-iteration-count: infinite;



  /* ...ein hin und her */

  animation-direction: alternate;

}



@keyframes boxSlider {

  0% {

    transform: translate(0, 0);

    opacity: 0.3;

  }



  25% {

    opacity: 0.9;

  }



  50% {

    transform: translate(100px, 100px);

    opacity: 0.2;
  }



  100% {

    transform: translate(30px, 30px);

    opacity: 0.8;

  }

}

Auch das allseits beliebte Polling sollten wir vermeiden, wenn es darum geht, regelmäßige Aktualisierungen von einem Server zu erhalten. Wir sind im Jahre 2020 und dürfen Technologien wie WebSockets, Server-Sent Events oder Fetch mit einer dauerhaften Verbindung verwenden [3]! Eine Website die kontinuierlich am Arbeiten ist, auch wenn sie gerade im Leerlauf sein sollte, reagiert auch weniger auf Benutzerinteraktionen. Eine Minimierung der Hintergrundaktivität verbessert die Reaktionsfähigkeit und gleichzeitig die Akkulaufzeit – Win-Win [4]!

Das HTTP/1.1-Protokoll wurde vor mehr als 20 Jahren auf dem Markt eingeführt. Hauptnachteil dieses textbasierten Protokolls in Bezug auf Leistung und Effizienz ist die Latenzzeit. Jedes Mal, wenn ein Asset von einer Webseite abgerufen wird (z. B. Bilder, CSS, JavaScript…), wird eine TCP-Verbindung zum Server mit einer gewissen Latenzzeit initiiert. Die Latenz ist abhängig vom Netzwerk und basiert auf vielen Parametern wie z. B. der geographischen Entfernung zwischen dem Benutzer und dem Webserver. Verstärkt wird die Verzögerung durch das Verhalten der Browser, die die Anzahl der gleichzeitigen Verbindungen auf – in der Regel – maximal 5 limitieren.

Das HTTP/2-Protokoll [5] – Mitte 2015 veröffentlicht – ist wesentlich ressourcenschonender, gerade bei großen Binärdateien, da sie eben binär übertragen werden. Weiterhin gibt es jetzt nur noch eine TCP-Verbindung, und die Downloads werden parallelisiert und wir werden zusätzlich den Overhead der TLS-Negotiations los. Da HTTP/2 Anfragen gruppiert, wird der Server für einen kürzeren Zeitraum belastet und Server-Ressourcen werden früher wieder freigegeben. Neben dem Performancegewinn birgt HTTP/2 auch noch erhebliches Energiesparpotential für den Client. Messungen zeigen, dass HTTP/2 bei gleichen Latenzwerten (0s, 30ms, 200ms, 1s), etwa 8 Prozent weniger Energie verbraucht und damit energieeffizienter ist als HTTP/1.1 [6].

HTTP2 kann somit die Energieeffizienz einer Website auf Client-Seite verbessern. Wir als Website-Entwickler können die Energieeffizienz auf Client-Seite verbessern und somit Batterien schonen, einfach durch ein Update unserer Server bzw. Umstellung des HTTP-Protokolls.

Tausend Worte statt eines Bildes

Wir müssen uns mit der Optimierung unserer (benötigten) Assets auseinandersetzen. Nur Text ist auf die Dauer auch ein wenig langweilig.

Rufen wir uns vorher noch einmal ins Gedächtnis: Daten benötigen Elektrizität und das bedeutet einen CO2-Ausstoß. Dementsprechend wichtig ist es, nicht unnötige, unsichtbare Bits und Bytes mit uns herumzuschleppen, die letztlich aus unserer Faulheit resultieren. Ein dicker Brocken sind Grafiken und Bilder.

An dieser Stelle möchte ich ein kleines Rechenbeispiel anführen [7]. Zu Beginn der Corona-Pandemie war die Seite der Johns Hopkins University (nachfolgend JHU) eine der populärsten Seiten im Netz. Jeder wollte die neuen Fallzahlen sehen. Schauen wir uns also das Logo der JHU ein wenig genauer an. Ein SVG – vorbildlich – mit 21,67kb und ein paar Angaben darüber, mit welchem Programm es erstellt wurde etc. Genau dieses SVG habe ich mit einem Web-Tool namens SVGOMG (s. u.) ein wenig optimiert. Dabei konnten 12,15kb eingespart werden. Das sind immerhin fast 44 Prozent. Die JHU wurde im April 7,9 Millionen mal pro Tag aufgerufen – das entspricht einer Zahl von 237 Millionen Aufrufen im Monat. Multiplizieren wir die Views pro Monat mit unserer Ersparnis so kommen wir auf eine Gesamtersparnis von 2.948,7 Gigabyte. Um auf einen realistischen Wert zurückzugreifen und gleichzeitig eine Vergleichbarkeit zum Website Carbon Calculator herzustellen, veranschlagen wir einen Energieaufwand von 1,8 kWh pro einem Gigabyte [8].

Multiplizieren wir diesen Wert mit unserer Gesamtersparnis kommen wir auf 5.307,66 kWh. Ok, es wird ja auch einiges gecached, gerade bei wiederkehrenden Besuchern. Also muss dieser Faktor noch herausgerechnet werden. Da gerade bei diesem Beispiel täglich neue Besucher dazu kamen, ziehen wir einen geschätzten Wert von 25 Prozent Caching ab und landen dann immer noch bei einer Zahl von 3.980,7 kWh. Das entspricht dem Energieverbrauch von mehr als 2,5 Single-Haushalten pro Jahr und etwa 2,3t CO2.

Wir reden hier von einem kleinen Logo, nicht der Herr-der-Ringe-Trilogie im Streaming. Diese Rechnung unterstreicht sehr gut die Weisheit "Kleinvieh macht auch Mist". Übrigens kann man diese Rechnung auch mit Tracking-Pixeln (etwa 44 Byte) durchführen, diesen kleinen Plagegeistern, die wir nur allzu häufig untergeschoben bekommen. Ein weiterer Grund darauf zu verzichten.

Das Netz bietet eine Vielzahl an Tools, die uns beim Optimieren unserer Assets unter die Arme greifen können, seien es Vektor- oder Bitmap-Images. An dieser Stelle seien exemplarisch SVGOMG, Squoosh und ImageOptim erwähnt [9]. Diese Tools helfen intelligent dabei, das letzte bisschen überflüssigen Ballast aus den Bildern herauszupressen. Squoosh oder ImageOptim kommen mit einer Vielzahl an Web-Image-Formaten zurecht und kombinieren nahtlos einige Bildoptimierungstools wie z. B. MozJPEG, pngquant, Pngcrush, 7zip, SVGO und Google Zopfli. Ein netter Nebeneffekt bei ImageOptim ist, dass auch private EXIF-Metadaten von Digitalkameras weggeworfen werden. Man macht also auch noch was für den Datenschutz.

Als (für uns Designer schmerzhafte) Faustregel gilt: Die Bildqualität soweit herunterschrauben, bis es anfängt weh zu tun. Unsere Bilder sollten in der kleinsten Größe gespeichert werden, die sowohl in Bezug auf die Auflösung als auch auf die Bildqualität noch tolerierbar ist, gerade da unsere Bilder oftmals sowieso hinter einem farbigen Overlay verkommen. Wenn wir jetzt noch unsere HTML-Lektion gelernt haben und wir die Bilder je nach Viewport "ausliefern", lassen sich noch mehr Einsparungen erzielen.

<img srcset="elsa-anna-480w.jpg 480w,
              elsa-anna-800w.jpg 800w"
      sizes="(max-width: 600px) 480px,
             800px"
      src="elsa-anna-800w.jpg"
      alt="Elsa and Anna in the snow">

Bildoptimierungen lassen sich auch sehr gut in die Build-Pipelines des Web-Projektes integrieren. Ein kleiner Gulp-Task kann ebenfalls viel bewirken:

const mozjpeg = require('imagemin-mozjpeg') 
const pngquant = require('imagemin-pngquant'); 
const imagemin = require('gulp-imagemin'); 
const gulp = require('gulp'); 
gulp.task('default', () => {
   gulp.src('images/*')
     .pipe(imagemin([
       pngquant({quality: [0.5, 0.5]}),
       mozjpeg({quality: 50})
     ]))
     .pipe(gulp.dest('images/')) 
});

Es gibt noch unzählige Optionen für imagemin. Ein Blick in die Dokumentation lohnt sich also [10]. Und ein Task wie der obige ist auch schnell in eine "Responsive Image Pipeline" egal in welchem Task-Runner umgebaut.

Ich gehe an dieser Stelle bewusst nicht tiefer auf Videos ein, das würde den Rahmen sprengen. Allerdings können wir uns jetzt alle vorstellen, was Optimierungen von Videoinhalten ausmachen (s. Einleitung), wenn schon ein kleines SVG einen so großen Impact haben kann. Videos bringen – im Gegensatz zu Bildern – den Zeit-Faktor mit. Daher sollte man sich hier die Frage stellen "brauche ich wirklich das ganze Video oder tut’s ein Loop" (gerade, wenn das Video nur als Hintergrund verwendet wird)? Weiterhin muss auch die Art und Weise hinterfragt werden, wie wir unsere Videos einbetten. Verwenden wir doch besser <video></video> statt YouTube-Embedds. Vielen von uns ist nämlich nicht bewusst, dass wir durch das Embedden auch einiges an Skripten erben, die je nach dem auch mal größer sein können als das ganze Video selbst.

Ein weiter Aspekt, mit dem wir uns beschäftigen müssen, ist die Auffindbarkeit unserer Seite. Auffindbarkeit ist ein grundlegender Pfeiler positiver UX. Wir müssen uns also mit Suchmaschinenoptimierung (SEO) befassen. SEO hat auf den ersten Blick nichts mit der Energieeffizienz von Websites zu tun, dabei steckt hier die Optimierung schon im Titel. Das Ziel von SEO ist inhärent mit dem Ziel der Reduzierung des Energieverbrauchs verbunden. Machen wir unsere Website in Suchmaschinen leichter auffindbar, helfen wir Menschen dabei, die gewünschten Informationen schnell und einfach zu finden. Erfolgreiches SEO führt dazu, dass die Menschen weniger Zeit damit verbringen, im Web nach Informationen zu suchen und dadurch weniger irrelevante Seiten besuchen, die nicht ihren Bedürfnissen entsprechen. Das bedeutet, es wird effektiv weniger Energie für unnötiges Surfen verbraucht.

Mit diesem Schritt einher geht auch die Optimierung unseres textualischen Contents. Ähnlich wie bei der Suchmaschinenoptimierung wirkt sich effektives Copywriting positiv auf die Energiebilanz unserer Website aus. Wenn wir darauf achten, dass Menschen ihre Zeit nicht damit verschwenden, durch belanglose Inhalte zu waten, wirkt sich das positiv auf die UX und auch die CO2-Bilanz aus. Klares und zielgerichtetes Texten trägt dazu bei, die vergeudete Zeit im Internet und damit auch die vergeudete Energie zu reduzieren. Übrigens scheint es ein (sinnvoller) Trend zu sein, sog. Lite Websites anzubieten – Nur-Text-Websites, die einem Zweck dienen: zu informieren. Und ja, auch Facebook, Twitter und Reddit gibt’s in der Lite-Version [11]. Denkt daran:

"When Information is cheap, attention becomes expensive" – James Gleick.

Ein weiterer sinnvoller Trend ist der Einsatz von statischen Website-Generatoren, um statt dynamischer – oft unnötig rechenintensiver – Seiten bereits vorgefertigte statische Seiten zu liefern. Back to the roots: Webseiten lassen sich noch immer als statische Dateien in HTML, CSS und JS schreiben oder eben durch statische Website-Tools wie Jekyll, HUGO, Eleventy, usw. generieren [12]. Eine gute Gedankenstütze, die einige dieser Punkte zusammenfasst, bietet die Green UX Checkliste von Manoverboard [13].

:root, 
body.light {
   --background-color: #fff;
   --text-color: #333; 
}

 body.dark {
   --background-color: #333;
   --text-color: #fff;
}

@media (prefers-color-scheme: dark) {
   body {
     --background-color: #333;
     --text-color: #fff;   
  }
  .mode-toggle {
     display: none;
  }
} 
body {
   background-color: var(--background-color);
   color: var(--text-color); 
}

Optimierung setzt auch an den Modellvorstellungen wie wir unsere Web-Projekte organisieren an. Mobile Endgeräte haben was die Page-Views angeht den Desktop lange schon überholt. Dementsprechend müssen wir uns auch an Paradigmen wie "Mobile First" gewöhnen. Bei Mobile First optimieren wir unsere Inhalte von Beginn an auf die Nutzung durch Smartdevices. Neben dem Augenmerk auf den Ressourcenverbrauch hilft uns dieser Ansatz auch Struktur in unser Web-Projekt zu bekommen und die mobilen Ansichten nicht als Overwrites der Desktop Styles sondern als eigenständige Bausteine direkt von Beginn an zu konzipieren. Die Idee hinter Mobile First stammt von Luke Wroblewski, einem Product Director bei Google aus dem Jahre 2009 - Mobile First ist eigentlich ein echt alter Hut [15]. Allerdings ist die Denkweise leider immer noch nicht in allen Web-Projekten angekommen. Mobile First zwingt uns zur Optimierung und zur Sparsamkeit.

Wo wir gerade beim Thema "Sparsamkeit" sind: Stellen wir uns wie Marie Kondō die Frage "Does it spark joy"?

Ist das Kunst oder kann das weg? Das kleine Wörtchen Nein als Design-Tool hilft uns immens beim Energiesparen. Die daraus folgende Datensparsamkeit hilft uns nicht nur beim nachhaltigen Einsatz von Ressourcen, sondern auch bei der Umsetzung der DSGVO.

Um es mal ein wenig plakativ auszudrücken: Die Größe einer durchschnittlichen Website hat sich von 1996 bis 2016 von 14,1kB auf 2,5MB vergrößert. 2019 wurde bereits ein Durchschnittswert von 4MB erreicht – Tendenz steigend. Wir haben zwar weniger inhaltlich zu sagen, das aber mit immer mehr Megabytes. Eine lustige Art wie wir uns diese Entwicklung einmal selbst vor Augen halten können, bietet die Website "Fit on a Floppy" [16]. Hier können wir testen, ob unsere jetzige Website noch auf einen 1,44MB-Datenträger passen würde – wenn nicht, gibt es auch gleich ein paar Abspecktipps.

Performance Budgets

Wann haben wir uns das letzte Mal ernsthaft Gedanken darüber gemacht, wie viele Daten wir über die Leitung blasen? Hier ein Framework, da ein paar Videos inkl. Autostart, ein paar Webfonts für drei unterschiedliche Icons und zu guter Letzt die ultrahochauflösenden Bilder des Firmenvorstandes für die Thumbnails. Wir haben durch die steigende Bandbreite verlernt, diesem Aspekt Beachtung zu schenken. Und oftmals sehen gerade wir Designer die Performance nicht als Teil der User Experience an. Das müssen wir allerdings wieder lernen, am besten, indem wir uns ein bisschen Selbstdisziplin auferlegen. Das Stichwort an dieser Stelle heißt "Performance Budget".

Ein Performance Budget ist eine Obergrenze für Webseiten, die von uns nicht überschritten werden darf. Es kann eine maximale JavaScript-Bundle-Größe, die Gesamtgröße an Bildern, eine bestimmte Ladezeit (z. B. Time-to-Interactive in unter 5s bei 3G/4G) oder ein Schwellenwert für eine beliebige Anzahl anderer Metriken sein. Aber Performance Budget sind nicht nur Schwellenwerte. Ähnlich wie ein finanzielles Budget sind sie etwas, das uns zwingt, bewusster auszugeben. Man könnte es als Währung betrachten, die wir im Sinne der Benutzererfahrung ausgeben bzw. mit der wir handeln. JavaScript kostet Zeit und Energie (sowohl während, als auch nach der Entwicklung). Performance Budgets sind eines der wenigen wirklich erfolgversprechende Tools und dabei so simpel. Ein Performance Budget braucht allerdings eine Metrik gegen die wir unseren "Erfolg" messen können. Dabei können diese Metriken sog. Milestones, mengenbasierte oder regelbasierte Metriken sein.

Milestones umfassen Timings, die auf der Benutzererfahrung beim Laden einer Seite basieren (z. B. Time-to-Interactive, First Contentful Paint). Milestones lassen sich auch kombinieren, um den gesamten Ablauf während des Ladevorgangs der Seite darzustellen. An dieser Stelle kann es auch ein wenig fancy werden. "Zeit bis zum ersten Tweet" ist auch eine valide Milestone-Metrik.

• Mengenbasierte Metriken basieren auf Größen (z. B. Größe des verwendeten JavaScripts (KB/MB), Anzahl der HTTP-Anfragen). Diese konzentrieren sich auf die Erfahrung innerhalb des Browser.
• Regelbasierte Metriken stützen sich auf Bewertungen, die von Tools wie Lighthouse oder WebPageTest generiert werden. Häufig eine einzelne Zahl oder eine gesamte Reihe zur Bewertung Ihrer Website.

Performance Budgets lassen sich sehr gut in Continuous-Integration-Prozesse integrieren, indem eine Warnung oder ein Fehler beim Build-Prozess ausgegeben wird, wenn gegen das Performance Budget verstoßen wird. Valide Beispiele für Budgets sind:

• Unsere Detailseite muss weniger als 170 KB JavaScript auf mobilen Endgeräten enthalten.
• Unsere Suchseite darf nur maximal 2 MB an Bildern auf dem Desktop-Rechner enthalten.
• Unsere Homepage muss in weniger als 5s bei Slow 3G/Moto G4 laden und interaktiv sein.
• Unser Blog muss bei den Lighthouse Performance Audits mindestens 80 Punkte erzielen.

Oftmals gehen die Budgets miteinander einher, wie in den Beispielen zu sehen ist. Seiten, die bei schlechten Verbindungen nicht gut performen, wenn zu viel Ballast über die Leitung geschickt wird, werden im Umkehrschluss auch nicht gut in einem Tool wie Lighthouse abschneiden.

Wenn man mit Performance Budgets beginnen will, bietet das Online-Tool Performance Budget Calculator gute Unterstützung [17]. Man startet mit einem Ziel, das man erreichen möchte: Ich möchte, dass meine Website in 2 Sekunden bei einer Mobile 3G-Slow-(780 Kbps)-Verbindung geladen ist. Danach kann man interaktiv an einigen Schrauben – HTML, CSS, JavaScript, Bilder, Video, Fonts – drehen und kann zum guten Schluss das Budget gleich gegen Lighthouse testen. Da es sich um ein Tool handelt, das den Einstieg in die Materie erleichtern soll, werden nur mengenbasierte Metriken angeboten. Das Budget lässt sich zum Schluss auch zur Integration in die heimische CI-Pipeline als json-File herunterladen:

[
  {
    "path": "/*",
    "timings": [
      {
        "metric": "interactive",
        "budget": 3000
      },
      {
        "metric": "first-meaningful-paint",
        "budget": 1000
      }
    ],
    "resourceSizes": [
      {
        "resourceType": "script",
        "budget": 125
      },
      {
        "resourceType": "total",
        "budget": 300
      }
    ],
    "resourceCounts": [
      {
        "resourceType": "third-party",
        "budget": 10
      }
    ]
  }
]

Dieses budget.json-File setzt die folgenden Budgets [18]:

• Ein Budget von 3000ms für Time to Interactive.
• Ein Budget von 1000ms für den First Meaningful Paint.
• Ein Budget von 125 KB für die Gesamtmenge an JavaScript auf der Seite.
• Ein Budget von 300 KB für die Gesamtgröße der Seite.
• Ein Budget von 10 Requests für die Anzahl an Requests, die an dritte gemacht werden dürfen.

Alleine über Performance Budgets ließe sich schon ein ganzer Artikel schreiben. Eine schöne Sammlung an Links zum Thema findet sich ebenfalls auf der Seite des Performance Budget Calculators [19].

An dieser Stelle möchte ich gerne noch eine Anmerkung zur Continuous Integration machen. Auch hier lässt sich Energie sparen. Nicht jede geänderte Farbe im Frontend oder jedes Komma im Text muss nach dem Push sofort die komplette Kaskade in Gang setzen, die zuletzt noch etliche Gigabyte in Docker-Container verpackt. So bequem es auch sein mag, hier gibt es kräftiges Einsparpotential.

Lean HTML

Auch was den HTML-Code angeht lassen sich mengenmäßige Einsparungen vornehmen. Semantisches HTML ist die Antwort, geht es um Zugänglichkeit, Auffindbarkeit oder schlichtweg um schlanken Code.

<div id="saveChanges" tabindex="0" role="button" aria-pressed="false">Save</div>
<!-- vs. -->
<button id="saveChanges">Save</button>

Das obige Beispiel zeigt, wieviel Ornamentierung notwendig ist, um eine vom Browser geschenkte Funktionalität und Ausprägung (schlecht) zu imitieren.

Nehmen wir z. B. das Grid: Vom Druck kommend hat es seinen Siegeszug als Layouting-Werkzeug bis ins Webdesign geschafft. Grids sind heutzutage nicht mehr aus dem Webdesign wegzudenken und bilden das Kernstück so vieler Frameworks wie z. B. Bootstrap oder ZURB Foundation [20].

Das Tolle ist, wir sind mit der jetzigen Technik in der Lage, komplexere Grids zu konzipieren als je zuvor und dabei gleichzeitig weniger Code schreiben zu müssen. Weder floats noch Flexbox erlauben wirklich komplexe Grid-Strukturen. Immer fehlen ein paar Features. Floats bieten mir keine Möglichkeiten, Elemente nach oben oder unten zu verschieben. Die Flexbox erlaubt mir eine strikte Trennung von Gestaltung und HTML-Code, eignet sich aber eher für lineare Strukturen als für verschachtelte. Das CSS-Grid ermöglicht "echte" Gestaltungsraster mittels CSS zu erstellen. CSS Grids wirken direkt auf dem Elternelement. Auf diesem wird das Raster definiert und die enthaltenen Kindelemente positioniert. Es bedarf nur der Angabe display:grid; auf dem Elternelement und der Eigenschaften grid-template-columns und grid-template-rows und fertig ist die Rasterlaube.

.container {
  height:100vh;
  display: grid;
  grid-template-rows: 5rem 1fr 12.5rem;
  grid-template-columns:25% 25% 25% 25%;
}

Mit so wenig Code lässt sich ein CSS-Grid mit drei Zeilen und drei Spalten erstellen. 100 Pixel Höhe für die erste und letzte Zeile und dazwischen soviel Platz wie gebraucht wird. Die mittlere Zeile verwendet die Einheit 1fr (1 Fraction). Die Verwendung dieser Einheit erlaubt es, dass sich die zweite Zeile über den gesamten noch zur Verfügung stehenden Raum erstrecken darf. Die vier Spalten sind jeweils 25 Prozent und die mittlere 50 Prozent breit.

<div class="container"> 
  <header>header</header> 
  <article>article</article> 
  <aside>aside</aside> 
  <footer>footer</footer>  
</div>

header {
  grid-column: 1 / 5;
  grid-row: 1 / 2;
}

article {
  grid-column: 1 / 4;
  grid-row: 2 / 3;
}

aside {
  grid-column: 4 / 5;
  grid-row: 2 / 3;
}

footer {
  grid-column: 1 / 5;
  grid-row: 3 / 4;
}

Wie schön, dass uns jetzt auch Google Chrome durch seine experimentellen Features einen schöneren Blick ins Innere des CSS-Grids gewährt.

Mit floats wäre sowohl beim CSS als auch im HTML-Code wesentlich mehr Text notwendig gewesen, um nur annähernd dieses Ergebnis zu erzielen. Code-Reduzierung bei gleichzeitiger Steigerung der Flexibilität und Effizienz.

Font-Spartag

Wo können wir noch ansetzen? Bei den Fonts, des Designers Lieblinge. Designer lieben Typografie – wir alle lieben Typografie. Aber warum müssen gleich alle 50 erhältlichen Schriftschnitte in unserer Website referenziert werden, wenn wir doch nur Regular und Bold brauchen? Auch Dynamik-Fonts sind da nicht die Lösung, sondern eher der Beginn eines neuen Rebound-Effekts. Überlassen wir die Typografie doch den Betriebssystemen. Deren Designer haben die schönsten Fonts für die Anzeigen in den jeweiligen Systemen bereits für uns ausgesucht – von San Francisco bis Roboto. Diese Fonts kann man sich einfach und schnell ausleihen mit dem sog. System Font Stack:

font-family: -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,"Helvetica Neue",Arial,"Noto Sans",sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji";

Da ist nun wirklich für jeden etwas dabei. Tolle Fonts erhalten und gleichzeitig noch die Performance steigern. Und wenn es denn mal unbedingt etwas anderes sein muss, finden sich in dem Artikel Performant Web Fonts von Joshua Stopper ein paar gute Tipps, wie sich mit Custom Web Fonts Ressourcen sparen lassen [21].

Fragen über Fragen

Formulare spielen bei der Computer-Benutzer-Interaktion eine wichtige, wenn nicht zentrale, Rolle. Allerdings erheben wir in diesen Formularen sehr häufig Daten, die für den Benutzer im aktuellen Kontext nicht verständlich sind bzw. die Frage aufwerfen, warum diese eigentlich benötigt werden! Vielleicht sind wir auf Business-Ebene über das Ziel heraus geschossen oder haben, in vorausschauender Manier, Daten abgefragt, die wir irgendwann einmal brauchen könnten. Diese liegen jetzt ungenutzt auf dem Webserver und im CRM und wandern all nächtlich ins Backup.

Eine Möglichkeit, wie wir dem entgegenwirken können, sind Frageprotokolle. Frageprotokolle ermöglichen es, bestehende Formulare und auch Formulare, die gerade erst entworfen werden, gezielt zu analysieren.

Ein Frageprotokoll listet auf:

• Jede Frage die wir stellen,
• wer innerhalb unser Organisation die Antworten zu der Frage verwendet,
• wozu wir die Antworten verwenden,
• ob eine Antwort notwendig oder optional ist und
• was passiert, wenn ein Benutzer nur veraltete oder falsche Angaben macht, um durch das Formular durchzukommen.

Wenn wir merken, dass wir eine Frage nicht beantworten können, bzw. die Antwort keinen ersichtlichen Nutzen für uns, unser Produkt oder den Benutzer generiert, dann können wir auf die Erhebung des jeweiligen Datensatzes verzichten. Es muss uns klar sein, dass alle Daten, die wir erheben auch Kosten generieren…

Genauso wichtig wie unsere technischen und inhaltlichen Optimierungen und Reduzierungen ist es, auf dem Laufenden zu bleiben und sich kontinuierlich eine Vorstellung darüber zu machen, wie Technologien sich in Bezug auf Nachhaltigkeit verändern. Wir brauchen einen verständlichen Kontext, der uns Web-Schaffende anleitet, vermehrt nachhaltig zu denken und dem entsprechend zu handeln. Wir müssen wissen, wie viel CO2-Emissionen das Internet erzeugt, wenn man surft, kommuniziert, ein Video streamt oder eine Website designt. Solide Informationen über die CO2-Bilanz von Online-Aktivitäten sind – zugegeben – schwer zu finden, aber es werden immer mehr. Das Thema tritt in den Focus und wir fangen jetzt an, zu verstehen, dass, wie bereits oben erwähnt, das Internet die größte kohlebetriebene Maschine auf dem Planeten ist. Nicht nur "die"” müssen etwas tun, sondern auch wir. Das betrifft unsere eigenen privaten Surfgewohnheiten wie auch unsere professionelle Arbeit.

Neben dem Schaffen eines Verständnisses für ein nachhaltiges Internet ist es wichtig, unsere Erfahrungen und Learnings zu kommunizieren, zu thematisieren und damit den Ball weiter am Rollen zu halten.

Ein guter Anfang und etwas Futter für die Leseliste ist der Artikel von James Christie zum Thema Sustainable Web Design aus dem Jahr 2013 [22]. Damit hat alles angefangen. Wenn wir tiefer in die Materie einsteigen wollen, bietet sich Designing for Sustainability von Tim Frick aus dem O’Reilly Verlag an [23].

Von dort aus geht es zum hervorragenden Artikel von Eric Bailey auf A List Apart "Paint the Picture not the Frame" [24], der zwar nicht im Nachhaltigkeitskontext steht, aber trotzdem ein paar wichtige Aspekte zum Thema enthält. Auch bei Wholegraindigital, den Machern hinter dem Website Carbon Calculator finden sich sehr lesenswerte Beiträge [25].

Nachhaltiges Webdesign ist eine Win-Win-Situation für alle!

Wie jede gute Bewegung braucht es auch ein Manifest, an dem wir uns orientieren können. Das Sustainable Web Manifesto ist dafür eine ideale Anlaufstelle und braucht noch ein paar Unterstützer, denn nachhaltiges Webdesign ist eine Notwendigkeit für uns alle [26]!

E wie ENGAGIEREN

Wenn wir von einer Sache überzeugt sind, wollen wir uns auch dafür ins Zeug legen und andere davon begeistern bzw. ein Teil der Bewegung werden. Auch Kunden lassen sich von einem nachhaltigen Webdesign-Konzept überzeugen! Jeder mag TORTE!

Nachhaltiges Webdesign ist eine Win-Win-Situation für alle direkt und indirekt Beteiligten und liefert uns sehr gute Argumente: Wir verbessern die Usability und User Experience, erzeugen klare und erfassbare Designs, verzichten auf Bullshit wie es Brad Frost so schön formulierte [27], erzielen bessere SEO-Rankings, benötigen kürzere Ladezeit und kommen gleich mit einer content- und damit auch mobil-optimierten Seite um die Ecke. Und zu guter Letzt, wir tun etwas für die Umwelt [28]!

Es gibt viele sinnvolle Initiativen zu dieser Thematik, die unsere Unterstützung gebrauchen können, um mehr Awareness für ein nachhaltiges Internet zu schaffen. Dazu zählen u. a. die Tech Impact Makers, ClimateAction.tech, UnternehmensGrün und Bits & Bäume[29].

Wir Webdesigner und -entwickler spielen eine maßgebliche Rolle dabei, wie sich das Web der Zukunft entwickelt. Sowohl bei der Konzeption, dem Design der Programmierung und auch der Nutzung können wir damit beginnen, das Internet bewusster und achtsamer zu nutzen. Am besten sollten wir gleich versuchen, beim Redesign oder beim nächsten neuen Projekt Nachhaltigkeit – genau wie UX – im Projekt zu verankern. Wir müssen unsere Kollegen, Kunden und uns selbst davon überzeugen, Nachhaltigkeit zu einem Designprinzip zu machen.

Testet, optimiert, reduziert, thematisiert und engagiert euch! Dann klappt’s auch mit der TORTE.

Henning Fries

Henning Fries ist UI- und UX-Designer und beschäftigt sich mit Themen wie Accessibility, Nachhaltigkeit, UX und UI.
>> Weiterlesen

Symbiose von Informatik und Handwerk

Open Source in der Automobilbranche

Nachhaltigkeit in der Software-Architektur

Klimawandel, KI & Co.: Welche Skills brauchst Du für die Welt von morgen?

Das Blue-Zone-Unternehmen

Barrierefreiheit in Software-Projekten umsetzen