Too Much PHP?

using in navigation

[old_expat]

I'm redesigning a site with about 700 mostly static .php pages, and I'm doing a lot of changes on the navigation. I use PHP includes to add the menus to the pages.

I have a horizontal menu with 5 main options .. then a sub menu (also horizontal and just below the main options) with sub options .. for each main option. Basically, I have 5 different PHP include menu files.

One thing I decided to do is a "you are here". So at the top of each page I added a:

$dir = "<span class=here>Option 1</span>";

Then in the appropriate anchot text position I added:

if ( $dir == Bangkok ) { echo "<span class=here>Option 1</span>"; } else { echo "Option 1"; }

The <span> creates a different text color, size and background color.

Now I'm thinking of doing the same thing selectively to different suboptions .. but I'm wondering if the extra functions will slow the load time.

In other words, how much PHP in static pages is too much.

[cameraman]

If you're performing dozens of queries on database tables with thousands of records or reiterative manipulations on large graphic files you might want to rethink things, but more than likely most of the stuff you come up with to do in script only takes a millisecond or two to execute. Compared to the amount of time it takes to transmit the content, in my humble opinion it's pretty much a non-issue.

Just for grins try using microtime() [us2.php.net] at the starts and ends of some of your scripts to profile them - it'll probably make you chuckle and resolve to write bigger scripts!

[vincevincevince]

It is almost always cheaper (when all costs are taken into account) to buy a faster server than to optimise code for speed.

[Swanny007]

If you're talking about 5 different directories, then it's not too much. I also use PHP includes for navigation and have some dynamic elements.

If you're not touching the database (it seems you're not) it should be pretty fast. Like cameraman said, time your scripts. Based on my experience I'm willing to bet the PHP dynamic menus on static pages will have very, very little impact to the script processing time. If you gzip or compress your content it will get to the client even faster. Do you have compression enabled?

If you take it a step further and cache the files (the menus are fairly static as well I assume) then that would make a difference as well.

[edited by: Swanny007 at 6:28 am (utc) on Mar. 7, 2008]

[old_expat]

Hi Swanny,

If you're not touching the database (it seems you're not) it should be pretty fast. Like cameraman said, time your scripts. Based on my experience I'm willing to bet the PHP dynamic menus on static pages will have very, very little impact to the script processing time. If you gzip or compress your content it will get to the client even faster. Do you have compression enabled?

1 - No database queries
2 - gzip is enabled
3 - altogether, a page has 6 includes

Right now everything runs pretty fast. I'm on a slow broadband connection in Thailand and my index page that has about a dozen smallish optimized images (60K?) loads in about 10 seconds .. in Opera with cache flushed. Server is a VPS in the US.

One page that queries a database and loads 30 records (descriptions and thumbnails) loads completely in about 12 seconds.

As I think I understand, the menu include is a process, then the 1st if statement (actually, 5 if statements .. one for each menu option) would be a subsequent process, then the 2nd level if statement (actually .. not sure, maybe 10 if statements) would be subsequent to the previous process.

If you take it a step further and cache the files (the menus are fairly static as well I assume) then that would make a difference as well.

I don't know how to cache files. And yes, the menus are static .. except for the is selection.