# K2 Form Performance Checklist

A field checklist for diagnosing and fixing slow K2 SmartForms. Work it top to
bottom the next time a form drags. Companion to the article
"Why Your K2 Forms Are Slow".

Version 1.0.0
By Mustafa Al-Barghouthy (Mus)

---

## Before you change anything: measure

- [ ] Reproduce the slowness somewhere close to production, not just on a fast dev box.
- [ ] Open browser devtools on the Network tab, clear it, and load the form.
- [ ] Record the total round-trip time so you can prove an improvement later.
- [ ] Remember that classic SmartForms batches calls into a few AJAX posts. For
      per-SmartObject detail, turn on server-side runtime logging or use the
      SmartObject call trace.

## Separate a slow service from a slow form

- [ ] Execute the suspect SmartObject in isolation (SmartObject Service Tester on a
      dev box, or via management and SQL tooling) and time it.
- [ ] If one call is slow on its own, fix the data: a missing index or unfiltered
      query for a SQL-backed SmartObject, or the remote system for a
      REST, SharePoint, AD, or custom broker.
- [ ] If the call is fast on its own, the form is multiplying it. Fix structure, not
      the database.

## Stop calling N times (the N plus one)

- [ ] Look for a rule that loops the list editor calling a Load method per row.
- [ ] Look for a per-row expression resolving a label through a separate SmartObject.
- [ ] Look for a repeating section with an explicit per-row data binding.
- [ ] Fix: return the related field in the same result set (join at the source), or
      load the lookup once into a form-level control and resolve display values in memory.

## Filter at the source

- [ ] Compare the row count in the response to the row count on screen.
- [ ] If the source returns thousands and the user sees a handful, the filter is in
      the wrong place.
- [ ] Prefer a SmartObject method input that maps to a WHERE clause, so it filters at
      the database.
- [ ] Treat a SmartForms-layer filter as a fallback: the broker may already have
      pulled the full set.

## Lighten heavy controls

- [ ] Cut List View columns to what the user actually reads.
- [ ] Cap rows. Use server-side paging where the control and SmartObject support it.
- [ ] Verify the paging happens at the source, not client-side over a full result set.
- [ ] Avoid editable List Views bound to unfiltered, unpaged sources.

## Tame rules that fire on everything

- [ ] Audit work wired to "When the View executed Initialize" and control-change events.
- [ ] Make work conditional: a rule should act only when its input actually changed.
- [ ] Defer data for views and tabs the user has not opened yet.

## Prove it

- [ ] Change one thing at a time and re-measure after each change.
- [ ] Keep the before and after numbers so you can point at each second you removed.