Things to look for in SSRS optimization include the following:

Long running reports
Which reports have the longest total duration?
If the TimeDataRetrieval is high, the data source could be a bottleneck, or the queries retrieve lots of data.  If the there is a high RowCount, lots of data is being retrieved – you might want to review the dataset queries.  If high volumes of data are grouped, sorted, and aggregated, high EstimatedMemoryUsageKB values for Processing are very likely.
 

Live Data or Snapshots
Reviewing the Source of report execution reveals if the report is Live (using real time resources) or Snapshot. If your reports don’t require real time access to data, they might be good candidates for history snapshots, configuring execution snapshots, and/or  caching.
 

Discover report patterns
Sorting by ReportPath and TimeStart may reveal interesting report execution patterns – for example, an expensive report that takes 5 minutes to run is executed every 10 minutes.

Most popular reports
Determine the most frequently generated reports. Analyze the results by Source type, and focus on live executions first.  Review and optimize the ones with the highest resource utilization (RowCount, TimeDataRetrieval, TimeProcessing, TimeRendering, EstimatedMemoryUsageKB, ScalabilityTime).
 

High Performance Users
Determine the users who hit your reporting server the hardest. Are they running Live reports or Snapshots? Analyze not only by number of executions, but also by resource utilization (ByteCount, RowCount, Total Execution Time, etc.)
 

High resource utilization
Review reports with the highest resource utilization, particularly those with EstimatedMemoryUsageKB > 50000, ScalabilityTime > 10000.  Frequent high values for ScalabilityTime might also point to general high load on the report server, which causes memory pressure for large requests.   

Number of bytes/rows returned
Review reports with large numbers of rows returned (RowCount). Are they viewed interactively (Format = RPL, HTML4.0), and or exported to XLS or PDF?  If yes, do these reports aggregate data, or just provide a list of several thousand pages of detail data and users only look at the first few pages? If you’re aggregating in the report, it might make more sense for performance to move the aggregation to the query in your dataset.
 

Large report outputs
Are there reports with very large outputs (ByteCount)?  You might want to investigate e.g. reports with >100 MB PDF output.
 

Report Health
Reports with Status != rsSuccess might indicate missing subreports, expired stored data source credentials, subscription delivery errors, invalid report definitions, etc.

 

Of course, the best way to analyze your SQL Reporting Services execution log data, is with SCRUBS.