btw, includes are linear in php, so if one include takes 10 milliseconds (random number there), then 2 will take 20 milliseconds, 10 will take 100 milliseconds and 1000 will take 10000 milliseconds.
Usually, what you "should" do is make your includes the way your doing them, and then cache the page / block of the page that doesn't change.
Example for some page:
> Means include
>> Common header html includes
> Left Menu Bar*
>> User Info+
>> Menu Items
>> Quick Search
> Right Content (search results)**
>> mini profile view+ (in a loop 20 times)
>> Common footer links
>> means include in my include
* means you cache the HTML after the includes in that block
+ means you cache the HTML for that block (can be used my multiple users)
** means you need some special cache - you cache the page and pagination, and insert the search results in it, then cache everything again.
The idea is this:
- The first time a page gets loaded, all includes happen (31 includes in that example, + lib includes)
- The second time a page gets loaded, you won't have to use all the includes you included the first time, since they didn't changed. So you just serve a cached version of the page (no html include, no db queries no nothing, just your main lib include) So this time you have just the lib includes.
- If you see the search results page again, but with different results, you have most the page cached, so all you need to include are the results, so you end up with 20 includes + lib includes.
Thing is, this will speed up your stuff, but chances are there 1 million other things you can do to speed it up with allot less work / minor logic change.