Description
The new website currently experiences a noticeable delay during the initial load, particularly when starting the app from a clean state (e.g., incognito window). The main cause appears to be the way Drapo loads JavaScript files dynamically — as the page renders, it identifies new components and injects additional <script> tags until all components are resolved.
To improve performance, we need to optimize how Drapo component scripts are handled and delivered in production environments. One of the most effective first steps is to minify the Drapo JS component files at build/publish time. This will reduce payload size and speed up the initial load without requiring significant architectural changes.
User Story
As a website visitor,
I want the application to load faster on first access,
So that I have a smooth and responsive experience even on initial loads or incognito sessions.
Requirements
Functional Requirements
Context: Initial load performance improvement for the website
- FR01: Implement JS minification for all Drapo component scripts when publishing or deploying to production environments.
- FR02: Ensure minification happens automatically during the build/publish pipeline (not manually).
- FR03: Keep source maps available for debugging (if needed, only in non-prod environments).
- FR04: The minification process should only be applied when the environment is set to “PRD” or equivalent.
- FR05: Development and staging environments should continue to load non-minified JS for easier debugging.
- FR06: Validate that Drapo component loading still works properly after minification (no breaking changes on initialization or dynamic injection).
- FR07: Confirm that caching and script versioning logic continue to function as expected.
Non-Functional Requirements
Context: Build pipeline and deployment optimization
- NFR01: No functional or rendering issues due to minified scripts.
- NFR02: Build logs or deploy outputs confirm the minification step is executed for PRD builds.
- NFR03: Site’s initial load time in an incognito window shows measurable improvement (lower total JS size / faster DOMContentLoaded time).
Acceptance Criteria
- All Drapo JS component files are minified when deployed to production.
- Non-production environments (QA, DEV, STG) remain non-minified for debugging.
- The site’s initial load time in an incognito window shows a measurable improvement (lower total JS size / faster DOMContentLoaded time).
- No functional or rendering issues occur due to minified scripts.
- Build logs or deploy outputs confirm the minification step is executed for PRD builds.
Minimum Test Scenarios (Gherkin)
Scenario: Production build minifies Drapo JS component files
Given the environment is set to "PRD"
When the build/publish pipeline runs
Then all Drapo JS component files should be minified
And build logs should confirm minification step
Scenario: Non-production builds do not minify JS
Given the environment is "DEV", "QA", or "STG"
When the build/publish pipeline runs
Then Drapo JS component files should not be minified
And source maps should be available for debugging
Scenario: Initial load performance improvement
Given a new incognito browser session
When the user accesses the application
Then the initial load time should be faster compared to previous non-minified deployment
And total JS payload size should be reduced
Scenario: No functional issues after minification
Given the application is deployed with minified Drapo JS components
When the user navigates and interacts with all dynamic components
Then all components should load and function as expected
Solution
Integrate a JS minification tool (e.g., Terser, UglifyJS, or Webpack built-in minification) into the build/publish pipeline. Configure the pipeline to conditionally minify Drapo JS component files only for production ("PRD") builds. Ensure source maps are generated only for non-prod environments. Validate component loading and caching/versioning logic post-minification by running smoke and regression tests in production-like environments. Update deployment documentation to reflect the minification process and log verification.
Developer Checklist
Description
The new website currently experiences a noticeable delay during the initial load, particularly when starting the app from a clean state (e.g., incognito window). The main cause appears to be the way Drapo loads JavaScript files dynamically — as the page renders, it identifies new components and injects additional <script> tags until all components are resolved.
To improve performance, we need to optimize how Drapo component scripts are handled and delivered in production environments. One of the most effective first steps is to minify the Drapo JS component files at build/publish time. This will reduce payload size and speed up the initial load without requiring significant architectural changes.
User Story
As a website visitor,
I want the application to load faster on first access,
So that I have a smooth and responsive experience even on initial loads or incognito sessions.
Requirements
Functional Requirements
Context: Initial load performance improvement for the website
Non-Functional Requirements
Context: Build pipeline and deployment optimization
Acceptance Criteria
Minimum Test Scenarios (Gherkin)
Solution
Integrate a JS minification tool (e.g., Terser, UglifyJS, or Webpack built-in minification) into the build/publish pipeline. Configure the pipeline to conditionally minify Drapo JS component files only for production ("PRD") builds. Ensure source maps are generated only for non-prod environments. Validate component loading and caching/versioning logic post-minification by running smoke and regression tests in production-like environments. Update deployment documentation to reflect the minification process and log verification.
Developer Checklist