DBCC EXTENTINFO - unused pages in these extents (undocumented)
When it comes to resolving table fragmentation, the basic checkout you perform is to run DBCC INDEXDEFRAG or even run DBCC DBREINDEX statements.
As per the default configuraiton SQL Database Engine allocates a new extent to an allocation unit only when it cannot quickly find a page in an existing extent with sufficient space to hold the row being inserted. This allocation goes with extents on the filegroup using a proportional allocation algorithm, that means if that filegroup with multiple fils means one has two times the free space as the other, two pages will be allocated from the file with the available space for every one page allocated from the other file. This means that every file in a filegroup should have a similar percentage of space used.
The Database Engine uses the IAM pages to find the extents allocated to the allocation unit. For each extent, the Database Engine searches the PFS pages to see if there is a page that can be used. Each IAM and PFS page covers lots of data pages, so there are few IAM and PFS pages in a database. This means that the IAM and PFS pages are generally in memory in the SQL Server buffer pool, so they can be searched quickly.
So when the data is inserted, it will be organized contiguously wherever possible, if data is dropped there will be empty space that causes the fragmentation. Viewing the extent fragmentation scores for each object is one way, but another way is to view object fragment placements throughout the database. The standard procedure to defragment the indexes is to perform database reorganization methods as mentioned above.
On the basis of extent information you can use undocumented procedure DBCC EXTENTINFO that shows you one row of output for every allocation.
For further information on this extents information refer to Tony's post about: Extent Usage and Behaviours when using DBREINDEX and SHRINKFILE on his blog.