Performance Verification¶
Performance was an important consideration during Toodle's development. The team worked to reduce unnecessary loading, improve the delivery of frontend assets, and maintain a responsive experience across different devices.
Performance verification focused primarily on the React frontend, using production build analysis, Lighthouse and regression testing.
Performance Testing Approach¶
The team used two main approaches to evaluate frontend performance.
| Method | Purpose |
|---|---|
| Lighthouse | Evaluate page loading, visual stability and browser performance |
| Vite production builds | Measure JavaScript bundles, CSS and image asset sizes |
Lighthouse provides performance indicators such as:
- First Contentful Paint (FCP): When the first visible content appears.
- Largest Contentful Paint (LCP): When the largest visible element finishes rendering.
- Total Blocking Time (TBT): Time spent blocking the main browser thread.
- Cumulative Layout Shift (CLS): Unexpected movement of visible page elements.
- Speed Index: How quickly page content becomes visually available.
Performance comparisons were based on production builds rather than the development server.
Performance Optimisations¶
Route-Level Code Splitting¶
Initially, most application pages were included in a large JavaScript bundle, even when users did not immediately need those pages.
The team introduced React lazy loading for authenticated routes.
This allowed pages such as the allocation board, timesheets, dashboards and calendar to load their JavaScript when accessed.
A Suspense loading state was also introduced so that the application could display a loading indicator while additional page resources were retrieved.
Vendor Chunking¶
Third-party libraries were separated into reusable JavaScript chunks through Vite's build configuration.
This reduced the amount of code bundled together with the main application entry point.
Larger dependencies, including the calendar and drag-and-drop libraries, could be loaded when the corresponding functionality was needed.
Image Optimisation¶
The landing page originally used large PNG images for the hero illustration and application logo.
These assets were optimised using WebP, with appropriately sized image variants and PNG fallbacks.
The changes reduced image transfer sizes while maintaining the application's visual appearance.
Explicit image dimensions were also used to help prevent unexpected layout shifts during loading.
Reducing Redundant API Requests¶
The tutor dashboard previously fetched the current user's profile even though the information was already available through the authentication context.
The dashboard was updated to reuse the existing profile data.
This removed an unnecessary API request without changing the dashboard's intended behaviour.
Before-and-After Results¶
Main JavaScript Bundle¶
Production build analysis recorded the following changes to the main application entry chunk.
| Metric | Before | After | Reduction |
|---|---|---|---|
| Raw JavaScript | 923.78 kB | 87.23 kB | 90.6% |
| Gzipped JavaScript | 276.70 kB | 25.56 kB | 90.8% |
The reduction was achieved by separating application pages and third-party libraries into independently loaded chunks.
Important: These figures represent the main entry chunk, not the total JavaScript transferred by the browser. Shared vendor chunks and page-specific code are still loaded when required.
Image Asset Sizes¶
| Asset | Before | After | Approximate Reduction |
|---|---|---|---|
| Landing hero | 1001.43 kB | 127.79 kB | 87% |
| Application logo | 533.32 kB | 13.37 kB | 97% |
WebP reduced the size of the images delivered to supported browsers.
The original assets were retained for development purposes, while optimised versions were used by the application.
Landing Page Transfer Size¶
The team also compared the approximate combined size of JavaScript, CSS and images downloaded for the landing page.
| Asset Category | Before | After |
|---|---|---|
| JavaScript | 923.78 kB | ~758.7 kB |
| CSS | 68.49 kB | 68.49 kB |
| Hero image | 1001.43 kB | 127.79 kB |
| Logo | 533.32 kB | 13.37 kB |
| Total | ~2.47 MB | ~0.95 MB |
The recorded comparison represents an approximate 62% reduction in initial landing-page asset weight for a browser supporting WebP.
These measurements are based on the recorded production build output and asset calculations. They should not be interpreted as independently measured network transfer times.
Performance Improvements at a Glance¶
| Area | Improvement |
|---|---|
| Initial loading | Smaller main application entry chunk |
| Navigation | Application pages loaded on demand |
| Image delivery | Smaller WebP assets |
| Browser caching | Separate reusable vendor chunks |
| API efficiency | Removed a redundant tutor dashboard request |
| Visual stability | Reserved image dimensions and loading states |
Together, these changes reduced unnecessary data transfer and improved how application resources were organised.
Regression Verification¶
The team also checked that the performance changes did not interfere with existing functionality.
The recorded optimisation verification included:
- 187 frontend tests passing across 30 files.
- Successful ESLint checks.
- Successful production build.
- Verification that role-based routes and navigation remained unchanged.
- Tests for the optimised logo component and tutor dashboard profile handling.
These results relate to the recorded performance-optimisation work, rather than the final test totals for the entire project.
The changes focused on how resources were loaded and delivered, without intentionally changing existing tutor-management workflows.
Measurement Limitations¶
Performance measurements can vary depending on the device, browser, network connection and server conditions.
The before-and-after results above are supported by recorded build sizes and asset measurements.
Although Lighthouse was used as part of the performance-verification approach, the supplied evidence does not establish a complete set of comparable numerical Lighthouse scores for every route and device.
Therefore, no unverified Lighthouse scores or loading-time improvements are claimed.
The recorded results also focus on frontend performance rather than independently benchmarking backend response times or database query performance.
Summary¶
Toodle's performance optimisation work concentrated on reducing unnecessary resources and improving the organisation of frontend code.
Route-level lazy loading, vendor chunking, image optimisation and removal of redundant API requests produced measurable reductions in bundle and asset sizes.
These improvements were supported by automated tests, linting and production build verification, helping the team improve frontend efficiency while preserving the application's existing functionality.