What a PX page actually weighs, and the switch that halves it

"Can the controller serve this graphic?" is normally answered with an opinion — it depends, keep it simple, use a Supervisor. It has a measurable form: when an operator opens the view, how many files and how many bytes does the station send, and how much of that is your drawing?

That is answerable without a running station, because the framework declares its own client-side dependency graph in Java. Every module that ships browser code registers a BJsBuild singleton naming exactly one pre-built bundle plus the builds it depends on, and the page writer resolves that set into the nested require() calls it writes into the page. Read the classes and you have the payload the framework will ask for, per view, exactly as the framework computes it. The figures below come from a stock Niagara 4.15 install.

Every session loads the same bootstrap, whatever the view contains. The requirejs alias table decides which file each name resolves to, and at stock defaults it resolves to the minified copy of each library:

Twelve files, 718 KB, 222 AMD modules, and not one pixel of anybody's building. BajaScript is the largest single item and it is not loaded by a define([...]) list that a scan would find — the baja! plugin requires it at runtime, which is why it is missing from most estimates of this.

Resolving each build's declared closure gives two honest figures rather than one. The certain column is the floor plus every bundle and stylesheet in the resolved graph: those are written into the page's require() blocks and fetched whether or not a particular widget is used. The ceiling adds every loose file a bundle member declares that no loaded bundle provides — the Ace code editor at 446.9 KB, the icon sprite stylesheet at 216.2 KB, moment, the dialogs plugin, jQuery contextMenu. Those are fetched lazily, when something that needs them is instantiated, so a real page lands between the two columns.

One bundle dominates all of them: the web editors bundle, 916 KB carrying 417 AMD modules — field editors, property sheet, nav tree, composite editor — pulled in by the graphics module, the standard widget kit, the chart module and the hx container alike. A read-only floorplan on a wall panel gets the whole editing toolkit, because the dependency is declared at build level rather than at view level.

Counted as AMD modules instead of files, a PX page with standard widgets is about 900 modules arriving in 31 requests. That ratio is the bundling doing its job, and it is the reason webdev mode belongs nowhere near a site station: with it on for a module, requirejs fetches that module's members individually and the same view goes from tens of requests to several hundred.

This is the finding worth acting on. The station's web server does have a gzip handler, and its MIME list covers JavaScript, CSS, HTML, plain text, JSON and the XML types — everything in the tables above. But the handler is only added to the handler collection when the web service's gzipEnabled property is true, and that property is declared HIDDEN with a default of false. You will not see it on the property sheet until you show hidden slots.

Nothing downstream compensates. Module resources are served from /module/* by a file servlet whose only content-encoding path requires the file on disk to already be a gzip file, which no bundle is. The heap-memory file cache that does compress is mapped to /vfile/* only.

Two caveats, both checkable. The gzip handler is present in the compact3 build of the web server that ships in the controller's own distribution file, so this is not a Supervisor-only switch. And the trade is controller CPU: this path is not cached, so it compresses per response. Turn it on deliberately, having tested it on your own hardware, before doing it at a site where many operators log in cold at once.

Module files are long-term cacheable by construction: because they live in a module's space, the servlet sends Cache-Control: private, must-revalidate, max-age=2592000 — thirty days. The second graphic an operator opens costs almost nothing, which is the right design.

It has a consequence people meet without recognising it. The page's requirejs config carries a urlArgs cache-buster derived from the last build time, so after a station upgrade or a module install every operator's first graphic is a full cold load again. If that is 2.3 MB uncompressed per operator, the morning after a Tuesday-night upgrade is when the site link gets measured for you.

Caching also switches off in two places that are easy to confuse with webdev: the servlet stops sending those headers if niagara.web.addExpires is set to false, or if its own file-servlet webdev flag is enabled. That is a different switch from the per-module one that makes requirejs fetch loose files.

The other half of a graphics budget is the artwork, and here the platform decides for you. The controller platform's distribution files name their VM as a compact3 ARM build, and that JVM's rt.jar can be counted: it carries zero classes under java/awt, javax/swing, javax/imageio and java/beans. The 64-bit JRE shipped in the same install carries 599, 1,951 and 89 respectively.

So nothing in a station on that platform can decode, scale, crop or recompress an image. There is no server-side thumbnail and no second chance: the render you engineer is the file every browser downloads, at the pixel dimensions and in the format you saved it. On a floorplan job that single fact usually outweighs every JavaScript figure above, because a render exported at 3000 px wide is a multi-megabyte PNG and the controller will not help you.

• Budget the framework, not just the drawing. The drawing is usually the small half.
• Turn the gzip switch on deliberately, tested on the controller, and check it again after an upgrade.
• Size the image once, correctly, in whatever rendered it.
• A chart is not free. Putting one on a landing view adds the chart and history bundles to every operator's first load of that page.
• Reuse view types. Payload is per view type and the browser cache is per file, so five graphics built from the same widget kit pay for the kit once.
• If a view genuinely has to be light — a wall panel, a phone over 4G, a guard's kiosk — the framework floor is the argument for serving a static page from the station's file space and keeping the station as the data source.