Content Search Webpart vs Content Query webpart RRS feed

  • Question

  • Hi All,

    In SP2013, team has introduced Content Search Webpart that is used to render the content dynamically. In SP2010, Content query webpart is used for this purpose. Only change in content search webpart is, it provides control, group & item templates to determine how it will look like. one more change i suppose content search webpart support cross site publishing.

    have anyone noticed any other change?

    Regards Amit

    Tuesday, May 14, 2013 6:21 AM

All replies

  • Hello Amit KM,

    Please talk about SP 2010 questions only in this forum. People may not aware about SP 2013 features here so i would suggest you if you have any question related to SP 2013 then post it in SP 2013 forum only.

    I will also move this thread to SP 2013 forum (i already moved your one thread before writing this). Now if you again post any SP 2013 question here then i will delete that.


    Hemendra: "Yesterday is just a memory,Tomorrow we may never see"

    Whenever you see a reply and if you think is helpful, click "Alternate TextVote As Helpful"! And whenever you see a reply being an answer to the question of the thread, click "Alternate TextMark As Answer

    Please feel free to unmark answer if does not resolves your problem.

    Tuesday, May 14, 2013 6:29 AM
  • oops, i didn't notice it. my apology.
    Tuesday, May 14, 2013 6:38 AM
  • Content Search webparts are more powerful and flexible than content query webparts.  Besides being able to pull information from anywhere that is crawled, you can also use refiners and multi-level sorting.  I saw a solution the other day where someone crawled the birthday field in the user profile service and then used the Content Search webpart to show all the people with upcoming birthdays.  And like you mentioned, Content search webparts use display templates which are way easier to customize than the XSLT that content query uses. 

    The only drawbacks that I've found with the content search webpart are that they currently are only available with On-Premis installations.  They have a lag to them when editing, essentially after you setup the content search webpart and click Apply in the webpart properties, it then takes 15 seconds or so for the page options to render including the Save button for the page.  And finally new items won't be displayed until they are crawled, where content query webparts will show new items instantaneously.

    Nick Hurst

    Tuesday, May 14, 2013 1:41 PM
  • Hi Nick,

    I am wondering why this webpart uses the crawled db, can't it just fetch the data directly, the way content query do, instead of using the search(crawled data).

    Regards Amit

    Wednesday, May 15, 2013 2:55 AM
  • I imagine they limited it so they could optimize the query options and menu's.  I think the question for me is why didn't they improve the content query webpart?  The only good news is there were already quite a few 3rd party content query type webparts for 2010, and I would imagine that many more solutions will be coming to the SharePoint 2013 app store. 

    Nick Hurst

    Wednesday, May 15, 2013 3:08 AM
  • also i am wondering what is the core role of crawled db here, does this webpart only fetch the link from crawled db and fetch actaul content from source itself or both(link & content) are fetched from crawled db.

    Regards Amit

    Wednesday, May 15, 2013 3:13 AM
  • well, there is a huge performance impact. CQWP will use either local cache or drill down through the structure (iteration is not a fastest thing in the world) and Content Search Web Part will use the search index for querying which is a way faster. Also, CQWP is limited to the single site collection, Content Search WP isn't.

    Basically, a choice of using a CQWP or a CSWP is a matter of living with the drawbacks ("it always depends, right? :) ").  CQWP will always the read actual data but it will put web frontends and SQL server under quite some load. CSWP is faster and requires less ressources; however, you'll have to live with data freshness defied by your crawl schedule.


    Wednesday, May 15, 2013 10:45 PM
  • Hi Alek,

    In case of CSWP, as content is coming from search index instead of content source what if we want to display the columns of list/document library that are not crawled.

    Regards amit

    Thursday, May 16, 2013 2:35 AM
  • My understanding is that it simply wouldn't work.  In my experience in teaching and using this feature, if you have added content in between crawl cycles and you try to utilize the CSWP then the content doesn't show up until the next crawl.  I don't make any changes and either manually initiate a crawl or just wait and then content appears after the crawl finishes.

    From what you are saying, if you do not crawl a list/library then you cannot take advantage of CSWP.  For a single list/library I think that the CQWP will work very well without putting too much strain on your hardware/VM.

    Friday, July 19, 2013 1:44 PM
  • I have two subsites under 1 top level site SharePoint 2013 online. For example, Site A has a list B. In list B, it has a drop down menu called Team Owners: CBS, EBS, Management and SFZ.

    My co-worker wants me to build something on subsite B called CBS. And this app has to filter everything from Team Owners CBS.

    I do not know how to do it. Please help as soon as possible.




    Thursday, December 24, 2015 10:37 PM