Catch yourself implementing a Concrete class (including Work classes) that contain Page Lists that will progressively grow larger (i.e. more than 100 elements of moderate- or large-sized pages) over the lifetime of the case. These will progressively take longer to load, and to save, which in turn means for lock-enabled classes like Work classes, the locks are held for longer. Even if end-users can tolerate something taking 2 seconds to load that would normally take less than half a second, high-throughput processing scenarios become materially impacted by the increased load and save time. Background processing is further impacted by locks being held for longer when multiple events are queued to be processed for the same case.
An alternative is to 'externalize' the class of data in the Page List to a distinct Concrete type, saving those instances separately from the composing class. Then define the Page List property to be a Refer-to-Data-Page auto-populate Property, looking up that Page List of instances only when they are needed.
Adding instances to the Page List then becomes a case of saving new instances of the externalized Data Class, without needing to lock, open or save the work item that references them. Savable Data Pages can now help orchestrate the saving of those instances at appropriate process milestones, or from background processing.