...

For performance reasons (and security) the spec file of a webcomponent should tell us what property should (and can) be sent to the server.

This page: Specification (.spec file) under Data synchronization we list the values the pushToServer attribute of a model property can have. By default the property is not allowed to be pushed to the server and therefore also not watched (by an angular $watch). Besides that you can also specify "allow" this also means that we don't add a watch on it, but the component pushes the value itself when it knows that it is changed. Dataproviders with the auto-apply directive work like that (Provided directives, filters, services and model values). Then the auto-apply directive will push data when the directive is triggered (dom onchange event). Components can also use the servoyApi.apply("dataprovider_propertyname") when the need to program it out. Using the above will not result in a loss of performance.

...

Above we talk about properties going from client to server, NGClient also provides a way to optimize the server to client communication of properties. Component developers can use this if you have a very complex component with many properties that must all be watched somehow (by a angular directive or directly as a $watch in code). In the link (or controller) function of a component directive where you get the servoy model pushed of the properties, you can add a special function on the model object:

Object.defineProperty($scope.model,$sabloConstants.modelChangeNotifier, {configurable:true,value:function(property,value) {
				switch(property) {
					case "borderType":
						$svyProperties.setBorder(element,value);
						break;
					case "background":
					case "transparent":
						$svyProperties.setCssProperty(element,"backgroundColor",$scope.model.transparent?"transparent":$scope.model.background);
						break;

...

If you enable that then all existing tableviews will be in readonly mode and the , except the forms/portals which have the ngReadOnlyMode set to "false". 

With the  APP_UI_PROPERTY.TABLEVIEW_NG_OPTIMIZED_READONLY_MODE all the textfield and typeahead fiels fields from tableviews will be replaced with a very light webcomponent. Buttons and Labels work the same so a click on them will fire the action. Currently only texfield and typeahead are replaced, others like combobox and datefield should still be done.

...

On the admin page under the ngclient settings there are 2 options is one option that can improve initial load performance when deployed:

servoy.ngclient.enableWebResourceOptimizer: This enabled the grouping of various js and css files, so the the browser only sees a few js and css files which are a combination of all the standard and component javascript and css files

...

.

...

Things to avoid

• Try to minimize the usage of controller.recreateUI(), Using the solutionModel is not a problem if you use it upfront to make all your forms the way you want. But try to avoid regenerating the forms all the time, this was quite cheap for the SmartClient, was already quite a bit heavier for a WebClient, but for the NGClient it has even more performance implications because quite a bit of logic needs o constantly be pushed to the client (besides a new template)
• Try to avoid a lot of nesting of forms, for example use a portal component instead of tabpanel that has a tableview form again. Or using a form for just a toolbar that could be quite an easy component.
• Try to avoid touching elements or forms when you are not (planning to) show them. Setting properties is not a problem, but calling api on an element of a form that is not shown means that we have to quickly create it (in a hidden div) so that the element is really alive.

...