Data traffic when used partialSubmit and composite component

Question

We have issue with performance of our application. We are using client STATE_SAVING_METHOD. I made some test on playground project and found the root cause are composite components witch we are using heavily.

Let me introduce my test case:

<h:form>
    <p:outputLabel value="Test input"/>
    <p:inputText id="testInputTextId"
                 value="#{customerController.someTestValue}">
        <p:ajax event="click" update="testInputTextId" listener="#{customerController.increaseValue()}"
                process="@this" partialSubmit="true"/>
    </p:inputText>
</h:form>
 <h:form>
    <c:forEach begin="0" end="5000" varStatus="loop">
        <!-- specific code -->
    </c:forEach>
</h:form>

CustomerController has just int member with method to increase its value. I've used c:forEach tag to simulate big view.

First example (without composite component) works as expected, just replace comment by:

<p:panelGrid>
    <p:row>
        <p:column>
            <p:outputLabel value="Label(A) #{loop.index}"/>
        </p:column>
        <p:column>
            <p:inputText value="Value #{loop.index}"/>
        </p:column>
    </p:row>
</p:panelGrid>

Second example is the same but mentioned code is in the composite component:

<ui:component xmlns="http://www.w3.org/1999/xhtml"
          xmlns:ui="http://java.sun.com/jsf/facelets"
          xmlns:p="http://primefaces.org/ui"
          xmlns:composite="http://java.sun.com/jsf/composite">

    <composite:interface>
        <composite:attribute name="label" required="true" type="java.lang.String"/>
    </composite:interface>

    <composite:implementation>
        <p:panelGrid>
            <p:row>
                <p:column>
                    <p:outputLabel value="Label(B) #{cc.attrs.label}"/>
                </p:column>
                <p:column>
                    <p:inputText value="Value #{cc.attrs.label}"/>
                </p:column>
            </p:row>
        </p:panelGrid>
    </composite:implementation>
</ui:component>

so replace comment by

<cc:testInputCompositeComponent label="#{loop.index}"/>

And now the test results:

Tomee 1.5.2 (JSF 2.1.29-03, PrimeFaces 5.2.3, JDK 64 1.7.0_67)

simple page:

• load page: 3,3 MB/12s
• paritalSubmit: 1,6 KB/400ms

with composite component:

• load page: 3,7 MB/16s
• paritalSubmit: 91 KB/1s

with facelet tag file:

• load page: 3,3 MB/16s
• paritalSubmit: 1,6 KB/10s

Tomee 1.7.1 (JSF 2.1.29-03, JSF 2.2.11, PrimeFaces 5.2.3, JDK 64 1.7.0_67)

simple page:

• load page: 3,3 MB/12s
• paritalSubmit: 1,5 KB/300ms

with composite component:

• load page: 3,7 MB/16s
• paritalSubmit: 90 KB/1s

with facelet tag file:

• load page: 3,3 MB/16s
• paritalSubmit: 1,6 KB/500ms

GlassFish 4.1 (JSF 2.2.11, PrimeFaces 5.2.3, JDK 64 1.8.0_45)

simple page:

• load page: 3,3 MB/14s
• paritalSubmit: 1,6 KB/4s

with composite component:

• load page: 3,7 MB/16s
• paritalSubmit: 90 KB/5s

with facelet tag file:

• load page: 3,3 MB/16s
• paritalSubmit: 1,6 KB/ 4s

So traffic is more then 50 times bigger when composite component is used. On local ENV it is not big issue but in the real world, where clients and server are far away, it causes that user needs wait 3-5 seconds for very simple operation where just one component should be updated based on user action. Notice that I'm basically do nothing with second form, just want to update component in first one.

Please, does anybody know if it is known issue? Or do I have something wrong? Thank you.

[Updated] Based on BalusC comment I made test also with Facelet Tag files and added results to original post.

Used latest browsers to measure: Opera, Firefox

There are some interesting numbers:

1. Traffic of facelet tag is low on Tomee 1.5.2, but time is 10s (We are forced to use TomEE 1.5.2 because of additional dependencies)
2. I've tested both JSF 2.1 and 2.2 on TomEE 1.7.1 and there were minor differences
3. GlassFish & JSF 2.2 & Facelet tag takes 4s, why so long. Tomee 1.5 is old, but GF is new with new libraries?
4. Question is why even if traffic is low, time is high (e.g. TomEE 1.5.2, & Facelet tag)