If CQ5/AEM 5.6 or 5.6.1 is being used as brochure style heavy content specific solution i.e. digital platform where number of content are like 50 k or more, CRX repository file size would be like 100 GB or more over the year.

You may face slowness when content author are accessing website console or you may find CRX repo size 5or 10 times bigger than what it is expected. Adobe provides/recommend repository optimization  as routine jobs weekly or bi-weekly to keep check on system health.

https://helpx.adobe.com/experience-manager/kb/performancetuningtips.html.

Problem We faced in our environment.

1. Production is non-cluster in Author and Publish both. Author instance  ideal size was reduced to 25 GB from 125 GB after series of optimization overnight.
2. Content author were having slowness in web site console  navigation when node has sizable content on first level i .e 10+ node.

That slowness was not related with repository size by the way. One of the publish agent configuration content was causing that slowness to prove it when agent was disabled slowness disappeared.
Steps to reduce Repository.

1. Set CRX Search Index’s resultFetchSize & cacheSize param

C:\CQ5-Author\crx-quickstart\repository\workspaces\crx.default\workspace.xml 
<SearchIndex class="com.day.crx.query.lucene.LuceneHandler">
<param name="path" value="${wsp.home}/index"/> 
<param name="resultFetchSize" value="50"/>
<param name="cacheSize" value="100000" />
</SearchIndex

2. Cache Tar PM index

C:\CQ5-Author\crx-quickstart\repository\workspaces\crx.default\workspace.xml 
<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager">
<param name="indexInMemory" value="true" />
</PersistenceManager>

3. disable clustering

C:\CQ5-Author\crx-quickstart\repository\repository.xml
<Cluster>
<Journal class="com.day.crx.persistence.tar.TarJournal"/>
</Cluster>

Once above configuration related changes is completed then perform these activity provided in AEM from system/console JMX tools.

1.Purge workflow instance data /system/console/jmx and then choose com.adobe.granite.workflow “Maintenance” and choose purgeCompletedWorkflow.
2.Perform Tar Index merge it might take 10 to 20 minutes…please check error.log  choose repository under /system/console/jmx and tarIndexMerge.
3.Perform tar optimization manually that might go overnight under repository under /system/console/jmx by clicking “startTarOptimization“.
4.Perform Step 2 again that might go for 10 to 20 minutes again.
5.Finally run DataStoreGarbageCollection under repository /system/console/jmx… and finally you will see disk space used is reclaimed.