Matthew Raymer
4 days ago
3 changed files with 0 additions and 1369 deletions
@ -1,881 +0,0 @@ |
|||
# Performance Analysis: 60-New-Activity Test |
|||
|
|||
**Date**: August 1, 2025 10:26:23 AM UTC |
|||
**Test File**: `test-playwright/60-new-activity.spec.ts` |
|||
**Analysis Type**: Performance Bottleneck Identification |
|||
|
|||
## Executive Summary |
|||
|
|||
The 60-new-activity test revealed significant performance bottlenecks, with the |
|||
`add-contact` action consuming 26.2% of total test time (4.21 seconds). Network |
|||
requests totaled 1,088 calls during the test run, indicating potential |
|||
optimization opportunities. |
|||
|
|||
**✅ MEASURED IMPROVEMENT**: After implementing batched feed updates with `nextTick()`, the test now completes in: |
|||
- **Chromium**: 23.7s (48% improvement from 45+ seconds) |
|||
- **Firefox**: 18.0s (60% improvement from 45+ seconds) |
|||
|
|||
**⚠️ PREDICTION**: The performance improvement is hypothesized to be due to reduced Vue reactivity triggers, but this has not been directly measured. |
|||
|
|||
## Key Performance Metrics |
|||
|
|||
| Metric | Value | Impact | |
|||
|--------|-------|--------| |
|||
| **Total Test Duration** | 16.05 seconds | Baseline | |
|||
| **Average Navigation Time** | 256ms | Acceptable | |
|||
| **Network Requests** | 1,088 | High | |
|||
| **Slowest Action** | add-contact (4.21s) | Critical | |
|||
|
|||
## Detailed Performance Breakdown |
|||
|
|||
### 🚨 Critical Performance Issues |
|||
|
|||
#### 1. **Add-Contact Action (4.21s, 26.2% of total time)** |
|||
|
|||
**Root Cause Analysis:** |
|||
|
|||
- Multiple network requests during contact validation |
|||
- Complex DID parsing and validation |
|||
- UI state management overhead |
|||
- Database operations |
|||
|
|||
**Specific Bottlenecks:** |
|||
|
|||
```typescript |
|||
// From ContactsView.vue - addContact method |
|||
private async addContact() { |
|||
// 1. DID parsing and validation (slow) |
|||
const did = this.parseDidFromInput(); |
|||
|
|||
// 2. Database insert operation |
|||
await this.$insertContact(did); |
|||
|
|||
// 3. Network request for visibility |
|||
await setVisibilityUtil(did, true); |
|||
|
|||
// 4. UI state updates and re-renders |
|||
this.updateContactList(); |
|||
} |
|||
``` |
|||
|
|||
**Network Requests During Add-Contact:** |
|||
|
|||
- `POST /api/report/canSeeMe` - 150ms |
|||
- `POST /api/report/cannotSeeMe` - 120ms |
|||
- Database operations - 200ms |
|||
- UI rendering - 300ms |
|||
|
|||
#### 2. **Switch-User Action (3.06s, 19.0% of total time)** |
|||
|
|||
**Root Cause Analysis:** |
|||
|
|||
- Authentication state management |
|||
- Database queries for user data |
|||
- UI component re-initialization |
|||
- Network requests for user validation |
|||
|
|||
#### 3. **Import-User-Account Action (1.85s, 11.5% of total time)** |
|||
|
|||
**Root Cause Analysis:** |
|||
|
|||
- File system operations |
|||
- DID validation and parsing |
|||
- Database import operations |
|||
- UI state synchronization |
|||
|
|||
## Network Request Analysis |
|||
|
|||
### 🔍 **Where the 1,088 Requests Come From** |
|||
|
|||
The performance collector tracks **ALL** network responses, not just API calls. Here's the breakdown: |
|||
|
|||
| Request Category | Count | Percentage | Impact | |
|||
|------------------|-------|------------|--------| |
|||
| **Network Responses** | 887 | 81.5% | High frequency, low impact | |
|||
| **Database Operations** | 312 | 28.6% | Medium frequency, medium impact | |
|||
| **API Calls** | 70 | 6.4% | Low frequency, **HIGH IMPACT** | |
|||
| **Development Tools** | 68 | 6.2% | Development only | |
|||
| **Static Assets** | 32 | 2.9% | Cached after first load | |
|||
| **External Resources** | 7 | 0.6% | Third-party dependencies | |
|||
|
|||
**⚠️ Note**: The "UI Updates (Vue Reactivity)" categorization is an estimation, not a measured metric. The performance collector does not track Vue-specific reactivity triggers. |
|||
|
|||
### 🎯 **Detailed Breakdown** |
|||
|
|||
#### **API Calls (The ones we care about)** |
|||
- **`/api/report/canSeeMe`** - 25 calls (35.7% of API calls) |
|||
- **`/api/report/cannotSeeMe`** - 20 calls (28.6% of API calls) |
|||
- **`/api/contacts`** - 15 calls (21.4% of API calls) |
|||
- **`/api/users`** - 10 calls (14.3% of API calls) |
|||
|
|||
#### **Database Operations** |
|||
- **`indexeddb://contacts`** - 156 operations (50.0% of DB calls) |
|||
- **`indexeddb://users`** - 89 operations (28.5% of DB calls) |
|||
- **`indexeddb://offers`** - 67 operations (21.5% of DB calls) |
|||
|
|||
#### **UI Updates (Vue Reactivity)** |
|||
- **`vue://component-update`** - 887 updates (100% of UI calls) |
|||
|
|||
### 🚨 **Key Insights** |
|||
|
|||
1. **UI reactivity is the biggest culprit** - 887 Vue component updates |
|||
2. **Database operations are frequent** - 312 IndexedDB operations |
|||
3. **API calls are low frequency but high impact** - Only 70 calls but cause major delays |
|||
4. **Development tools add noise** - 68 requests from hot reload, etc. |
|||
|
|||
## Vue Reactivity Analysis |
|||
|
|||
### 🔍 **Components Involved in the Test** |
|||
|
|||
Based on the test flow, these components are responsible for the 887 UI updates: |
|||
|
|||
#### **Primary Components (High Reactivity)** |
|||
|
|||
1. **`HomeView.vue`** - Main container component |
|||
- **Reactive Properties**: `feedData`, `activeDid`, `isFeedLoading`, `numNewOffersToUser` |
|||
- **Update Triggers**: Feed loading, user switching, offer creation |
|||
- **Estimated Updates**: ~300 updates during test |
|||
|
|||
2. **`ActivityListItem.vue`** - Individual activity display |
|||
- **Reactive Properties**: `record`, `lastViewedClaimId`, `activeDid` |
|||
- **Update Triggers**: Record changes, user switching, offer status updates |
|||
- **Estimated Updates**: ~200 updates (multiple items in feed) |
|||
|
|||
3. **`ContactsView.vue`** - Contact management interface |
|||
- **Reactive Properties**: `contacts`, `contactInput`, `contactsSelected`, `givenByMeDescriptions` |
|||
- **Update Triggers**: Contact addition, selection changes, give amounts |
|||
- **Estimated Updates**: ~150 updates during contact operations |
|||
|
|||
#### **Secondary Components (Medium Reactivity)** |
|||
|
|||
4. **`ContactListItem.vue`** - Individual contact display |
|||
- **Reactive Properties**: `contact`, `isSelected`, `showActions`, `givenAmounts` |
|||
- **Update Triggers**: Selection changes, give amount updates |
|||
- **Estimated Updates**: ~100 updates |
|||
|
|||
5. **`ContactInputForm.vue`** - Contact input interface |
|||
- **Reactive Properties**: `modelValue`, `isRegistered`, `inputValidation` |
|||
- **Update Triggers**: Input changes, validation updates |
|||
- **Estimated Updates**: ~50 updates |
|||
|
|||
6. **`OfferDialog.vue`** - Offer creation dialog |
|||
- **Reactive Properties**: `isOpen`, `offerData`, `validationState` |
|||
- **Update Triggers**: Dialog state, form validation |
|||
- **Estimated Updates**: ~50 updates |
|||
|
|||
#### **Utility Components (Low Reactivity)** |
|||
|
|||
7. **`QuickNav.vue`** - Navigation component |
|||
8. **`TopMessage.vue`** - Message display |
|||
9. **`OnboardingDialog.vue`** - Onboarding flow |
|||
10. **`GiftedDialog.vue`** - Gift creation interface |
|||
|
|||
### 🎯 **Specific Reactivity Issues Identified** |
|||
|
|||
#### **1. HomeView.vue - Feed Data Reactivity** |
|||
|
|||
```typescript |
|||
// Current: Highly reactive feed data with individual push operations |
|||
for (const record of records) { |
|||
const processedRecord = await this.processRecord(record); |
|||
if (processedRecord) { |
|||
this.feedData.push(processedRecord); // Triggers reactivity for each push |
|||
} |
|||
} |
|||
|
|||
// Optimized: Batched updates with nextTick |
|||
const processedRecords: GiveRecordWithContactInfo[] = []; |
|||
for (const record of records) { |
|||
const processedRecord = await this.processRecord(record); |
|||
if (processedRecord) { |
|||
processedRecords.push(processedRecord); |
|||
} |
|||
} |
|||
// Single reactivity trigger for all records |
|||
await nextTick(() => { |
|||
this.feedData.push(...processedRecords); |
|||
}); |
|||
``` |
|||
|
|||
#### **2. ActivityListItem.vue - Record Reactivity** |
|||
|
|||
```typescript |
|||
// Current: Deep reactive record object |
|||
@Prop() record!: GiveRecordWithContactInfo; |
|||
|
|||
// Problem: Any change to record triggers component re-render |
|||
// Solution: Use computed properties for derived data |
|||
get displayName() { |
|||
return this.record.issuer.displayName; |
|||
} |
|||
``` |
|||
|
|||
#### **3. ContactsView.vue - Contact List Reactivity** |
|||
|
|||
```typescript |
|||
// Current: Reactive contact arrays and objects |
|||
contacts: Array<Contact> = []; |
|||
givenByMeDescriptions: Record<string, string> = {}; |
|||
|
|||
// Problem: Contact updates trigger cascading re-renders |
|||
// Solution: Use shallowRef and computed properties |
|||
contacts = shallowRef<Array<Contact>>([]); |
|||
``` |
|||
|
|||
#### **4. ContactListItem.vue - Selection Reactivity** |
|||
|
|||
```typescript |
|||
// Current: Reactive selection state |
|||
:is-selected="contactsSelected.includes(contact.did)" |
|||
|
|||
// Problem: Array operations trigger re-renders |
|||
// Solution: Use Set for efficient lookups |
|||
const selectedSet = computed(() => new Set(contactsSelected.value)); |
|||
``` |
|||
|
|||
### 🚀 **Vue Reactivity Optimization Strategies** |
|||
|
|||
#### **1. Use `shallowRef` for Large Objects** |
|||
|
|||
```typescript |
|||
// Before: Deep reactive objects |
|||
const feedData = ref<GiveRecordWithContactInfo[]>([]); |
|||
|
|||
// After: Shallow reactive arrays |
|||
const feedData = shallowRef<GiveRecordWithContactInfo[]>([]); |
|||
``` |
|||
|
|||
#### **2. Implement `v-memo` for Expensive Components** |
|||
|
|||
```vue |
|||
<!-- Before: Always re-renders --> |
|||
<ActivityListItem |
|||
v-for="record in feedData" |
|||
:key="record.jwtId" |
|||
:record="record" |
|||
/> |
|||
|
|||
<!-- After: Memoized re-renders --> |
|||
<ActivityListItem |
|||
v-for="record in feedData" |
|||
:key="record.jwtId" |
|||
v-memo="[record.jwtId, record.issuerDid, record.recipientDid]" |
|||
:record="record" |
|||
/> |
|||
``` |
|||
|
|||
#### **3. Use Computed Properties Efficiently** |
|||
|
|||
```typescript |
|||
// Before: Inline computed values |
|||
const displayName = record.issuer.displayName; |
|||
|
|||
// After: Cached computed properties |
|||
const displayName = computed(() => record.issuer.displayName); |
|||
``` |
|||
|
|||
#### **4. Batch DOM Updates with `nextTick`** |
|||
|
|||
```typescript |
|||
// Before: Multiple synchronous updates |
|||
this.feedData.push(newRecord); |
|||
this.isFeedLoading = false; |
|||
this.numNewOffersToUser++; |
|||
|
|||
// After: Batched updates |
|||
await nextTick(() => { |
|||
this.feedData.push(newRecord); |
|||
this.isFeedLoading = false; |
|||
this.numNewOffersToUser++; |
|||
}); |
|||
``` |
|||
|
|||
#### **5. Use `v-once` for Static Content** |
|||
|
|||
```vue |
|||
<!-- Before: Always reactive --> |
|||
<h1>{{ AppString.APP_NAME }}</h1> |
|||
|
|||
<!-- After: Static content --> |
|||
<h1 v-once>{{ AppString.APP_NAME }}</h1> |
|||
``` |
|||
|
|||
## ✅ **Implemented Optimization** |
|||
|
|||
### **HomeView.vue Feed Data Batching** |
|||
|
|||
**Problem**: The `processFeedResults` method was triggering Vue reactivity for each individual record push: |
|||
|
|||
```typescript |
|||
// Before: Individual reactivity triggers |
|||
for (const record of records) { |
|||
const processedRecord = await this.processRecord(record); |
|||
if (processedRecord) { |
|||
this.feedData.push(processedRecord); // Triggers reactivity for each push |
|||
} |
|||
} |
|||
``` |
|||
|
|||
**Solution**: Batched updates using `nextTick()` to reduce reactivity triggers: |
|||
|
|||
```typescript |
|||
// After: Single reactivity trigger |
|||
const processedRecords: GiveRecordWithContactInfo[] = []; |
|||
for (const record of records) { |
|||
const processedRecord = await this.processRecord(record); |
|||
if (processedRecord) { |
|||
processedRecords.push(processedRecord); |
|||
} |
|||
} |
|||
// Single reactivity trigger for all records |
|||
await nextTick(() => { |
|||
this.feedData.push(...processedRecords); |
|||
}); |
|||
``` |
|||
|
|||
**Impact**: |
|||
|
|||
- **✅ Measured**: Test completion time improved by 48-60% (23.7s vs 45+ seconds) |
|||
- **✅ Measured**: Eliminated timeout issues in both Chromium and Firefox |
|||
- **❌ Predicted**: Reduced Vue reactivity triggers from individual `push()` operations to batched updates |
|||
- **⚠️ Note**: Vue reactivity metrics not captured by current performance collector |
|||
|
|||
## 🔍 **Measurement Gaps & Next Steps** |
|||
|
|||
### **What We Actually Measured vs. What We Predicted** |
|||
|
|||
#### **✅ Measured Data (Real Evidence)** |
|||
|
|||
1. **Test Duration Improvement**: |
|||
- Before: 45+ seconds (timeout) |
|||
- After: 23.7s (Chromium), 18.0s (Firefox) |
|||
- **Source**: Playwright test execution times |
|||
|
|||
2. **Timeout Elimination**: |
|||
- Before: Tests consistently timed out |
|||
- After: Tests complete successfully |
|||
- **Source**: Test execution logs |
|||
|
|||
3. **Network Request Counts**: |
|||
- Total: 1,088 network responses |
|||
- **Source**: Performance collector network tracking |
|||
|
|||
#### **❌ Predicted Data (Hypotheses)** |
|||
|
|||
1. **Vue Reactivity Reduction**: |
|||
- Claim: "887 individual updates reduced to 1 batch update" |
|||
- **Status**: Estimation based on code analysis, not measured |
|||
- **Source**: Code review of `nextTick()` implementation |
|||
|
|||
2. **Component Re-render Reduction**: |
|||
- Claim: Reduced component updates in ActivityListItem |
|||
- **Status**: Predicted, not measured |
|||
- **Source**: Vue reactivity theory |
|||
|
|||
#### **What We Need to Measure** |
|||
|
|||
To confirm the Vue reactivity impact, we need to add specific metrics to the performance collector: |
|||
|
|||
#### **1. Vue Reactivity Metrics** |
|||
```typescript |
|||
// Add to PerformanceCollector |
|||
private vueMetrics = { |
|||
componentUpdates: 0, |
|||
reactivityTriggers: 0, |
|||
watcherExecutions: 0, |
|||
computedPropertyRecomputations: 0 |
|||
}; |
|||
``` |
|||
|
|||
**Implementation Strategy**: |
|||
- Inject Vue DevTools hooks into the page |
|||
- Track `beforeUpdate` and `updated` lifecycle hooks |
|||
- Monitor `watch` and `computed` property executions |
|||
- Count reactive property changes |
|||
|
|||
#### **2. DOM Mutation Tracking** |
|||
```typescript |
|||
// Track actual DOM changes |
|||
private domMetrics = { |
|||
nodeInsertions: 0, |
|||
nodeRemovals: 0, |
|||
attributeChanges: 0, |
|||
textContentChanges: 0 |
|||
}; |
|||
``` |
|||
|
|||
**Implementation Strategy**: |
|||
- Use `MutationObserver` to track DOM changes |
|||
- Filter for Vue-specific mutations |
|||
- Correlate with component lifecycle events |
|||
|
|||
#### **3. Memory Usage Patterns** |
|||
```typescript |
|||
// Enhanced memory tracking |
|||
private memoryMetrics = { |
|||
heapUsage: 0, |
|||
componentInstances: 0, |
|||
reactiveObjects: 0, |
|||
watcherCount: 0 |
|||
}; |
|||
``` |
|||
|
|||
**Implementation Strategy**: |
|||
- Track Vue component instance count |
|||
- Monitor reactive object creation |
|||
- Measure watcher cleanup efficiency |
|||
|
|||
## 🎯 **Conclusion: What We Know vs. What We Need to Investigate** |
|||
|
|||
### **What We Know (Measured Evidence)** |
|||
|
|||
1. **✅ Performance Improvement is Real**: The test went from timing out (45+ seconds) to completing in 18-24 seconds |
|||
2. **✅ The Fix Works**: The `nextTick()` batching implementation resolved the timeout issues |
|||
3. **✅ Cross-Browser Compatibility**: Improvements work in both Chromium and Firefox |
|||
|
|||
### **What We Need to Investigate (Unanswered Questions)** |
|||
|
|||
1. **❓ Root Cause**: Is the improvement due to: |
|||
- Reduced Vue reactivity triggers (our hypothesis) |
|||
- Reduced network requests (we need to measure) |
|||
- Better error handling (the app no longer crashes) |
|||
- Other factors we haven't identified |
|||
|
|||
2. **❓ Vue Reactivity Impact**: We need to implement Vue-specific metrics to |
|||
confirm our hypothesis |
|||
|
|||
3. **❓ Network Request Analysis**: We need to categorize the 1,088 network |
|||
responses to understand their impact |
|||
|
|||
### **Next Steps for Validation** |
|||
|
|||
1. **Enhance Performance Collector**: Add Vue reactivity and DOM mutation tracking |
|||
2. **Run Comparative Tests**: Test before/after with enhanced metrics |
|||
3. **Network Analysis**: Categorize and analyze network request patterns |
|||
4. **Memory Profiling**: Track memory usage patterns during test execution |
|||
|
|||
### **Key Takeaway** |
|||
|
|||
While we have **strong evidence** that the `nextTick()` batching improved |
|||
performance, we need **enhanced measurement tools** to understand the root cause. |
|||
The current performance collector provides excellent timing data but lacks |
|||
Vue-specific metrics needed to validate our reactivity hypothesis. |
|||
|
|||
// Track Vue component updates |
|||
page.on('console', msg => { |
|||
if (msg.text().includes('Vue update')) { |
|||
this.vueMetrics.componentUpdates++; |
|||
} |
|||
}); |
|||
``` |
|||
|
|||
#### **2. DOM Mutation Metrics** |
|||
```typescript |
|||
// Track DOM changes |
|||
const observer = new MutationObserver(mutations => { |
|||
this.metrics.domMutations = mutations.length; |
|||
}); |
|||
observer.observe(document.body, { |
|||
childList: true, |
|||
subtree: true |
|||
}); |
|||
``` |
|||
|
|||
#### **3. Memory Usage Metrics** |
|||
|
|||
```typescript |
|||
// Track memory usage |
|||
const memoryInfo = performance.memory; |
|||
this.metrics.memoryUsage = { |
|||
usedJSHeapSize: memoryInfo.usedJSHeapSize, |
|||
totalJSHeapSize: memoryInfo.totalJSHeapSize |
|||
}; |
|||
``` |
|||
|
|||
### **Current Evidence vs. Predictions** |
|||
|
|||
| Metric | Status | Evidence | |
|||
|--------|--------|----------| |
|||
| **Test Duration** | ✅ **Measured** | 23.7s vs 45+ seconds | |
|||
| **Timeout Elimination** | ✅ **Measured** | No more timeouts | |
|||
| **Vue Reactivity** | ❌ **Predicted** | Code analysis only | |
|||
| **Network Requests** | ❌ **Predicted** | Estimated breakdown | |
|||
|
|||
## Optimization Recommendations |
|||
|
|||
### 🔧 Immediate Optimizations |
|||
|
|||
#### 1. **Vue Reactivity Optimization** (Biggest Impact) |
|||
|
|||
**Problem**: 887 UI component updates causing excessive re-renders |
|||
**Solution**: Optimize Vue reactivity patterns |
|||
|
|||
```typescript |
|||
// Current: Reactive objects causing cascading updates |
|||
const contact = reactive({ |
|||
name: '', |
|||
did: '', |
|||
visibility: false |
|||
}); |
|||
|
|||
// Optimized: Use shallowRef for large objects |
|||
const contact = shallowRef({ |
|||
name: '', |
|||
did: '', |
|||
visibility: false |
|||
}); |
|||
|
|||
// Use computed properties efficiently |
|||
const visibleContacts = computed(() => |
|||
contacts.value.filter(c => c.visibility) |
|||
); |
|||
``` |
|||
|
|||
#### 2. **Database Operations Batching** (Medium Impact) |
|||
|
|||
**Problem**: 312 individual IndexedDB operations |
|||
**Solution**: Batch database operations |
|||
|
|||
```typescript |
|||
// Current: Individual operations |
|||
await db.contacts.add(contact); |
|||
await db.users.update(user); |
|||
await db.offers.add(offer); |
|||
|
|||
// Optimized: Batch operations |
|||
await db.transaction('rw', [db.contacts, db.users, db.offers], async () => { |
|||
await db.contacts.add(contact); |
|||
await db.users.update(user); |
|||
await db.offers.add(offer); |
|||
}); |
|||
``` |
|||
|
|||
#### 3. **API Call Optimization** (High Impact, Low Frequency) |
|||
|
|||
**Problem**: 70 API calls with high latency |
|||
**Solution**: Batch and cache API calls |
|||
|
|||
```typescript |
|||
// Current: Sequential API calls |
|||
await setVisibilityUtil(did, true); |
|||
await setVisibilityUtil(did, false); |
|||
|
|||
// Optimized: Batch API calls |
|||
await Promise.all([ |
|||
setVisibilityUtil(did, true), |
|||
setVisibilityUtil(did, false) |
|||
]); |
|||
|
|||
// Add API response caching |
|||
const apiCache = new Map(); |
|||
const cachedApiCall = async (url, options) => { |
|||
const key = `${url}-${JSON.stringify(options)}`; |
|||
if (apiCache.has(key)) return apiCache.get(key); |
|||
const result = await fetch(url, options); |
|||
apiCache.set(key, result); |
|||
return result; |
|||
}; |
|||
``` |
|||
|
|||
### 🚀 Advanced Optimizations |
|||
|
|||
#### 1. **Network Request Optimization** |
|||
|
|||
- **Implement request batching** for API calls |
|||
- **Add request caching** for repeated calls |
|||
- **Use WebSocket connections** for real-time updates |
|||
- **Implement request deduplication** |
|||
|
|||
#### 2. **UI Performance** |
|||
|
|||
- **Virtual scrolling** for large contact lists |
|||
- **Component lazy loading** for non-critical UI elements |
|||
- **Debounce user input** to reduce unnecessary operations |
|||
- **Optimize re-render cycles** with proper Vue reactivity |
|||
|
|||
#### 3. **Database Optimization** |
|||
|
|||
- **Index optimization** for frequently queried fields |
|||
- **Query optimization** to reduce database load |
|||
- **Connection pooling** for better resource management |
|||
- **Caching layer** for frequently accessed data |
|||
|
|||
## Test-Specific Improvements |
|||
|
|||
### Current Test Structure Issues |
|||
|
|||
1. **Sequential Operations**: Test performs operations one after another |
|||
2. **No Cleanup**: Previous test state may affect performance |
|||
3. **Synchronous Waits**: Using `waitForTimeout` instead of proper async waits |
|||
|
|||
### Recommended Test Optimizations |
|||
|
|||
```typescript |
|||
// Before: Sequential operations |
|||
await perfCollector.measureUserAction('add-contact', async () => { |
|||
await page.getByTestId('contactInput').fill(did); |
|||
await page.getByTestId('addContactButton').click(); |
|||
await expect(page.getByText('Contact added successfully')).toBeVisible(); |
|||
}); |
|||
|
|||
// After: Parallel operations where possible |
|||
await perfCollector.measureUserAction('add-contact', async () => { |
|||
const [input, button] = await Promise.all([ |
|||
page.getByTestId('contactInput'), |
|||
page.getByTestId('addContactButton') |
|||
]); |
|||
await input.fill(did); |
|||
await button.click(); |
|||
await expect(page.getByText('Contact added successfully')).toBeVisible(); |
|||
}); |
|||
``` |
|||
|
|||
## Monitoring and Metrics |
|||
|
|||
### Key Performance Indicators (KPIs) |
|||
|
|||
1. **Add-Contact Duration**: Target < 2 seconds |
|||
2. **Switch-User Duration**: Target < 1.5 seconds |
|||
3. **Network Request Count**: Target < 500 requests |
|||
4. **UI Rendering Time**: Target < 100ms per operation |
|||
|
|||
### Performance Monitoring Setup |
|||
|
|||
```typescript |
|||
// Add performance monitoring to test |
|||
const performanceMetrics = { |
|||
addContactTime: 0, |
|||
switchUserTime: 0, |
|||
networkRequests: 0, |
|||
uiRenderTime: 0 |
|||
}; |
|||
|
|||
// Monitor network requests |
|||
page.on('request', () => performanceMetrics.networkRequests++); |
|||
``` |
|||
|
|||
## Browser-Specific Considerations |
|||
|
|||
### Firefox Performance Issues |
|||
|
|||
- **NetworkIdle Detection**: Firefox handles `waitForLoadState('networkidle')` differently |
|||
- **Solution**: Use `waitForSelector()` instead for more reliable cross-browser behavior |
|||
|
|||
### Chromium Performance Issues |
|||
|
|||
- **Memory Usage**: Higher memory consumption during test runs |
|||
- **Solution**: Implement proper cleanup and garbage collection |
|||
|
|||
## Conclusion |
|||
|
|||
The 60-new-activity test revealed significant performance bottlenecks, primarily |
|||
in the `add-contact` action. The main issues are: |
|||
|
|||
1. **Multiple sequential network requests** during contact addition |
|||
2. **Inefficient UI state management** causing unnecessary re-renders |
|||
3. **Lack of request batching** for API calls |
|||
4. **Database operation inefficiencies** |
|||
|
|||
**Priority Actions:** |
|||
|
|||
1. Implement request batching for visibility API calls |
|||
2. Optimize database operations with transactions |
|||
3. Add component caching for user switching |
|||
4. Implement proper cleanup in tests |
|||
|
|||
**Expected Impact:** |
|||
|
|||
- 40-50% reduction in add-contact time |
|||
- 30% reduction in total test duration |
|||
- 60% reduction in network request count |
|||
|
|||
--- |
|||
|
|||
## TODO Items |
|||
|
|||
### 🔥 High Priority |
|||
|
|||
#### Vue Reactivity Optimization (Biggest Impact) |
|||
|
|||
- [x] **Optimize HomeView.vue** to reduce ~300 feed updates ✅ **COMPLETED** |
|||
- [x] Replace individual `push()` operations with batched updates |
|||
- [x] Use `nextTick()` for batched feed updates |
|||
- [x] Implement single reactivity trigger for all records |
|||
- [x] **Result**: 48-60% performance improvement, eliminated timeouts |
|||
|
|||
- [ ] **Optimize ActivityListItem.vue** to reduce ~200 record updates |
|||
- [ ] Use computed properties for record-derived data |
|||
- [ ] Add `v-once` for static content (app name, icons) |
|||
- [ ] Implement `shallowRef` for large record objects |
|||
- [ ] Add memoization for expensive computed values |
|||
|
|||
- [ ] **Optimize ContactsView.vue** to reduce ~150 contact updates |
|||
- [ ] Replace contact arrays with `shallowRef()` |
|||
- [ ] Use Set for efficient selection lookups |
|||
- [ ] Implement computed properties for contact filtering |
|||
- [ ] Add `v-memo` to ContactListItem components |
|||
|
|||
- [ ] **Optimize ContactListItem.vue** to reduce ~100 selection updates |
|||
- [ ] Use computed properties for selection state |
|||
- [ ] Implement efficient give amount calculations |
|||
- [ ] Add memoization for contact display data |
|||
- [ ] Use `shallowRef` for contact objects |
|||
|
|||
- [ ] **Optimize database operations** to reduce 312 IndexedDB calls |
|||
- [ ] Implement database transaction batching |
|||
- [ ] Add database operation queuing |
|||
- [ ] Cache frequently accessed data |
|||
- [ ] Use bulk operations for multiple records |
|||
|
|||
- [ ] **Optimize API calls** to reduce 70 high-impact requests |
|||
- [ ] Implement API response caching |
|||
- [ ] Batch visibility API calls (`canSeeMe`/`cannotSeeMe`) |
|||
- [ ] Add request deduplication for identical calls |
|||
- [ ] Implement API call debouncing |
|||
|
|||
#### Next Priority: ActivityListItem.vue Optimization |
|||
|
|||
- [ ] **Optimize ActivityListItem.vue** to reduce ~200 record updates |
|||
- [ ] Use computed properties for record-derived data |
|||
- [ ] Add `v-once` for static content (app name, icons) |
|||
- [ ] Implement `shallowRef` for large record objects |
|||
- [ ] Add memoization for expensive computed values |
|||
- [ ] **Target**: Reduce record update time by 30-40% |
|||
|
|||
#### Database Operations Optimization |
|||
|
|||
- [ ] **Optimize database operations** to reduce 312 IndexedDB calls |
|||
- [ ] Implement database transaction batching |
|||
- [ ] Add database operation queuing |
|||
- [ ] Cache frequently accessed data |
|||
- [ ] Use bulk operations for multiple records |
|||
- [ ] **Target**: Reduce database operations by 50% |
|||
|
|||
#### API Call Optimization |
|||
|
|||
- [ ] **Optimize API calls** to reduce 70 high-impact requests |
|||
- [ ] Implement API response caching |
|||
- [ ] Batch visibility API calls (`canSeeMe`/`cannotSeeMe`) |
|||
- [ ] Add request deduplication for identical calls |
|||
- [ ] Implement API call debouncing |
|||
- [ ] **Target**: Reduce API calls by 40% |
|||
|
|||
#### Test Improvements |
|||
|
|||
- [ ] **Fix Firefox networkIdle issues** |
|||
- [ ] Replace `waitForLoadState('networkidle')` with `waitForSelector()` |
|||
- [ ] Test across all browsers (Chrome, Firefox, Safari) |
|||
- [ ] Add browser-specific wait strategies |
|||
|
|||
- [ ] **Add proper test cleanup** |
|||
- [ ] Implement `beforeEach` cleanup for test state |
|||
- [ ] Add `afterEach` cleanup for alerts and dialogs |
|||
- [ ] Ensure database state is reset between tests |
|||
|
|||
### 🚀 Medium Priority |
|||
|
|||
#### Network Request Optimization |
|||
|
|||
- [ ] **Implement request deduplication** |
|||
- [ ] Create request deduplication service |
|||
- [ ] Cache identical API calls within 5-second window |
|||
- [ ] Add request batching for similar operations |
|||
|
|||
- [ ] **Add request caching layer** |
|||
- [ ] Cache frequently accessed data (user profiles, contacts) |
|||
- [ ] Implement cache invalidation on data changes |
|||
- [ ] Add cache size limits and cleanup |
|||
|
|||
- [ ] **Optimize API endpoints** |
|||
- [ ] Review `/api/report/canSeeMe` and `/api/report/cannotSeeMe` |
|||
- [ ] Consider combining visibility operations |
|||
- [ ] Add response caching headers |
|||
|
|||
#### UI Performance |
|||
|
|||
- [ ] **Implement virtual scrolling** for contact lists |
|||
- [ ] Add virtual scrolling component for large lists |
|||
- [ ] Optimize contact list rendering |
|||
- [ ] Add lazy loading for contact details |
|||
|
|||
- [ ] **Debounce user input** |
|||
- [ ] Add debouncing to contact input fields |
|||
- [ ] Reduce unnecessary API calls during typing |
|||
- [ ] Optimize search functionality |
|||
|
|||
- [ ] **Optimize Vue reactivity** |
|||
- [ ] Review component re-render cycles |
|||
- [ ] Use `shallowRef` for large objects |
|||
- [ ] Implement proper computed properties |
|||
|
|||
### 📊 Low Priority |
|||
|
|||
#### Monitoring and Metrics Tasks |
|||
|
|||
- [ ] **Add performance monitoring** |
|||
- [ ] Create performance metrics collection service |
|||
- [ ] Add real-time performance dashboards |
|||
- [ ] Implement performance alerts for regressions |
|||
|
|||
- [ ] **Set up performance KPIs** |
|||
- [ ] Define target metrics for each action |
|||
- [ ] Add performance regression testing |
|||
- [ ] Create performance baseline documentation |
|||
|
|||
- [ ] **Add browser-specific optimizations** |
|||
- [ ] Implement Firefox-specific optimizations |
|||
- [ ] Add Safari-specific performance improvements |
|||
- [ ] Create browser detection and optimization service |
|||
|
|||
#### Advanced Optimizations |
|||
|
|||
- [ ] **Implement WebSocket connections** |
|||
- [ ] Replace polling with WebSocket for real-time updates |
|||
- [ ] Add WebSocket connection management |
|||
- [ ] Implement fallback to polling |
|||
|
|||
- [ ] **Add service worker caching** |
|||
- [ ] Cache static assets and API responses |
|||
- [ ] Implement offline functionality |
|||
- [ ] Add cache invalidation strategies |
|||
|
|||
- [ ] **Database query optimization** |
|||
- [ ] Add database indexes for frequently queried fields |
|||
- [ ] Optimize database queries for contact operations |
|||
- [ ] Implement query result caching |
|||
|
|||
### 🧪 Testing and Validation |
|||
|
|||
- [ ] **Create performance test suite** |
|||
- [ ] Add dedicated performance test files |
|||
- [ ] Create performance regression tests |
|||
- [ ] Set up automated performance monitoring |
|||
|
|||
- [ ] **Add performance benchmarks** |
|||
- [ ] Create baseline performance measurements |
|||
- [ ] Add performance comparison tools |
|||
- [ ] Document performance improvement targets |
|||
|
|||
- [ ] **Cross-browser performance testing** |
|||
- [ ] Test performance across all supported browsers |
|||
- [ ] Identify browser-specific bottlenecks |
|||
- [ ] Create browser-specific optimization strategies |
|||
|
|||
### 📚 Documentation |
|||
|
|||
- [ ] **Update performance documentation** |
|||
- [ ] Document performance optimization patterns |
|||
- [ ] Create performance troubleshooting guide |
|||
- [ ] Add performance best practices documentation |
|||
|
|||
- [ ] **Create performance monitoring guide** |
|||
- [ ] Document how to use performance metrics |
|||
- [ ] Add performance debugging instructions |
|||
- [ ] Create performance optimization checklist |
|||
|
|||
## Next Steps |
|||
|
|||
1. **Start with high-priority optimizations** - Focus on the biggest bottlenecks first |
|||
2. **Implement medium-priority improvements** - Address network and UI optimizations |
|||
3. **Add monitoring and advanced optimizations** - Build long-term performance infrastructure |
|||
4. **Ongoing monitoring** - Continuously track and improve performance |
|||
@ -1,232 +0,0 @@ |
|||
# Contact Import Testing Implementation |
|||
|
|||
## Overview |
|||
|
|||
This document describes the comprehensive test suite implemented for Time Safari's |
|||
contact import functionality. The tests cover all scenarios mentioned in the |
|||
original TODO comment and provide thorough validation of the contact import feature. |
|||
|
|||
## Test File: `45-contact-import.spec.ts` |
|||
|
|||
### Test Coverage |
|||
|
|||
The test suite covers all the requirements from the original TODO: |
|||
|
|||
1. ✅ **Contact import via URL query parameters** |
|||
- Single contact import: `/contact-import?contacts=[{"did":"did:example:123","name":"Alice"}]` |
|||
- Multiple contacts import with proper encoding |
|||
- URL parameter validation and error handling |
|||
|
|||
2. ✅ **JWT import via URL path** |
|||
- JWT token in URL: `/contact-import/[JWT_TOKEN]` |
|||
- Deep link support: `/deep-link/contact-import/[JWT_TOKEN]` |
|||
- JWT payload validation and parsing |
|||
|
|||
3. ✅ **Manual JWT input via textarea** |
|||
- Direct JWT string input |
|||
- Raw contact data input |
|||
- Input validation and error handling |
|||
|
|||
4. ✅ **Duplicate contact detection and field comparison** |
|||
- Existing contact detection |
|||
- Field-by-field comparison display |
|||
- Modified contact handling |
|||
|
|||
5. ✅ **Error scenarios** |
|||
- Invalid JWT format detection |
|||
- Malformed contact data validation |
|||
- Missing required fields handling |
|||
- Wrong data types validation |
|||
- Network error simulation |
|||
|
|||
6. ✅ **Error logging verification** |
|||
- Console error message validation |
|||
- UI error message display verification |
|||
- Error state handling |
|||
|
|||
### Test Scenarios |
|||
|
|||
#### Basic Import Tests |
|||
|
|||
- **Single contact via URL**: Tests basic URL parameter import |
|||
- **Multiple contacts via URL**: Tests bulk import functionality |
|||
- **JWT path import**: Tests JWT token in URL path |
|||
- **Deep link import**: Tests deep link redirect functionality |
|||
- **Manual JWT input**: Tests textarea JWT input |
|||
- **Manual contact data input**: Tests raw JSON input |
|||
|
|||
#### Advanced Functionality Tests |
|||
|
|||
- **Duplicate detection**: Tests existing contact identification |
|||
- **Field comparison**: Tests difference display for modified contacts |
|||
- **Selective import**: Tests checkbox selection functionality |
|||
- **Visibility settings**: Tests activity visibility controls |
|||
- **Mixed new/existing**: Tests combination scenarios |
|||
- **Large import performance**: Tests performance with 10+ contacts |
|||
|
|||
#### Error Handling Tests |
|||
|
|||
- **Invalid JWT format**: Tests malformed JWT handling |
|||
- **Empty contact array**: Tests empty data handling |
|||
- **Missing required fields**: Tests incomplete data validation |
|||
- **Wrong data types**: Tests type validation |
|||
- **Network error simulation**: Tests network failure handling |
|||
|
|||
### Test Data |
|||
|
|||
#### Valid Test Contacts |
|||
|
|||
```typescript |
|||
const TEST_CONTACTS = { |
|||
alice: { |
|||
did: 'did:ethr:0x111d15564f824D56C7a07b913aA7aDd03382aA39', |
|||
name: 'Alice Test', |
|||
publicKey: 'alice-public-key-123' |
|||
}, |
|||
bob: { |
|||
did: 'did:ethr:0x222BB77E6Ff3774d34c751f3c1260866357B677b', |
|||
name: 'Bob Test', |
|||
publicKey: 'bob-public-key-456' |
|||
}, |
|||
charlie: { |
|||
did: 'did:ethr:0x333CC88F7Gg488e45d862f4d237097f748C788c', |
|||
name: 'Charlie Test', |
|||
publicKey: 'charlie-public-key-789' |
|||
} |
|||
}; |
|||
``` |
|||
|
|||
#### Invalid Test Data |
|||
|
|||
```typescript |
|||
const INVALID_DATA = { |
|||
malformedJwt: 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.invalid.payload', |
|||
emptyArray: '[]', |
|||
missingFields: '[{"name":"Incomplete Contact"}]', |
|||
wrongTypes: '[{"did":123,"name":456}]', |
|||
networkError: 'http://invalid-url-that-will-fail.com/contacts' |
|||
}; |
|||
``` |
|||
|
|||
### Utility Functions Added |
|||
|
|||
#### New Functions in `testUtils.ts` |
|||
|
|||
- `createTestJwt(payload)`: Creates test JWT tokens |
|||
- `cleanupTestContacts(page, contactNames)`: Cleans up test contacts |
|||
- `addTestContact(page, did, name, publicKey?)`: Adds a test contact |
|||
- `verifyContactExists(page, name)`: Verifies contact exists |
|||
- `verifyContactCount(page, expectedCount)`: Verifies contact count |
|||
|
|||
### Test Execution |
|||
|
|||
#### Running Individual Tests |
|||
|
|||
```bash |
|||
# Run all contact import tests |
|||
npm run test:playwright -- 45-contact-import.spec.ts |
|||
|
|||
# Run specific test |
|||
npm run test:playwright -- 45-contact-import.spec.ts -g "Import single contact" |
|||
``` |
|||
|
|||
#### Test Environment Requirements |
|||
|
|||
- Clean database state before each test |
|||
- Test user (User 00) imported |
|||
- No existing test contacts |
|||
- Proper network connectivity for deep link tests |
|||
|
|||
### Key Selectors Used |
|||
|
|||
```typescript |
|||
// Import functionality |
|||
'button:has-text("Import Selected Contacts")' |
|||
'textarea[placeholder="Contact-import data"]' |
|||
'button:has-text("Check Import")' |
|||
|
|||
// Contact list |
|||
'li[data-testid="contactListItem"]' |
|||
'h2:has-text("Contact Name")' |
|||
|
|||
// Alert dialogs |
|||
'div[role="alert"]' |
|||
'span:has-text("Success")' |
|||
'button > svg.fa-xmark' |
|||
|
|||
// Import status |
|||
'li:has-text("New")' |
|||
'li:has-text("Existing")' |
|||
'span:has-text("the same as")' |
|||
``` |
|||
|
|||
### Error Handling Validation |
|||
|
|||
The tests verify proper error handling for: |
|||
|
|||
- Invalid JWT tokens |
|||
- Malformed contact data |
|||
- Missing required fields |
|||
- Network failures |
|||
- Duplicate contact scenarios |
|||
- Empty or invalid input |
|||
|
|||
### Performance Considerations |
|||
|
|||
- Tests include large contact list performance validation |
|||
- Proper cleanup to prevent test interference |
|||
- Efficient contact management utilities |
|||
- Resource-intensive test classification |
|||
|
|||
### Integration with Existing Tests |
|||
|
|||
The contact import tests integrate with: |
|||
|
|||
- Existing contact management tests (`40-add-contact.spec.ts`) |
|||
- User management utilities (`testUtils.ts`) |
|||
- Platform service testing infrastructure |
|||
- Database migration testing framework |
|||
|
|||
### Security Considerations |
|||
|
|||
- JWT token validation testing |
|||
- Input sanitization verification |
|||
- Error message security (no sensitive data exposure) |
|||
- Network request validation |
|||
|
|||
## Migration Status |
|||
|
|||
This test implementation addresses the TODO comment requirements: |
|||
|
|||
``` |
|||
// TODO: Testing Required - Database Operations + Logging Migration to PlatformServiceMixin |
|||
// Priority: Medium | Migrated: 2025-07-06 | Author: Matthew Raymer |
|||
``` |
|||
|
|||
**Status**: ✅ **COMPLETED** - August 4, 2025 |
|||
|
|||
All 6 testing requirements have been implemented with comprehensive coverage: |
|||
|
|||
1. ✅ Contact import via URL |
|||
2. ✅ JWT import via URL path |
|||
3. ✅ Manual JWT input |
|||
4. ✅ Duplicate contact detection |
|||
5. ✅ Error scenarios |
|||
6. ✅ Error logging verification |
|||
|
|||
## Future Enhancements |
|||
|
|||
Potential improvements for the test suite: |
|||
|
|||
- Real JWT signing for more authentic testing |
|||
- Network interception for better error simulation |
|||
- Performance benchmarking metrics |
|||
- Cross-platform compatibility testing |
|||
- Accessibility testing for import interfaces |
|||
|
|||
## Author |
|||
|
|||
**Matthew Raymer** - 2025-08-04 |
|||
|
|||
This test suite provides comprehensive coverage of the contact import functionality |
|||
and ensures robust validation of all import methods, error scenarios, and edge cases. |
|||
@ -1,256 +0,0 @@ |
|||
# Performance Monitoring in Playwright Tests |
|||
|
|||
Performance monitoring is more than just numbers — it’s about understanding **how your users experience your app** during automated test runs. |
|||
This guide will teach you not just how to set it up, but also **why each step matters**. |
|||
|
|||
--- |
|||
|
|||
## Why Performance Monitoring Matters |
|||
|
|||
Think of Playwright tests as quality control for your app’s speed and responsiveness. |
|||
By adding performance monitoring, you can: |
|||
|
|||
- 🚨 **Catch regressions early** before users feel them |
|||
- 🎯 **Keep user experience consistent** across releases |
|||
- 🔎 **Spot bottlenecks** in login, navigation, or heavy data flows |
|||
- 📊 **Make informed decisions** with hard data, not guesses |
|||
- 🏆 **Maintain performance standards** as features grow |
|||
|
|||
> **Key Insight:** Without metrics, “fast” is just a feeling. With metrics, it’s a fact. |
|||
|
|||
--- |
|||
|
|||
## How It Works: The Architecture |
|||
|
|||
The monitoring system has **four pillars**: |
|||
|
|||
1. **PerformanceCollector Class** – Collects raw metrics |
|||
2. **Performance Utilities** – Easy-to-use helper functions |
|||
3. **Test Integration** – Hooks directly into Playwright tests |
|||
4. **Report Generation** – Creates JSON reports you can analyze later |
|||
|
|||
Here’s a mental model: |
|||
|
|||
``` |
|||
Playwright Test |
|||
| |
|||
v |
|||
PerformanceCollector (collects data) |
|||
| |
|||
v |
|||
Report Generation → JSON / HTML / CI attachments |
|||
``` |
|||
|
|||
### Core Collector |
|||
|
|||
```typescript |
|||
// performanceUtils.ts |
|||
export class PerformanceCollector { |
|||
private page: Page; |
|||
public metrics: any; |
|||
public navigationMetrics: any[]; |
|||
private cdpSession: any; |
|||
|
|||
// Methods for collecting various metrics |
|||
async collectNavigationMetrics(label: string) |
|||
async collectWebVitals() |
|||
async measureUserAction(actionName: string, actionFn: () => Promise<void>) |
|||
generateReport() |
|||
} |
|||
``` |
|||
|
|||
👉 **Teaching Point:** `measureUserAction` wraps a user action and times it, giving you reproducible benchmarks. |
|||
|
|||
--- |
|||
|
|||
## Quick Start: A Simple Example |
|||
|
|||
```typescript |
|||
import { createPerformanceCollector, attachPerformanceData } from './performanceUtils'; |
|||
|
|||
test('My test with performance monitoring', async ({ page }, testInfo) => { |
|||
const perfCollector = await createPerformanceCollector(page); |
|||
|
|||
// Measure user action |
|||
await perfCollector.measureUserAction('click-button', async () => { |
|||
await page.click('#my-button'); |
|||
}); |
|||
|
|||
// Attach data to the test report |
|||
await attachPerformanceData(testInfo, perfCollector); |
|||
}); |
|||
``` |
|||
|
|||
✅ After this test runs, you’ll find performance data **directly in the Playwright report**. |
|||
|
|||
--- |
|||
|
|||
## Advanced Example: A Complete User Flow |
|||
|
|||
```typescript |
|||
test('Complex user flow with performance tracking', async ({ page }, testInfo) => { |
|||
const perfCollector = await createPerformanceCollector(page); |
|||
|
|||
await perfCollector.collectNavigationMetrics('initial-load'); |
|||
|
|||
await perfCollector.measureUserAction('login', async () => { |
|||
await page.fill('#username', 'user'); |
|||
await page.fill('#password', 'pass'); |
|||
await page.click('#login-button'); |
|||
}); |
|||
|
|||
await perfCollector.measureUserAction('navigate-to-dashboard', async () => { |
|||
await page.goto('/dashboard'); |
|||
}); |
|||
|
|||
await attachPerformanceData(testInfo, perfCollector); |
|||
}); |
|||
``` |
|||
|
|||
> **Pro Tip:** Use descriptive labels like `'login'` or `'navigate-to-dashboard'` |
|||
to make reports easy to scan. |
|||
|
|||
--- |
|||
|
|||
## What Metrics You’ll See |
|||
|
|||
### Navigation Metrics (Page Load) |
|||
|
|||
- `domContentLoaded` → When DOM is ready |
|||
- `loadComplete` → When page is fully loaded |
|||
- `firstPaint` → When users first *see* something |
|||
- `serverResponse` → How quickly the backend responds |
|||
|
|||
### User Action Metrics |
|||
|
|||
- `duration` → How long the action took |
|||
- `metrics` → Detailed performance snapshots |
|||
|
|||
### Memory Usage |
|||
|
|||
- `used`, `total`, `limit` → Helps catch leaks and spikes |
|||
|
|||
### Web Vitals |
|||
|
|||
- **LCP** → Largest Contentful Paint |
|||
- **FID** → First Input Delay |
|||
- **CLS** → Layout stability |
|||
|
|||
--- |
|||
|
|||
## Reading the Data: A Beginner’s Lens |
|||
|
|||
Here’s what a **healthy test run** might look like: |
|||
|
|||
```json |
|||
{ |
|||
"label": "home-page-load", |
|||
"metrics": { |
|||
"domContentLoaded": 294, |
|||
"loadComplete": 295, |
|||
"serverResponse": 27.6, |
|||
"resourceCount": 96 |
|||
} |
|||
} |
|||
``` |
|||
|
|||
**Interpretation:** |
|||
|
|||
- DOM loaded fast (<500ms) ✅ |
|||
- Server response is excellent (<100ms) ✅ |
|||
- Resource count is reasonable for a SPA ✅ |
|||
|
|||
Now, here’s a **problematic run**: |
|||
|
|||
```json |
|||
{ |
|||
"label": "slow-page-load", |
|||
"metrics": { |
|||
"domContentLoaded": 2500, |
|||
"loadComplete": 5000, |
|||
"serverResponse": 800, |
|||
"resourceCount": 200 |
|||
} |
|||
} |
|||
``` |
|||
|
|||
**Interpretation:** |
|||
|
|||
- DOM took 2.5s ❌ |
|||
- Full load took 5s ❌ |
|||
- Too many resources (200) ❌ |
|||
|
|||
> **Lesson:** Slow page loads often mean large bundles, too many requests, or server lag. |
|||
|
|||
--- |
|||
|
|||
## Performance Threshold Cheat Sheet |
|||
|
|||
| Metric | Excellent | Good | Poor | |
|||
|--------|-----------|------|------| |
|||
| domContentLoaded | < 500ms | < 1000ms | > 2000ms | |
|||
| loadComplete | < 1000ms | < 2000ms | > 3000ms | |
|||
| userAction duration | < 100ms | < 300ms | > 500ms | |
|||
| memory usage | < 50MB | < 100MB | > 150MB | |
|||
|
|||
👉 Use these thresholds to set alerts in your regression tests. |
|||
|
|||
--- |
|||
|
|||
## Common Patterns |
|||
|
|||
1. **Initial Page Load** |
|||
- ✅ DOM in <500ms |
|||
- ✅ Load in <1000ms |
|||
- ⚠️ Watch out for large bundles |
|||
|
|||
2. **User Interaction** |
|||
- ✅ Actions under 100ms |
|||
- ✅ Few/no extra requests |
|||
- ⚠️ Avoid bloated API calls |
|||
|
|||
3. **Navigation** |
|||
- ✅ <200ms between pages |
|||
- ⚠️ Inconsistency usually means missing cache headers |
|||
|
|||
--- |
|||
|
|||
## Best Practices |
|||
|
|||
- 📏 **Consistency** – Measure the same flows every run |
|||
- 🧪 **Realism** – Test with production-like data |
|||
- 🏗 **Environment Control** – Use stable test environments |
|||
- 📉 **Set Thresholds** – Define what “slow” means for your team |
|||
- 🔁 **Continuous Monitoring** – Run in CI/CD and watch trends |
|||
|
|||
> **Remember:** A fast app last release doesn’t guarantee it’s fast today. |
|||
|
|||
--- |
|||
|
|||
## Migration Tip |
|||
|
|||
**Before (Manual Timing):** |
|||
```typescript |
|||
const start = Date.now(); |
|||
await page.click('#button'); |
|||
console.log(Date.now() - start); |
|||
``` |
|||
|
|||
**After (Structured Monitoring):** |
|||
|
|||
```typescript |
|||
await perfCollector.measureUserAction('button-click', async () => { |
|||
await page.click('#button'); |
|||
}); |
|||
``` |
|||
|
|||
✅ Cleaner, more consistent, and automatically reported. |
|||
|
|||
--- |
|||
|
|||
## Key Takeaway |
|||
|
|||
Performance monitoring in Playwright isn’t just about collecting data — it’s |
|||
about making your tests **teach you** how users experience your app. |
|||
The **PerformanceCollector** class plus good testing habits give you a clear, |
|||
data-driven picture of app health. |
|||
Loading…
Reference in new issue