Very slow ajax loading times?

I've noticed this as well when just using 1 field collection and add 10 or more field collection items. Adding more items will result in freezing FireFox for a few seconds before finishing.

I am using my local development environment to recreate this.

Guys, I use Firefox all day every day unless I absolutely can't or I need to test something, so don't take this the wrong way, but it really doesn't deal with running out of memory very well. I'm not suggesting this as a 'real' solution to this AJAX problem, but if you need something to do your work, try the form in Chromium.

hi,
has anyone managed to solve this?

i want know the reason two ,i found it is very very long time(about 2 minutes) to see the popup panel

It would be great if we can fix this ajax loading problem.

I'll mention another workaround that may help in the meantime: If you change the field formatter for the field collection field to list or 'field collection items' you should see links when viewing the node that can take you to a page to add or edit a single item at a time.

I'm currently experiencing similar symptoms as well. I have custom code formatting widgets and themes for custom fields that change based on user input and various scenarios. AJAX is basically non-functional with major delays. I've checked to make sure that my code is not firing multiple times or bogging down resources. The response time from the server is fast. It is the browser download time for the AJAX response that is ridiculously slow. I will continue Googling for more info, but currently I'm at a loss. In dozens of sites and custom forms, I've never experienced this. I think perhaps this can go on the ajax page as well. Thanks for any insights!

Update: I removed all dpm() calls that were touched by my ajax response and that fixed it. I'm still a little confused as to why that would slow down the browser so much as I dpm bunches of stuff with and without ajax all the time and never run into any issues, but judging from the results, it definitely was the problem causer. I can see though that some of the DPM calls were pulling through a good bit of information, but I don't think it's five minutes load time of information!!

Hi guys, i have the same problem too. i use field collection with field collection table and after insert 20/30 items, field collection slows down considerably.

I found this article but I have not tried yet if it works: http://drupal.stackexchange.com/questions/52051/slow-add-another-item-wi... and https://www.drupal.org/node/1394184#comment-8252701
If anyone can try the solution and see if it works.

/**
 * Implements hook_field_attach_form()
 * We are looking at our t2imageclient widget after the "Add another item" has been added.
 * We are going to alter the behavior of this button, to let us add as many new entries as
 * we want.
 */
function YOURMODULE_field_attach_form($entity_type, $entity, &$form, &$form_state, $langcode)
{
  $options = array('language' => field_valid_language($langcode));

  // Merge default options.
  $default_options = array(
    'default' => FALSE,
    'deleted' => FALSE,
    'language' => NULL,
  );
  $options += $default_options;

  list(, , $bundle) = entity_extract_ids($entity_type, $entity);
  $instances = _field_invoke_get_instances($entity_type, $bundle, $options);

  // Iterate through the instances.
  $return = array();
  foreach ($instances as $instance) {
    // field_info_field() is not available for deleted fields, so use
    // field_info_field_by_id().
    $field = field_info_field_by_id($instance['field_id']);
    $field_name = $field['field_name'];

    //If we are looking at our field type and specific widget type, and we are multiple entries
    if($field['type'] == 'TODO_PUT_YOUR_FIELD_TYPE' && 
      $instance['widget']['type'] == 'TODO_PUT_YOUR_WIDGET_TYPE' && 
      $field['cardinality'] == FIELD_CARDINALITY_UNLIMITED)
    {
      //Check just in case the button is here, and add another #submit function
      if(isset($form[$field['field_name']]['und']['add_more']))
      {
        $form[$field['field_name']]['und']['add_more']['#submit'][] =
          'YOURMODULE_field_add_more_submit';
      }
    }
  }
}

/**
 * Our extra "Add another item" #submit handler. Copy pasted the field_add_more_submit
 * function, altered to change the nb of widgets based on our conditions.
 */
function YOURMODULE_field_add_more_submit($form, &$form_state)
{
  //Put here the condition for altering the nb of widgets, e.g. it could be based on a 
  //POST value
  if(true /** TODO */)
  {
    $button = $form_state['triggering_element'];

    // Go one level up in the form, to the widgets container.
    $element = drupal_array_get_nested_value($form, array_slice($button['#array_parents'], 0, -1));
    $field_name = $element['#field_name'];
    $langcode = $element['#language'];
    $parents = $element['#field_parents'];

    // Alter the number of widgets to show. items_count = 0 means 1.
    $field_state = field_form_get_state($parents, $field_name, $langcode, $form_state);
    //Here as an example, I am adding 10
    $field_state['items_count'] += 10;
    //But you can just fix the nb of items, like 5
    $field_state['items_count'] = 5;
    field_form_set_state($parents, $field_name, $langcode, $form_state, $field_state);

    $form_state['rebuild'] = TRUE;
  }
}

I use this method, it saves some time in that if you want to add 6 new field sets to your field collection you can choose 6 in the dropdown... But it will still take a while, and take longer if you need to do it to multiple fields.

Field collections in general don't appear to be a good approach unless you only have a small number of field collections. I'm looking into alternatives myself. This code should be committed to field collections regardless.

Hi guys,
i have a fieldcollection field in a entity form type with FieldCollection Table display, and its set to unlimited value. In this field collection there are 5 fields(One field is entity reference autofill type).

After some research I found that after insert 20/30 items, field collection slows down considerably. Infact, in my entityform, after 40 items of fieldcollection, increases the data loading time.

I use this method but it does not solve the problem. After adding 20 items, it takes long time to fill the fields.

Now I do not know if it is a field collection problem or ajax.

Slow loading of field collections can be caused by entity reference fields. In our case we resolved it by changing the field from select to autocomplete, and not using views for selection or display.

Xhprof can help with narrowing down where the bottleneck is.

I did some profiling on adding new items to a field collection field that has many items. It seems the browser is getting the response quickly and the javascript itself is not taking long to execute but most of the delay is when the browser is recalculating the styles and layout for the page. This was true for firefox which took about 10 seconds and chrome which took about 2 seconds (slow for chrome compared to adding items to the blank form).

I'm not sure what the next step is yet but I found some information I believe should be helpful.

https://developers.google.com/web/fundamentals/performance/rendering/

https://developers.google.com/web/tools/chrome-devtools/evaluate-perform...

For those of you using the widget from Field Collection Table try changing it back to Field Collection Embedded and see if that makes a difference. For my test case I just tried the Field Collection Table widget and found that the response time was a lot slower.

I have to say I was very hopeful that it was the table widget that was responsible. Unfortunately it doesn't seem to be the case. I have a content type with 30+ field collections. I changed them from the table widget to embedded and the speed is the same.

I believe the main issue is that the whole form is posted to the server when you add a new row/set to a field collection. I'm not sure why the whole form needs to be posted, but it's happening.

During the post a lot of other page activity is recorded in the browser. I'm not too familiar with the debugging console, but as jmuzz has pointed out, there's a lot of style and layout recalculating going on...

I'm trying to find a solution but I can not. Fieldcollection is a beautiful module, but this limitation is very annoying.

I tried to use Multifield & MultifieldTable module but has not support for rules yet: it's not possible to get subfields value.

Another workaround is to disable javascript in your browser. The page will reload and send you to the top when you add another item but it should be much faster.

The javascript is an extra layer of functionality built on top of that so that may help explain why the button submits the whole form.

I looked at the actual response from the ajax post and most of it is the dropdown boxes that appear for each row if you hit "Show row weights" at the top of the widget. It sends one of these dropdowns for each row and they each have 2x the number of options as there are field items (positive and negative numbers). I tried this with a text input instead of a field collection and the row weights are in a text box (when they are visible) so the response is much smaller. I did this with an unlimited cardinality text field with 200 entries and the response time was quite good so the way the row weights are represented on the form may be the key to speeding this up.

I tried it with an image field too because it also uses a dropdown for row weights when cardinality is unlimited and I saw a similar slowdown with a large number of items. I think switching the row weights to a text box if possible could make a big difference.

The way row weights are represented on the form depends on how many items there are, not what kind of item. If there are less than 100 items the row weights will be in a dropdown. I did some more testing with this on a text field and there was some slowdown with about 95 text items but once it went over 100 it switched to text box row weights and sped up considerably. It went from one to the other during a single node edit just using ajax functionality.

Still hoping there is a way to get it using text boxes when there are fewer items.

In the meantime, here is a hack that seems to help:

Open up /modules/system/system.module and change

define('DRUPAL_WEIGHT_SELECT_MAX', 100);

to

define('DRUPAL_WEIGHT_SELECT_MAX', 1);

If anybody tries this please let me know if it does / doesn't make a difference.

Edit: A variable can be used for this too so instead of hacking the system module you can add the following to your settings.php:

$conf['drupal_weight_select_max'] = 1;

Please try this patch and let me know if it makes a difference.

I added the system config variable to my settings.php ($conf['drupal_weight_select_max'] = 1;) and I applied the patch you suggested.
My Field collections all have unlimited cardinality.

It's definitely faster, it seems to have shaved off 20% of the time. But it's still too slow to use in production. Is there a reason it posts the whole form when a new field collection row/group is added?

@AgentJay Thanks for trying it.

I explained a bit about the javascript in #18. Keep in mind field collection doesn't have custom javascript to manage these forms. That functionality comes from core and it's the same javascript that's used whenever there is a multiple cardinality field. In theory it could be replaced by something in field collection but I don't know if that's feasible.

As far as I can tell the post and reply aren't what is taking up most of the time. The slow part is the step after it has received the reply and it is replacing the current field collection widget html with the new state.

@jmuzz I have tried your solution too. As @AgentJay says, has improved a little bit but it's still too slow to use in production.

Now I can put 50 items a little faster. But in my site, users can add more than 100 items at a time.

I have tried it with my fieldcollection: FIELD1(entityreference with autofill) - FIELD2(is filled in automatically from the selection FIELD1) - FIELD3(text list with only 2 value) - FIELD4(Term Reference with only 5 value) - FIELD5(text list with only 5 value).

I found that other modules have some similar problems. Prospects for seeing this fixed in 7.x are not promising. I'm going to postpone this for now until somebody gets an idea about how this can be solved.

My suggestion is to use the hidden field collection widget and the add / edit / delete links on the view pages if possible.

#1350820: Features form very slow with large set of components

#2187399: Significant performance deterioration with more items (entities) added

http://drupal.stackexchange.com/questions/27971/horrible-frontend-perfor...

http://drupal.stackexchange.com/questions/106123/how-to-speed-up-node-ad...

Hi,

This is a great module but it simply does not scale well. How can we fix it? I'm willing to pay money for some development to make FC scalable. What would this effort cost? Please contact only if you have serious Drupal credientials.
Thanks, JIm

@jwilde,
did you find a solution?

Thanks

@jmuzz I can confirm that paragraph module has this "bug" too.

After 30/40 items performance go down...

Thanks @j.branson!! Your solution in comment #8 solved this for me. My delays in adding new rows in field collections were of the "go get a cup of coffee and come back later" variety. It now comes back within a second or 2 with no changes other than commenting out dpm statements.

@mgmd can you explain how to do please?

@jmuzz i have disable Javascript in my browser and can confirm that with this solution adding fieldcollection time is very fast, but without javascript enable there are many modules does not work: "entityrefrence", "accordion_block" and much more...

Maybe you hit the problem as explained in #18 #19 #20 and we are close to the solution. I'm trying too.

Thanks a lot.

See how I solved this problem

I also had the same problem with all of you. With many items inserted the form in edit mode became slow and crashed.

I got around this problem by telling my users add items in the node view mode only, not more in the edit mode.

In structure >> Content types >> Manage Display >> Full View I defined the settings of the field collection item to display 'edit', 'delete' and 'add' buttons.

And then I instructed my users to add, edit or delete field colletion items only in the node view mode because when you enable these 3 buttons above to add a new item drupal loads on a new screen only the fields of the respective field collection and not the whole form.

So the problem of slowness does not occur and users can add items unlimitedly