How to fix: Slow page loads when opening pages that have custom new item forms [DataFormWebPart] for large lists [around 6000 items]


After creating a custom new item form for a SharePoint list having a very large number of items, the new item form will take a very long time to load at browse time. There are no error messages.


The issue happens because the default value "0" of the ListItemID parameter of the data source in the new item form causes a very resource intensive query to be run at page load time. This causes the perfiormance issue during page load. The reason we include all those parameters is to make the datasourcecontrol extensible in design time. The datasourcecontrol can be used by another webpart or view on the page and it could still work. If you don’t need those scenarios, then removing them should still work in runtime.


  1. Using the "Common Data View Tasks" pane for the new item form, click on "Parameters" to open the "Data View Parameters" dialog box.
  2. Select ListItemID and delete "0" in the Default Value input box.
  3. Leave the default value of ListItemID blank and click on OK.
  4. Save the page, and browse to it.

Additional Advice / Tip:

When working with large data sets you may experience other slowness in SharePoint Designer while working with data views. In those situations, you may see SharePoint Designer as non-responsive for several seconds after changes are made and / or may seem very sluggish once it's responding. Quick fix is to click "Common Data View Tasks" pane for the data view, and select "Show with sample data". Instead of showing all of the data from the data source, it limits it to 5 sample items.

Comments (13)
  1. Kosher says:

    That doesn’t work, among many other things.  I tried the steps on the new item form, removed the 0, and the form takes forever to load still.  I have lots of form fields with dynamic data but this is nuts.  How in the world is it so slow?

  2. Mark Arnold says:

    I think I found something that can help further.  It looks like when you close a webpart through the browser, the webpart will still hang around in the background AND query list data even though it’s not visible in the browser.  I discovered this in SPD when I opened the default.aspx and found HUGE amounts of discussion list data being returned from previous webparts that I’d added, then closed thinking they were gone.  They appeared greyed out in SPD because of their closed status.  When I deleted all these lingering webparts my page loads considerably faster in SPD and the browser.


  3. erugalatha says:

    I’ve tried lots of things to speed up SPD including your steps above.  Nothing works – it is just dog slow! Microsoft need to take another look at it as sometimes it is unusable even with a list with a small number of rows.

  4. Dustan Archer says:

    Works great for me. 3 of the 33 fields are multiple value choice fields with 2133 records at this time. Was taking 1 to 5 mins to load. Now the load times are instantaneous. Thanks again.

  5. Oleg says:

    Its open library with 10 items around 5 MINUTES!!!!


  6. wattsonlosen says:

    works fine for me also.

    thank you very much

  7. Jesse McNulty says:

    Seems like if you are using a data source such as Web Service no matter how many balues are displayed the page is very very slow.

  8. michmon says:

    @Jesse: it’s not so much how many values are displayed, as it is the number of items returned. If you apply XSLT filtering, it will take the full set of items (potentially thousands) and then filter. Alternativley, if you filter at the datasource level, and limit the number of items actually returned, you should see a perf increase.

  9. Katie says:

    How do I access the Common Data View Task in order to edit the parameters?

  10. Bazin Makonnen says:

    Open up your ASPX page, click on your custom form and then Click on the Common Data View Tasks button in the top-right hand corner.

    Bain Makonnen

  11. Jeff Barton says:

    I’m having this problem with OOB pages i.e. the list form web part and not the data form web part.  The ‘edit parameters’ option does not exist for list form web parts.  Any ideas?

  12. Jeff Barton says:

    I narrowed my problem down to the multi-valued lookup column in my list.  If I uncheck the option to "allow multiple values" for that column, the problem goes away.  I’ve scoured the interweb to find a solution to this, but all I find is advice on filtering views/webparts, using folders to partition the list into chunks < 2000, and indexing frequently used columns.  The latter doesn’t work on this breed of column, and indexing the column that it points to doesn’t help either.  Any advice or findings regarding the multi-valued lookup column and large lists would be greatly appreciated.

  13. Srikanth says:

    Hey michmon; this worked for me thank you somuch

Comments are closed.

Skip to main content