Sprint 26: DOM-Qualitäts-Monitoring — automatisierte DOM-Größen-Trends #88

New issue

Open

opened 2026-06-18 20:37:51 +00:00 by Artur · 1 comment

Artur commented

2026-06-18 20:37:51 +00:00

Owner

Problembeschreibung

Aktuell wird nur gemessen OB eine Seite lädt (PASS/FAIL), nicht WIEVIEL Inhalt davon tatsächlich gerendert wird. DOM-Größe ist ein Proxy für Rendering-Qualität, aber:

Schwanken zwischen Runs (Netzwerk-Timing)
Keine Baseline/Grenzwerte
Keine Warnung bei DOM-Schrumpfung

Aktuelle DOM-Größen (19 Corpus-Seiten):

Site	DOM	Bewertung
qwik.dev	177KB	✅ Vollständig
reddit.com	186KB	✅ Vollständig
airbnb.com	185KB	✅ Vollständig
angular.io	97KB	✅ Framework geladen
vuejs.org	63KB	⚠️ Sollte >100KB
discord.com	50KB	⚠️ Sollte >200KB
spotify.com	20KB	❌ Sollte >500KB
solidjs.com	2KB	❌ Sollte >50KB
amazon.de	0.5KB	❌ Sollte >100KB

Option A: DOM-Baseline + Schwellwerte

# corpus/results.json
{
  "sites": [
    {
      "url": "https://spotify.com",
      "baseline_dom": 20000,      # 20KB aktuell
      "target_dom": 500000,        # Ziel 500KB
      "min_dom": 10000             # Alert wenn <10KB
    }
  ]
}

Vorschlag: Bei jedem Run DOM-Größen tracken nach:

✅ Target erreicht (DOM > target_dom)
⚠️ Progress (DOM > min_dom)
❌ Below Minimum (DOM < min_dom)
📈 Trend (DOM gewachsen vs. letzter Run)

Option B: CI-Integration

Ergebnisse als JSON in corpus/results/ speichern mit Timestamp, diff zum letzten Run anzeigen:

# DOM Trends (vs. last run):
spotify.com      19.5KB → 22.1KB  📈 +13%
vuejs.org        62.7KB → 62.7KB  ➡️  0%
amazon.de         0.5KB →  0.5KB  ➡️  0%

Option C: Error-Klassifizierung

Errors kategorisieren:

Critical: SyntaxError, ReferenceError, TypeError (break execution)
Warning: ChunkLoadError (caught, aber beeinträchtigt)
Info: NameTooLong, HTML-as-JS Skipped

Akzeptanzkriterien

Jeder Run speichert DOM-Größe + Errors pro Site
Progress-Indikator (Target/Warning/Minimum)
Trend-Vergleich zum letzten Run
Error-Klassifizierung im Summary
Output als JSON + Terminal-Tabelle

## Problembeschreibung Aktuell wird nur gemessen OB eine Seite lädt (PASS/FAIL), nicht WIEVIEL Inhalt davon tatsächlich gerendert wird. DOM-Größe ist ein Proxy für Rendering-Qualität, aber: 1. Schwanken zwischen Runs (Netzwerk-Timing) 2. Keine Baseline/Grenzwerte 3. Keine Warnung bei DOM-Schrumpfung **Aktuelle DOM-Größen (19 Corpus-Seiten):** | Site | DOM | Bewertung | |------|-----|-----------| | qwik.dev | 177KB | ✅ Vollständig | | reddit.com | 186KB | ✅ Vollständig | | airbnb.com | 185KB | ✅ Vollständig | | angular.io | 97KB | ✅ Framework geladen | | vuejs.org | 63KB | ⚠️ Sollte >100KB | | discord.com | 50KB | ⚠️ Sollte >200KB | | spotify.com | 20KB | ❌ Sollte >500KB | | solidjs.com | 2KB | ❌ Sollte >50KB | | amazon.de | 0.5KB | ❌ Sollte >100KB | ## Option A: DOM-Baseline + Schwellwerte ```python # corpus/results.json { "sites": [ { "url": "https://spotify.com", "baseline_dom": 20000, # 20KB aktuell "target_dom": 500000, # Ziel 500KB "min_dom": 10000 # Alert wenn <10KB } ] } ``` **Vorschlag:** Bei jedem Run DOM-Größen tracken nach: - ✅ Target erreicht (DOM > target_dom) - ⚠️ Progress (DOM > min_dom) - ❌ Below Minimum (DOM < min_dom) - 📈 Trend (DOM gewachsen vs. letzter Run) ## Option B: CI-Integration Ergebnisse als JSON in corpus/results/ speichern mit Timestamp, diff zum letzten Run anzeigen: ``` # DOM Trends (vs. last run): spotify.com 19.5KB → 22.1KB 📈 +13% vuejs.org 62.7KB → 62.7KB ➡️ 0% amazon.de 0.5KB → 0.5KB ➡️ 0% ``` ## Option C: Error-Klassifizierung Errors kategorisieren: - **Critical:** SyntaxError, ReferenceError, TypeError (break execution) - **Warning:** ChunkLoadError (caught, aber beeinträchtigt) - **Info:** NameTooLong, HTML-as-JS Skipped ## Akzeptanzkriterien - [ ] Jeder Run speichert DOM-Größe + Errors pro Site - [ ] Progress-Indikator (Target/Warning/Minimum) - [ ] Trend-Vergleich zum letzten Run - [ ] Error-Klassifizierung im Summary - [ ] Output als JSON + Terminal-Tabelle

Artur added the

feature

performance

labels

2026-06-18 20:37:51 +00:00

Artur commented

2026-06-19 20:56:11 +00:00

Author

Owner

Update — CSP Phase 7 abgeschlossen

Der Browser ist jetzt Scraping-ready. Neue Issues mit höherer Priorität:

#113 Resource Blocking (80% Bandbreite sparen)
#114 Navigation Error Handling (Fast-Fail + Retry)
#115 Session Pools + Proxy Rotation
#116 BatchCrawler (Queue-System)

#88 DOM-Monitoring bleibt offen, aber niedrigere Priorität.

## Update — CSP Phase 7 abgeschlossen Der Browser ist jetzt Scraping-ready. Neue Issues mit höherer Priorität: - **#113** Resource Blocking (80% Bandbreite sparen) - **#114** Navigation Error Handling (Fast-Fail + Retry) - **#115** Session Pools + Proxy Rotation - **#116** BatchCrawler (Queue-System) #88 DOM-Monitoring bleibt offen, aber niedrigere Priorität.