{"id":33726,"date":"2026-05-29T14:33:11","date_gmt":"2026-05-29T12:33:11","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=33726"},"modified":"2026-05-29T18:12:29","modified_gmt":"2026-05-29T16:12:29","slug":"how-i-made-my-a2ui-dashboard-300-times-faster","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/how-i-made-my-a2ui-dashboard-300-times-faster\/","title":{"rendered":"How I Made My A2UI Dashboard 300 Times Faster"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 7 of 7 in the series “Agentic Angular”<\/em>\t\t<\/p>\n\t\t\t<\/label>\n\n\t\t\t

\n\t\t\t
    \n\t\t\t\t\t\t\t\t\t
  1. Understanding AG-UI: The Standard for Agentic User Interfaces<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  2. AG-UI in Practice: The SDK for TypeScript<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  3. Implementing AG-UI with Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  4. A2UI: How AI Generates Dynamic UIs at Runtime<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  5. Integrating A2UI with AG-UI in Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  6. Custom Catalogs in A2UI: Your Own Components for AI-Generated UIs<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  7. How I Made My A2UI Dashboard 300 Times Faster<\/span><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    39 seconds. Over 46,000 tokens. For a single<\/em> dashboard. That's what the first version of my A2UI solution looked like \u2013 and nobody wants to see something like that in production, neither the users staring at an empty screen nor the person who pays the model provider's bill at the end of the month.<\/p>\n

    Today the same solution runs at around 0.1 seconds<\/strong> and a little over 1,500 tokens<\/strong>. That's a speedup by a factor of 300<\/strong> and a reduction in token consumption by a factor of 30<\/strong>. The truly interesting part, though, isn't the number itself, but the surprisingly simple lever behind it \u2013 and the lesson it offers for any LLM-powered UI generation.<\/p>\n

    In a previous article, I showed how A2UI can be used to generate entire dashboards. The result looked like this:<\/p>\n

    \"The<\/p>\n

    In this article, I'll show how I dramatically sped up exactly that solution \u2013 and what consequences this optimization brings with it. Because every performance gain comes at a price.<\/p>\n

    The Problem: Why A2UI Generation Was Slow and Expensive<\/h2>\n

    A bit of context first: A2UI<\/code> is a protocol that lets you describe user interfaces \u2013 here, a dashboard \u2013 in a way that an LLM can generate them. So the model doesn't produce finished HTML, but a structured description of the interface that the client then renders. It was exactly this generation step that was the bottleneck in the first version.<\/p>\n

    To generate A2UI, you first need a correspondingly long prompt with good examples \u2013 classic one-shot or few-shot prompting. Since LLMs handle such examples extremely well, I didn't even copy the full A2UI specification or JSON schema into the prompt. Even so, the whole thing was very large: in the example shown at the beginning, we ended up with over 43,000 input tokens<\/strong>.<\/p>\n

    On top of that: generating the A2UI markup from this description took correspondingly long. The model has to produce an extensive structure token by token \u2013 and that's exactly what's expensive.<\/p>\n

    In addition, the model has to repeatedly issue function calls to retrieve the data for the individual tiles. Each of these calls costs additional reasoning, and therefore time and tokens.<\/p>\n

    And finally, perhaps the most unpleasant problem: when generating A2UI, the model can get confused and produce faulty markup. A2UI's basic design \u2013 which, for instance, deliberately avoids deep nesting \u2013 does help LLMs noticeably. But errors can't be ruled out entirely, and every error forces additional correction loops. Weaker (and thus cheaper) models in particular are affected by this.<\/p>\n

    This is what a complete run looked like in the original variant:<\/p>\n

    \"Trace<\/p>\n

    It's easy to see: the model first gathers the data via several tool calls and then generates the complete A2UI markup in a single step lasting over 30 seconds. This one step dominates the entire runtime.<\/p>\n

    The Solution: an Application-Specific DSL Instead of A2UI Markup<\/h2>\n

    The idea is remarkably simple: a small, application-specific DSL<\/code> (Domain-Specific Language) \u2013 that is, a deliberately minimal description language tailored to exactly one purpose \u2013 that lets you describe precisely what should be generated: a dashboard with specific contents that fit the application. In our case, this DSL looks like this:<\/p>\n

    {\n  "toolName": "renderDashboard",\n  "toolCallId": "call_2mO2fjJD4ZpGHna4yXsW8QG0",\n  "toolInput": {\n    "tiles": [\n      {\n        "type": "boardingPasses",\n        "count": 2\n      },\n      {\n        "type": "bookedFlightsList",\n        "showCheckInButton": true\n      },\n      {\n        "type": "flightSearch",\n        "defaultFrom": "Graz",\n        "defaultTo": "Hamburg"\n      },\n      {\n        "type": "rentalCars"\n      },\n      {\n        "type": "hotels"\n      },\n      {\n        "type": "weatherList"\n      }\n    ]\n  }\n}<\/code><\/pre>\n
    The model is now only instructed to translate the user's request into this DSL. That's all it does. Since this leads to a very short result, the conversion is fast, less error-prone, and even weaker models handle it without any trouble.<\/p>\n
    There's another, often underestimated advantage: the application is thereby forced more strongly into a defined framework. The model can no longer do things that the application design didn't anticipate. As a result \u2013 despite the fundamentally non-deterministic behavior of an LLM \u2013 the outcome becomes much more controllable.<\/p>\n
    This DSL is then used for two purposes:<\/p>\n
      \n
    1. Conversion into A2UI<\/strong> \u2013 deterministic, in code, without any model.<\/li>\n
    2. Retrieving the necessary data<\/strong> \u2013 likewise without any further reasoning by the model.<\/li>\n<\/ol>\n
      The crucial point: both the translation into A2UI and the fetching of the data now happen in ordinary application code. The model is no longer involved in any of it.<\/p>\n
      And the client notices none of this. It still receives A2UI as before and therefore doesn't need to know any details of the application logic. The DSL is purely an implementation decision on the server side.<\/p>\n
      Consequences: Pros and Cons of the DSL Approach<\/h2>\n
      As always in software architecture, there's no such thing as "free." Let's lay out the pros and cons.<\/p>\n
      Pros:<\/strong><\/p>\n