Performance improvement: Optimize publishing of design tokens to only affected pages

[surajair]

Currently, when publishing design tokens, all design tokens are published, and the process does not return the specific pages where a design token was used. For better performance, we should identify which design tokens have actually changed and then determine only the pages using those changed design tokens. Then, return the relevant page tags.

Current Implementation:

The publishDesignToken method in PublishChangesAction currently:

1. Publishes ALL design tokens without checking which ones changed
2. Returns a generic tag website-settings-${appId} for all pages
3. Does not track which pages use which design tokens

Proposed Solution:

1. Track changed design tokens: Compare current design tokens with the published version to identify what changed
2. Find affected pages: Use the existing siteWideUsage data structure (already tracks design token usage per page) to identify pages using the changed tokens
3. Return specific page tags: Instead of returning a generic website-settings tag, return tags only for affected pages

Relevant Code:

• Publishing logic: src/actions/builder/publish-changes.ts - publishDesignToken() method (lines 137-166)
• Design token management: src/core/components/settings/new-panel/manage-design-token/manage-design-tokens.tsx
• Usage tracking: The siteWideUsage prop already tracks design token usage per page (see line 126 in manage-design-tokens.tsx)
• Token usage analysis: src/core/components/settings/new-panel/manage-design-token/design-token-usage.tsx - shows how to find pages using specific tokens

Benefits:

• Improved performance by invalidating/updating only affected pages
• Better cache management
• More granular change tracking
• Reduced unnecessary rebuilds

Acceptance Criteria:

• Detect design tokens that were changed during publishing
• Query siteWideUsage to identify pages where changed tokens are used
• Return only the tags of affected pages, not all pages
• Update tests to verify only affected pages are invalidated

Notes:

• This is a low priority optimization task
• The siteWideUsage data structure already exists and tracks this information
• Consider performance implications of comparing large design token sets