„Optimierung bestehender Websites hinsichtlich Performance, Sicherheit und SEO“Aus eurer Anzeige. Meine Arbeitsprobe dazu, an eurer eigenen Startseite gemessen

Eure Startseite kann am Handy über 4,3 MB leichter werden.

Ohne dass sich am Design etwas ändert.

Vorher und nachher ansehen Anleitung ansehen

Das Einbaupaket: 8 Projektbilder als WebP · Video in 1280 × 720 · Standbild · Anleitung

Auf ein kurzes Ja schicke ich euch Bilder und Video, sie liegen nicht öffentlich im Netz.

Erster Bildschirm von www.e-site.com in der Handy-Ansicht: Slide „Technisch anspruchsvolle Plattformen“ — **www.e-site.com** · Startseite am Handy
gemessen am 28.10.

Vieles ist bei euch schon sauber gelöst. Zwei Stellen bringen am Handy richtig viel, gemessen nur öffentlich, so wie ein Besucher eure Seite öffnet.

Chromium mit Pixel-7-Profil, jeweils ohne Scrollen · heute: vier Läufe, je 7,50 bis 7,53 MB (zwei gedrosselt, zwei ohne Drosselung) · mit den neuen Dateien: der Lauf ohne Wischen mit Fast 4G, 3,20 MB · Vorher und nachher · So habe ich gemessen

Schon richtig gut: ein schnelles Startbild, SEO-Grundlagen und Schema, Sicherheits-Kopfzeilen, WP Rocket mit kritischem CSS, alt-Attribut an allen Bildern.

Schon einmal gemacht: Bei einem Hersteller lädt die WordPress-Startseite am Handy 1,0 statt 7,4 MB.

Vorher und nachher

Gleicher erster Bildschirm, weniger als die Hälfte der Daten

Eure Startseite zweimal geladen: wie heute und mit den neuen Dateien. Getauscht sind nur die acht Projektbilder und das Video, alles andere kommt unverändert von eurem Server.

Übertragen in 30 Sekunden

Heute7,59 / 7,60 MB

Neue Dateien, mit Wischen wie heute3,24 MB

ohne Wischen 3,20 MB

Projektbilder vollständig

Heute6,85 / 6,91 s

Neue Dateien4,66 / 4,70 s

Video spielbereit

Heute6,62 / 6,70 s

Neue Dateien2,74 / 2,79 s

Startbild (LCP), kein Unterschied

Heute2,29 / 2,31 s

Neue Dateien2,30 / 2,36 s

Am ersten Bildschirm ändert sich nichts, der Gewinn liegt in der Leitung: Bilder und Video sind heute nach 8,3 Sekunden übertragen, mit den neuen Dateien nach 4,6. Bis dahin ist die Leitung heute voll ausgelastet.

Geladene Daten über die Zeit

Heute
Neue Dateien
durchgezogen Lauf 1, gestrichelt Lauf 2 (bei den neuen Dateien ohne Wischen)

Übertragene Bytes je Lauf, gemessen im Browser. Nach 12 Sekunden kam in keinem Lauf mehr nennenswert etwas dazu. Zum Ablesen die Kurve antippen oder mit der Maus darüberfahren. Als Tabelle

Gerät: Pixel 7 (Chromium-Profil)Netz: „Fast 4G“ aus den Chrome-Entwicklerwerkzeugen, 8,1 Mbit/s, 165 msProzessor ungebremst, Cache aus28.10.2026, 13:23 bis 13:46 Uhrje Fassung zwei Läufe

Ein Besucher wischt nach 5 Sekunden zu den Projekten

Bei 5,8 Sekunden ist er dort. Bis dahin sehen beide Fassungen gleich aus. Danach lädt heute das erste Projektbild noch bis knapp 7 Sekunden, mit den neuen Dateien ist es gleich ganz da.

4,5 skurz vor dem Wischengleich
Heute4,5 s
Neue Dateien4,6 s
6,0 sgerade angekommenUnterschied
Heute6,0 s
Neue Dateien6,1 s
6,5 s0,7 s nach AnkunftUnterschied
Heute6,5 s
Neue Dateien6,6 s

Projektbild unkenntlich gemacht, es ist ein Motiv eures Kunden.

Das Einbaupaket

Die acht Projektbilder als WebP unter euren Dateinamen, das Video in 1280 × 720, ein Standbild aus seinem ersten Bild und eine Anleitung für WordPress mit Elementor: Bilder austauschen, Video mit Standbild einsetzen, am Handy nur laden, was gebraucht wird. Ohne zusätzliches Plugin.

Es sind eure Bilder und euer Video von der Startseite, nur für euch neu kodiert. Die Anleitung könnt ihr schon jetzt ansehen.

Anleitung ansehen

Performance

Was ich auf eurer Startseite gemessen habe

Vier Stellen, die Kernwerte jeweils in mindestens vier Messläufen gleich. Die Rohwerte stehen unten bei den Belegen.

01 · Bildergrößter Hebel

3,4MB0,36MB

Acht Projektbilder im Referenz-Slider

Die Bilder sind 960 × 960 Pixel groß und als PNG gespeichert, je 303 bis 608 kB. In derselben Pixelgröße als WebP sind es zusammen 0,36 MB, die Transparenz bleibt. Am Handy laden sie, nachdem die Projektliste vom Server gekommen ist, auch wenn niemand bis zum Slider scrollt. Ein Teil eurer Bilder kommt schon als WebP, diese acht noch nicht. Bildvergleich im sichtbaren Motiv: SSIM rund 0,95 bis 0,98, 1 wäre identisch.

02 · Videoschnell erledigt

2,1MB0,82MB

Hintergrundvideo: neu kodiert oder am Handy ganz aus

Das Video hat 1920 × 1080 Pixel, läuft am Handy in einer Fläche von 372 × 330 CSS-Pixeln ohne Vorschaubild und lädt bei jedem Aufruf mit, auch ohne Scrollen: in meinen Messläufen 2,05 bis 2,14 MB. Sein Inhaltsverzeichnis steht am Dateiende. Deshalb holt der Browser das Video bei langsamer Leitung in drei Teilabrufen und hat das erste Bild rund 1,0 Sekunden nach dem ersten Abruf. In 1280 × 720 wiegt derselbe Clip 0,82 MB, kommt in einem Abruf und hat das erste Bild nach 0,23 bis 0,28 Sekunden, beides gemessen mit Fast 4G.

Steht in Elementor „Play On Mobile“ auf aus, lädt das Handy laut Elementor-Hilfe kein Video, bei euch auf der Stufe „Mobil Hochformat“ bis 480 px. An seiner Stelle ist ein Standbild gedacht (17 kB, bekommt ihr von mir). Welcher Weg, entscheiden eure Designer.

03 · DoppeltKleinigkeit

2 × 180kB

Dasselbe Foto lädt zweimal

konfi.jpg und konfi-1.jpg sind Byte für Byte gleich. Beim Durchscrollen laden beide, einmal als Banner-Hintergrund und einmal als Bild weiter unten. Eine Datei für beide Stellen spart 180 kB.

04 · Dateienauf Staging testen

92 + 68

CSS- und JavaScript-Dateien bis „fertig geladen“

WP Rocket lädt euer CSS am Handy schon asynchron und setzt kritisches CSS vorab, das ist gut gelöst. Von 67 Skripten tragen 65 weder defer noch async, und 87 % des CSS bleiben beim Aufruf am Handy ungenutzt. Was davon später laden darf, würde ich Skript für Skript auf Staging testen.

Barrierefreiheit

Vier Punkte, die schnell gehen

Automatisch geprüft mit axe-core 4.14. Die ersten drei Punkte sind Regeln aus WCAG 2.2, Stufe A und AA, und kamen in zehn von zehn Läufen. Der vierte ist eine Best-Practice-Regel von axe, geprüft und gemeldet in den vier neuen Läufen.

Links bekommen einen Namen

Die sechs Social-Icons im Fuß, der Menü-Knopf im mitlaufenden Kopf und ein Kontakt-Symbol haben heute keinen Namen, den ein Screenreader vorlesen kann. Ein aria-label je Link genügt.

Vorschlag

aria-label=
  "E-SITE.com bei Instagram"

„Weiterlesen »“ auch im Namen

Sichtbar steht „Weiterlesen »“, als Name hinterlegt ist „Mehr über …“. Steht der sichtbare Text samt » vorn im Namen, finden ihn auch Menschen, die per Sprache steuern.

Vorschlag

aria-label=
  "Weiterlesen » Angriff über
   UpdraftPlus …"

1,57 → 4,69 : 1

Ein hellerer Ton desselben Rots

Rot auf Petrol erreicht laut axe-core 1,57 : 1, Grau #717171 auf Petrol 1,81 : 1. WCAG verlangt für große Schrift wie die rote Zeile 3 : 1, für normale Schrift wie das Grau 4,5 : 1. Kontrastmeldungen insgesamt: 10 im ersten Aufruf, 31 nach dem Durchscrollen.

Beispielton als Vorschlag, den genauen Ton legen eure Designer fest.

Die H1 auch für Screenreader

„Technisch anspruchsvolle Plattformen“ ist die einzige H1 der Startseite. In Elementor ist sie auf allen sieben Gerätestufen ausgeblendet, damit fehlt sie auch Screenreadern. axe meldet das als page-has-heading-one. Mit der Klasse screen-reader-text bleibt sie unsichtbar und wird trotzdem vorgelesen.

Vorschlag

Advanced → Responsive:
  Hide On … aus
Advanced → CSS Classes:
  screen-reader-text

Euer Theme nutzt die Klasse schon für „Skip to content“. Sie blendet per clip-path aus, nicht per display:none, Screenreader lesen den Text also vor.

Vorschlag

So würde ich in der ersten Woche anfangen

Vom größten Hebel zur Feinarbeit, jeder Schritt mit Messung vorher und nachher.

Schritt 1

Projektbilder

Die acht WebP aus dem Paket einsetzen und die Bilder im Slider erst laden, wenn er ins Bild kommt.

Mein Vorschlag fürs erste Ticket

Schritt 2

Video

Die 1280er-Fassung mit Standbild aus dem Paket, am Handy wahlweise nur das Standbild. Welche Variante, entscheiden eure Designer.

Schritt 3

Doppeltes Foto und Vorladen

Eine Datei für beide Stellen, und testen, welches Bild am Handy zuerst laden soll.

Schritt 4

Barrierefreiheit

Namen für die acht Links, die vier „Weiterlesen“ angleichen, die H1 für Screenreader, Kontraste mit euren Designern abstimmen.

Schritt 5

Skripte

Auf Staging testen, welche Skripte WP Rocket verzögert laden darf, danach der Messbericht.

Am Ende der Woche liegt bei euch ein Bericht mit allen Werten vorher und nachher, gemessen mit derselben Methode wie auf dieser Seite.

Über mich

Wer das für euch umsetzt

Ich bin Burak Karaman, Webentwickler aus Remscheid, und arbeite als Freelancer remote. Ich messe vorher und belege das Ergebnis danach mit derselben Methode.

„Burak hat die Ladezeit unserer WordPress-Seite deutlich verbessert und alle Änderungen sauber dokumentiert.“

Kunde aus der Produktfotografie, über den Auftrag zur Ladezeit

über 80

Pull Requests im Hauptzweig seit September

Für einen Anbieter von Software für Rechnungs- und Belegmanagement: klickbare Prototypen neuer Programmmodule im Design-System des Kunden, auf Deutsch und Englisch, mit Git. Seit Mitte Oktober arbeite ich dort auch mit Jira: Ein Ticket samt Akzeptanzkriterien und Skizzen habe ich eingeschätzt und als klickbare Lösungsseite über den Team-Chat geliefert.

7,4 → 1,0

MB auf der Startseite eines Herstellers

Zweisprachige WordPress-Seite mit WPML und Elementor Pro, am Handy vorher und nachher mit derselben Methode gemessen. Vorher lud das Handy dort 4,2 MB Video schon beim Aufruf.

375

alte Adressen in einem Schritt am Ziel

Beim selben Kunden, von über 1.000 geprüften alten Adressen aus Sitemaps, Internet-Archiv und Search Console.

WordPress-Seiten in monatlicher Betreuung

Ein Gesundheits-Blog seit August und die Website des Herstellers seit Oktober.

Nächster Schritt

So kann ich ab nächster Woche für euch arbeiten.

Für eure Kundenprojekte genauso wie für eure eigene Seite. Nennt mir eines, dann messe ich dessen Startseite auf dieselbe Weise, als Arbeitsprobe ohne Kosten. Ihr bekommt das Ergebnis ohne meinen Namen, zum Weitergeben an euren Kunden.

Kurz Ja sagen

Die Anleitung liegt oben, Bilder und Video schicke ich euch auf ein kurzes Ja.

Einschätzung vorab

Vor jedem Ticket bekommt ihr eine Einschätzung in Stunden.

Übergabe mit Messung

Ihr bekommt das Ergebnis mit Werten vorher und nachher, so wie auf dieser Seite.

Antwort innerhalb eines Werktagsremote, kurzfristig startklargern langfristig

Burak Karaman

Webentwicklung · Remscheid

Alle Messwerte zu eurer Seite vom 28.10.2026, öffentlich abgerufen.
Zu den Belegen

Für die Technik

Alle Messungen zum Aufklappen

Zehn ausgewertete Messläufe am 28.10.2026, nur öffentliche Abrufe wie bei einem normalen Besuch, ohne Formulare und ohne Login.

So habe ich gemessen Profil, Läufe, Werkzeuge

Chromium (Playwright 1.64, Headless Shell) mit dem Geräteprofil Pixel 7: 412 × 839 CSS-Pixel, Pixeldichte 2,625, Handy-Browserkennung, Cache aus. Je Lauf ein normaler Seitenaufruf von https://www.e-site.com/. Die Barrierefreiheitsprüfung (axe-core 4.14.0) lief lokal im geladenen Browser, ohne zusätzlichen Abruf.

Lauf	Uhrzeit	Netz und Prozessor	Ablauf
1	01:56	gedrosselt: 1,6 Mbit/s, 150 ms, Prozessor × 4	nicht gescrollt, gewartet bis Netzruhe
2	01:59	gedrosselt wie Lauf 1	wie Lauf 1
3	02:04	gedrosselt wie Lauf 1	erst gewartet, dann einmal bis ganz unten gescrollt
4	02:06	gedrosselt wie Lauf 1	wie Lauf 3
5	09:21	ohne Drosselung	wie Lauf 3
6	09:22	ohne Drosselung	wie Lauf 3
7–10	13:23–13:46	Fast 4G: 8,1 Mbit/s, 165 ms, Prozessor ungebremst	vorher und nachher, siehe unten

Datenmenge je Lauf 7,50 bis 7,53 MB ohne Scrollen

Lauf	bis „fertig geladen“	ohne Scrollen gesamt	nach Durchscrollen	Abrufe
1 (gedrosselt)	–	7,50 MB	–	192
2 (gedrosselt)	–	7,50 MB	–	192
3 (gedrosselt)	1,96 MB	*	8,44 MB	205
4 (gedrosselt)	1,96 MB	*	8,44 MB	205
5 (ohne Drosselung)	1,96 MB	7,53 MB	8,56 MB	203
6 (ohne Drosselung)	1,96 MB	7,53 MB	8,56 MB	203

* In Lauf 3 und 4 begann das Scrollen, bevor die Projektbilder nachluden. In Lauf 5 und 6 starteten die acht Bilder 13,8 bzw. 12,7 Sekunden nach dem Aufruf, rund sieben Sekunden nach dem load-Ereignis, ohne dass gescrollt wurde. Wer in diesen beiden Läufen nur bis zum load-Ereignis misst, sieht deshalb 2,0 MB statt 7,5 MB. Mit Fast 4G (Lauf 8 und 10) kam die Projektliste schon vor dem load-Ereignis, dort waren es bis load 6,1 MB. Wann die Bilder laden, hängt also davon ab, wann die Liste vom Server kommt.

Zusammensetzung in Lauf 5 ohne Scrollen: acht Projektbilder 3,40 MB, Video 2,11 MB, alles andere 2,02 MB. Alle Abrufe liefen über HTTP/2.

Vorher und nachher: die vier Läufe Fast 4G, Tausch per Route

Chromium wie oben, dazu das Netzprofil „Fast 4G“ aus den Chrome-Entwicklerwerkzeugen: 165 ms Latenz, 8,1 Mbit/s herunter, 1,35 Mbit/s hoch. Prozessor ungebremst, Cache aus, Bildschirmfotos alle 250 ms. Für „mit den neuen Dateien“ leitet eine Playwright-Route genau neun Abrufe um, die acht Projekt-PNG und das Video, auf einen Server auf meinem Rechner, der die neuen Dateien liefert. Ein direktes Ausliefern aus der Route hätte die Drosselung umgangen, deshalb laufen auch die neuen Dateien durch dieselbe gedrosselte Leitung. In den Läufen „heute“ ist dieselbe Route gesetzt und reicht die Abrufe unverändert durch.

Lauf	Uhrzeit	Fassung	Ablauf	übertragen	LCP	CLS	Projektbilder fertig	Video spielbereit	load
7	13:23	neue Dateien	ohne Wischen (Probelauf, 45 s)	3,20 MB	2,36 s	0,0089	4,70 s	2,74 s	2,81 s
8	13:36	heute	Wischen nach 5 s	7,59 MB	2,31 s	0,0089	6,91 s	6,70 s	6,90 s
9	13:45	neue Dateien	Wischen nach 5 s	3,24 MB	2,30 s	0,0089	4,66 s	2,79 s	2,86 s
10	13:45	heute	Wischen nach 5 s	7,60 MB	2,29 s	0,0089	6,85 s	6,62 s	6,84 s

Der Filmstreifen oben zeigt je Fassung einen Lauf mit Wischen, Lauf 9 und 10 dieser Tabelle, gestartet im Abstand von 42 Sekunden. Lauf 7 war ein Probelauf ohne Wischen, deshalb gibt es von ihm keinen Filmstreifen. In beiden Läufen mit den neuen Dateien kam die Projektliste später vom Server: admin-ajax brauchte 1,9 bis 2,0 Sekunden statt 0,5. Für die Projektbilder mit den neuen Dateien ist das ein Nachteil. Das Video hatte dadurch dort die Leitung für sich; kämen Bilder und Video gleichzeitig, wäre es etwas später spielbereit.

Wischen heißt: echte Touch-Ereignisse an einer Stelle ohne Link, dann ein Sprung zum Projekt-Karussell, angekommen nach 5,81 Sekunden. Die Bildschirmfotos von Lauf 9 und 10 sind bei 2,0 Sekunden Byte für Byte gleich, bei 4,5 Sekunden liegt der SSIM bei 0,997. Das load-Ereignis kam heute erst nach 6,8 bis 6,9 Sekunden: Die Projektliste traf vor dem load-Ereignis ein, und es wartete auf die 3,4 MB PNG. In den Läufen mit den neuen Dateien kam die Liste erst danach. Deshalb steht load hier nur zur Vollständigkeit.

Video heute: drei Teilabrufe (Anfang, Ende mit dem Inhaltsverzeichnis, Rest), erstes Bild nach 3,42 bzw. 3,45 Sekunden, ohne Stocken abspielbar nach 6,62 bzw. 6,70 Sekunden, ganz übertragen nach 8,31 bzw. 8,34 Sekunden, 2,13 und 2,14 MB. Mit den neuen Dateien: ein Abruf, erstes Bild und ohne Stocken abspielbar beides nach 2,74 bzw. 2,79 Sekunden, ganz übertragen nach 3,52 bzw. 3,54 Sekunden, 0,82 MB.

Zwei weitere Aufrufe um 13:25 und 13:38 Uhr brachen wegen eines Fehlers in meinem Messskript ab und sind nicht ausgewertet.

Kurve als Tabelle übertragene MB je Sekunde

Zeit	Heute, Lauf 1	Heute, Lauf 2	Neue Dateien, Lauf 1	Neue Dateien, Lauf 2 (ohne Wischen)
0 s	0,00	0,00	0,00	0,00
1 s	0,47	0,47	0,47	0,47
2 s	1,33	1,29	1,36	1,31
3 s	2,22	2,28	2,30	2,31
4 s	3,23	3,27	2,84	2,84
5 s	4,24	4,29	3,20	3,20
6 s	5,25	5,29	3,24	3,20
7 s	6,24	6,29	3,24	3,20
8 s	7,25	7,28	3,24	3,20
9 s	7,59	7,60	3,24	3,20
10 s	7,59	7,60	3,24	3,20

Die acht Projektbilder einzeln PNG und WebP in gleicher Pixelgröße

Alle acht: 960 × 960 Pixel mit Transparenzkanal, angezeigt am Handy in 430 × 430 CSS-Pixeln. Neu kodiert als WebP mit Qualität 80, Transparenz bleibt erhalten. Ein großer Teil jedes Bildes ist transparent und in beiden Fassungen gleich, deshalb steht hier der Vergleich nur über das sichtbare Motiv (SSIM, 8 × 8-Fenster, nur deckende Flächen). Über das ganze Bild gerechnet, über Weiß gelegt, sind es 0,981 bis 0,990.

Datei	PNG heute	als WebP	SSIM Motiv
`miccados.png`	303 kB	46 kB	0,970
`getriebeservice-ch.png`	356 kB	36 kB	0,980
`vitalstoffmessung-….png`	364 kB	31 kB	0,976
`jobtour-technical.png`	401 kB	49 kB	0,973
`restaurant-beckers.png`	418 kB	50 kB	0,959
`ats-getriebe-com.png`	444 kB	42 kB	0,962
`zle-ehrlich.png`	508 kB	41 kB	0,954
`vetrihof-de.png`	608 kB	63 kB	0,971
Zusammen	3,40 MB	0,36 MB	0,954–0,980

Schon als WebP kommen sieben andere Bilder, zum Beispiel die Blogbilder (post_…-650x560.jpg.webp).

Video und doppeltes Foto Probeschnitt, Prüfsumme

Video 1904841_Computer_Code_1920x1080.mp4: H.264, 1920 × 1080, 29,97 Bilder je Sekunde, 12,45 Sekunden, 2.106.185 Byte. Am Handy angezeigt in 372 × 330 CSS-Pixeln, autoplay, kein poster, Elementor-Einstellung background_play_on_mobile: yes.
Probeschnitt 1280 × 720 (CRF 28): 823.011 Byte, SSIM 0,986 zum Original über den ganzen Clip. 960 × 540: 560.462 Byte. Standbild aus dem ersten Bild für das Paket: 17.084 Byte (WebP, Qualität 80).
konfi.jpg und konfi-1.jpg (Oktober 2024): gleiche SHA-1-Prüfsumme d554e46a816b…, je 179.868 Byte. konfi-1.jpg ist Hintergrund eines Banners, konfi.jpg ein Bild weiter unten. Beide geladen in den Läufen 3 bis 6.

CSS und JavaScript 92 + 68 Dateien, WP Rocket

Bis zum load-Ereignis 92 CSS- und 68 JavaScript-Abrufe, gleich in den Läufen 3 bis 6.
In der HTML, die das Handy bekommt: ein Block kritisches CSS (rocket-critical-css), 93 CSS-Einbindungen asynchron per rel="preload" mit data-rocket-async. Hintergrundbilder über den Lazyload von WP Rocket.
67 Skripte mit src, davon 2 mit defer oder async.
CSS-Abdeckung: 2,1 Mio. Zeichen CSS (entpackt, inklusive Inline-CSS), davon beim Aufruf am Handy 13,3 % genutzt.

Barrierefreiheit im Detail axe-core 4.14.0

Regel	Lauf 1–2	Lauf 3–6	Lauf 7–10	Wo
`link-name`	8	8	8–10	Social-Icons Instagram, Facebook, Twitter, Pinterest, Xing, LinkedIn; Menü-Knopf im mitlaufenden Kopf; Kontakt-Symbol
`label-content-name-mismatch`	4	4	4	„Weiterlesen »“ der vier Blog-Teaser, `aria-label="Mehr über …"`
`color-contrast`	10	31	10	laut axe-core u. a. #bc3737 auf #2e4e5e (1,57 : 1), #717171 auf #2e4e5e (1,81 : 1), Datum #adadad (3,95 : 1), Name in den Kundenstimmen #b5b5b5 (4,32 : 1)

Lauf 1 und 2 ohne Scrollen, Lauf 3 bis 6 nach dem Durchscrollen, Lauf 8 bis 10 nach dem Wischen zu den Projekten, Lauf 7 ohne Wischen (dort 8, sonst 10 fehlende Linknamen, unter anderem zeigt der aktive mitlaufende Kopf den Menü-Knopf ein zweites Mal). Geprüft nach den Regelsätzen wcag2a, wcag2aa, wcag21a, wcag21aa und wcag22aa. axe-core schneidet nach der zweiten Stelle ab, nach der WCAG-Formel gerundet sind es 1,58 und 1,82.

Zusätzlich in Lauf 7 bis 10 mit dem Regelsatz best-practice, gemeldet in allen vier:

Regel	Anzahl	Was
`page-has-heading-one`	1	keine sichtbare H1; die einzige H1 trägt in Elementor alle sieben Klassen `elementor-hidden-…`
`landmark-one-main`	1	kein Hauptbereich; der Inhalt steckt in `<div id="main">`, ein `<main>` fehlt
`region`	11–18	Inhalt außerhalb von Bereichen, folgt aus dem fehlenden Hauptbereich
`heading-order`	47	Überschriften überspringen Ebenen, zum Beispiel H5 für die Namen in den Kundenstimmen
`aria-allowed-role`	4–5	unter anderem `role="presentation"` am Hintergrundvideo

Zeiten, und warum sie nicht oben stehen hängen stark vom Netz ab

Profil	erster Inhalt	größtes Element	load
ohne Drosselung (Lauf 5 / 6)	0,94 / 1,50 s	1,85 / 2,43 s	6,57 / 5,78 s
gedrosselt (Lauf 1–4)	3,7 bis 5,3 s	7,5 bis 10,7 s	26,6 bis 28,9 s
Fast 4G (Lauf 7–10)	1,16 bis 1,36 s	2,29 bis 2,36 s	heute 6,84 / 6,90 s, mit den neuen Dateien 2,81 / 2,86 s*

* Nicht vergleichbar: In den Läufen mit den neuen Dateien kam die Projektliste erst nach load, heute davor.

Auf schneller Leitung steht das große Bild nach rund zwei Sekunden, mit dem Profil Fast 4G nach 2,3 Sekunden, das ist gut. Die gedrosselten Werte zeigen, wie stark die Seite von Netz und Gerät abhängt. Die Datenmenge war dagegen bei gleichem Ablauf nahezu gleich (ohne Scrollen 7,50 bis 7,53 MB), deshalb steht sie oben.

Kleinigkeiten für einen ruhigen Nachmittag

Vorgeladen wird visitenkarte3.jpg. Am Handy liegt es als blasses Overlay (Deckkraft 0,15) über dem Startbild, als größtes Element zählt der Browser in allen Läufen buero.jpg (Juni 2023). Ob beide früh laden sollen, wäre ein Test wert.
Die Schrift Montserrat kommt als TTF mit 166 kB, als WOFF2 sind es 124 kB.
Die acht Projektbilder tragen im Karussell alle denselben Alternativtext alt="Featured Image". Besser wäre jeweils der Projektname.
Im Quelltext stehen die Versionen von WordPress, WP Rocket und Site Kit. Das lässt sich ausblenden.
HSTS gilt 30 Tage (max-age=2592000).

Was schon richtig gut ist, im Detail SEO, Sicherheit, Auslieferung

SEO-Grundlagen: Titel „KI- und Digitalagentur Baden-Baden | E-SITE.com“, Beschreibung, Canonical, Open Graph, Schema LocalBusiness und WebSite, lang="de", Sitemap in der robots.txt.
Sicherheits-Kopfzeilen: HSTS mit Subdomains, X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Referrer-Policy und Permissions-Policy.
Auslieferung: alle Abrufe über HTTP/2, CSS und JavaScript komprimiert, CSS und fast alle Skripte ein Jahr im Browser-Cache, WP Rocket mit kritischem CSS.
Bilder: Jedes Bild-Element der Startseite hat ein alt-Attribut, sieben Bilder kommen schon als WebP.
Startbild: Mit Fast 4G steht das größte Element nach 2,29 bis 2,36 Sekunden, CLS 0,0089 in allen vier Läufen (Labormessung).