View Full Version : iframes

Business Attorney
04-22-2011, 01:50 PM
Frederick isn't the only one trying something new. I added iframes to my LLC site last night.

I have been listing some LLC books available through Amazon on my site. When Illinois recently passed a new law that would require any company with affiliates in the state to collect sales taxes on all sales to Illinois residents (including sales made directly or by non-Illinois affiliates), Amazon closed the accounts of all affiliates in Illinois.

Even though the links only brought in a few dollars a month, I didn't want to leave in links to Amazon. Call it principle or spite. With the Amazon ads, I had hard-coded links to specific products on each of my 80 or so pages. I thought this was a good time to change that. Since this site is written in html rather than php, and I don't feel like going through and converting it to php right now, I looked for another solution and came up with iframes.

Now I have one question and a request:

The question: Are there any drawbacks to using iframes? The Amazon ads were iframes, which is what gave me the idea in the first place. To reduce page loading time, I copied the images I needed and put them on my server to avoid one extra link out (times 5, on most pages). I also reduced the images to exactly the size I needed, to avoid unnecessarily large image files.

The request: Can some of you that use browsers other than Firefox and IE (Opera, Safari) take a look and let me know if the book ads in the left column look OK. I notice at least one difference between how Firefox and IE render the code - the "learn more" button is 2 pixels from the bottom of the frame on Firefox and 10 pixels on IE.

Any other comments are welcome. I know the color choice is a little loud and doesn't really go well with the other blues on the page, but I will deal with that at some point.

Here is a pretty typical page on the site: LLC Disadvantages :: Limited Liability Company Center (http://www.limitedliabilitycompanycenter.com/llc_disadvantages.html)

04-22-2011, 02:44 PM
It looks good in opera and FF. I have a big screen and a high resolution (I forget the actual resolution). The downside of iframes is SEO. The source on your website just shows the iframe link. If there is anything in there that you want for the search engines, they won't see it. The information in the iframe is probably on sites all over the web though, so it's probably not important.

04-22-2011, 03:41 PM
As far as the downside of using iframes, I think the only real issue is one of seo. Since the content in the iframe is on a different page the content doesn't get indexed. It shouldn't be an issue for you.

The ads look fine in Safari on a Mac. In Opera the Learn More buttons are too high and sitting on top of some of the link text. The space between them is gone. It looks like the buttons are using absolute positioning to set them at the bottom. That really shouldn't be necessary, though I assume you did that to keep all the iframes the same size and still have the buttons be at the bottom.

I did this really quick and didn't exactly test to see if it works, but you might try this on each of the pages within the iframe. As you can see I didn't fill in everything either, but hopefully it's enough to show you how I would have set things up.

If you can't get it to work let me know. I should be able to give you all the code with few more minutes of non-laziness. :)

<div class="book-ad">
<a class="book-image" href=""><img src="" alt="" /></a>
<a class="book-title" href=""></a>
<p class="author"></p>
<a class="action-button" href=""><img src="" alt="" /></a>

You don't need all those classes, but I added them so you can better identify what goes where. Here's some quick css.

body {background: #0ff}
.book-ad {padding:10px 5px; text-align: center; height:240px; width:120px; position: relative}
.book-ad p {margin-top: 0}
.action-button {position: absolute; bottom: 10px}

I think the Opera issue is that the button is being positioned in relation to something other than the whole ad. If you add position: relative to the ad div it should work. I also added in the width and height on the ad div since it doesn't look to me like Opera is honoring the width and height.

Business Attorney
04-22-2011, 04:25 PM
Thank you. I'll try these changes tonight or over the weekend.

By the way, I plan to clean up the code and move the css to my stylesheet when I am done. In the past, I have edited the stylesheet as I was making each change, but the thread on Frederick's css made me think I was doing a lot of extra running back and forth. Plus, the style sheet is long so it takes more time to get to the right place even once I am in the document. So last night as I was playing around with the margins, padding, font size, etc... I decided to keep everything in front of me until I have it just the way I want it. It sure seemed to allow me to work faster when I could make the changes in one document rather than in two. Thank you to Frederick for that!

Thank you both for pointing out the SEO effect. I agree that the content of these iframes is all over the web and is not important to my SEO efforts, but if I am tempted to use iframes in another context, the loss of SEO benefits from the content of the iframes might be important.

Business Attorney
04-22-2011, 04:45 PM
By the way, one more question. Last night I tried to make the background color an element of the div "book-ad" which seemingly should be the whole thing. However, it gave the background only to the divs book-image and book-title while the bottom part was still white.

When I move the css to the stylesheet, I am going to have to leave "body {background: #0ff}" in the html code unless I can attribute it to a div. What's up with that?

04-22-2011, 05:06 PM
The background color issue is also due to positioning the button When you use position or float and element you take that element out of what's called the normal document flow. You can style it so it looks like it's inside the book-ad div, but as far as the code is concerned it's no longer inside that div. As far as the code is concerned the book-ad div ends right after the book-title div.

If you want to prove this to yourself add

.book-ad {border: 1px solid red}

The bottom border will be just under the title and the button will be on the other side. In fact you'll probably notice the border matches exactly with what you saw with the background color. Adding borders like that is an easy trick to help debug things by the way.

Feel free to ask questions as you rework the site. FYI, the way I would go about building the site is first to develop a single page. I think the only thing that changes across your pages is the content area. So the one page is really to build the header, footer, and two sidebars and structuring the layout for the content. You might as well use real content from one of your pages for the content area.

Then you have boilerplate template for the entire site.

The next step for me is changing that single html page into php and moving header, footer, and sidebar code into their own files and replacing them in the template with one line of php to include those files. That's part of the beauty of working with server side languages as now all that boilerplate code sits in single files that are reused across the site.

You'll have some issues where seo is concerned though, if you try to do that now as all your urls will change to use the php extension. It's a solvable issue and probably not even a difficult one, though it could mean a dip in traffic for a short time while search engines reindex the site.

In your case if you want to stick with html you could copy that single page template over and over and just replace the content area on each page.

You can probably also use something called server side includes (SSI) I think your server is running Apache so you should be able to use server side includes. It's similar to the php include though it lets you keep the .html extension. You can also set up your server so when it sees the .html extension it still runs the code through a php parser before displaying it to the browser. It's another way to include php on each page and still keep the .html extension.

I don't know that you want to take on the challenge of all of the above, but once set up it'll save you a lot of time and effort later in maintaining the site. It's also not as hard as I probably made it sound, though there are a few potential show stopping gotchas along the way.

Business Attorney
04-22-2011, 06:12 PM
Steve, thanks for the explanation about the background color. I see why it has the effect it does.

What you suggested in building pages is exactly what I do, although over time my page template has changed slightly and, due to not having the site in php, those changes don't get reflected on all the changes unless I go back and make the changes on the existing pages. Sometimes I do that and sometimes I don't, depending on how much I care.

As for the php suggestion, I agree that it is the best choice and I would never write a site today without using php. I have converted several small hobby sites of mine to php from html and I do think I will probably do that with this one some day. My major hesitation is that my site has the #1 ranking in Google for literally dozens of competitive keywords and phrases. Even though I'm not selling anything, I really hate to jeopardize that. For my sites with little or no traffic, it wasn't a big deal to me.

I do have some search and replace software that makes it relatively less painful to make changes across all the pages. Once I got the ads the way I wanted them, it probably took me 15 minutes to change all 80 pages. Also, I make very few global changes. This was really an exception.

Even when I have to make mass changes by hand, I open about 20 windows in my code editor at time and then it is just ... "scroll down, highlight, control v, control s, close window; scroll down, highlight, control v, control s, close window; etc...).

Because I keep the pages virtually identical except for the content, I can probably make a change to all 80 pages in about 15 minutes. Spending 15 seconds making the change once to one php file would obviously be better, and if I were making global changes several times a month, even 15 minutes would add up. Before yesterday I made no changes at all to the site since November, so it is one of those things that falls in the category of nice to have but not critical. In fact, the effort to switch over would probably require more time than I would save at this point, since the site is fairly mature.

Some day when I get tired of the design, I'll use that as an opportunity to spur me to make the switch to php.

Live and learn!

04-22-2011, 07:23 PM
Glad I could help. I completely understand why you don't want to change the site to php now.

I'm not sure if you remember, but my site used to be on a completely different domain. A few years ago I decided it wasn't the right domain for me and so I moved the site to it's current location. That meant every url on the site was changing. I accepted there might be some loss, but thought it was worth it.

I set up 301 redirects for every url on the site so the old url would point to the new. Unfortunately since I was moving I changed things other than the domain. I changed the whole structure of the site, renamed files, etc. I had to map each url 1:1 old to new. (You'd only be changing the extension so all the redirection could be taken care of with few lines of code instead of all the 1:1 mapping)

Right after the move there was no change in search results. The old pages ranked, people clicked, and were taken to the new page via redirection. A month or so later traffic dipped, though not much. Not too long after that traffic was up across the board. People lose traffic because they fail to set up any redirection. As long as you set it up you really shouldn't see more than a temporary dip, though some links you've earned probably never get transferred to the new url.

Do keep in mind that using server side includes or setting your server to parse .html files as php means you can set up the template files and still have the pages be .html. The latter is relatively easy to do. It's a matter of changing one (maybe a few) lines of code in one of the Apache files. I think it's one you likely have access to. Even easier though you can add this to your .htaccess file.

AddType application/x-httpd-php .html

If your page doesn't have php in it then nothing happens. If your page does have php in it, then the php gets parsed the same way it would if the extension were .php. In effect you could keep your current .html urls and still use php on the pages.

Business Attorney
04-22-2011, 11:15 PM
Steve, in the html site that I switched to php, I did add a line in the .htaccess so that if anyone types a URL with the extension .html they auto-magically go to the .php page. Even if someone mistakenly types the html extension on a page that didn't exist as a page prior to the switchover, it still goes to the php page. The line of code was:

RewriteRule ^(.*)\.html$ http://www.mywebsite.com/$1.php [NC,R=301]

I honestly don't know what that does compared to what you suggested, but it seems to work. That particular site had relatively few hits to begin with, and I also added several pages at the same time I recoded it in php, so it is difficult to say for sure, but I didn't see a dip at all.

Maybe I am being too cautious. It really would be nice to have it in php.

As for the includes, I tried that a year or two ago it didn't work. I believe that the host for my site (1&1) did not have SSI activated on shared servers, and that I found that information buried in the FAQs some place. It may have changed by now.

04-23-2011, 12:00 AM
If you add the code below to your htaccess file your site should parse the .html files as php. This means you could change your page code to php but still use the html extension and have the page treated by the server as .php. This would solve any page renaming issues.

AddType application/x-httpd-php .php .html

04-23-2011, 12:21 AM
David the rewrite rule you posted is exactly what I was referring to with the single line of redirection. That would take care of everything with search engines as it does with real people typing the url or following links to the .html pages.

The code Bill typed and I typed above will let basically let .html files act like .php files so you can run php, but keep the .html extension.

Maybe you won't see a dip if you change things. It could depend on a number of things. It's something to be prepared for, but maybe won't happen. What you could do if you're nervous is convert a few pages at a time. Start building the php template and only use it on a handful of pages and see what happens. Start with the pages that don't get as much traffic and go from there. There's no reason you have to do everything all at once.

Business Attorney
04-23-2011, 01:10 AM
The solution you and Bill proposed seems perfect. Is there any drawback?

04-23-2011, 01:25 AM
Didn't see that VG had already posted that.. Remember that G never sees server side code. It can just be html or php generating html which is what wordpress does for example. As long as you aren't changing anything that goes to the browser G has no way of knowing how the html sent to the browser was produced. So that code will allow you to keep the same page name and the search engines will not see any change (other than changes in page copy etc). So no, I can't think of any negatives.

04-23-2011, 01:56 AM
I don't think there's any drawback. Like Bill said search engines don't see the server side code. Your php is parsed before it ever reaches a browser so no one including search engines sees the php. From everyone's perspective your page will simply be like any other .html page.

Business Attorney
04-23-2011, 02:26 AM
Thank you both. That was very helpful.

04-23-2011, 04:30 AM
Glad we could help. You know where to come if you have more questions.

04-23-2011, 08:47 AM
I'm rather surprised that iframes are still around - I first came across iframes it seems like 10 or 12 years ago. I think it was exclusive to IE in the beginning. I rather presumed it was what people are calling non-compliant code. So, iframes now work on all browsers and are not considered "old" and "dated" code? That's good.

Has anyone any idea about the speed of iframes compared to graphics? I mean, if I have content in a graphic and if I have that same content in an iframe, which would download faster into a webpage?

04-23-2011, 12:30 PM
iframes have been part of html for a long time. I think they were introduced by IE, but all browsers have been using them for as long as I can remember. They've been part of the html specification since html 4.01 I think.

I wouldn't say iframes are old and outdated. It's more a case of whether or not they're used well. iframes make sense when you need to load one web page inside your another. For example Facebook uses iframe code to let people embed many of the widgets you see on other sites.

You wouldn't use an iframe to load an image directly. iframes are means to load one document inside another so you'd be building an html page just to house an image and then call that document inside the iframe. That would ultimately be 2 http requests. One for the document inside the iframe and then one for the image that document has to call.

Chances are if you can accomplish the same thing without an iframe you're probably better off. I realize that's a pretty general statement. Take this whole thread though. What David wants to accomplish is done much better using a server side language like php. His use of iframes was because his pages as they existed couldn't run php. However the better solution to what he wanted to do was still to use php (or other server side language).

For most things iframes probably have more cons than pros, but they can be the solution to some problems.

04-23-2011, 12:46 PM
Iframes are placing a web page inside of your web page. Similar to an RSS feed in a way. If you want to put Amazon or ebay products on your web site I believe they give you an iframe link to their site. Harold would know more about how that works. You could also have say a table that is on your site and insert it into one of your web pages. Its an easy way for companies like Amazon to put their information on your website. They just tell you to use this one line of code and its there. Remember, everyone that has Amazon products on their pages isn't a web designer or programmer so its kind of idiot proof. The same sort of thing can be done with a line of JavaScript by the way.

Its probably possible to use php to convert an iframe to actual html on your site. I'd have to give some thought as to how to do that though. If I were to use iframes I'd look into this as it would help SEO and not really be duplicate content.

04-23-2011, 03:00 PM
If I remember correctly, Netscape did not support iframes. I found iframes quite useful for a whle, although I haven't used one for quite some time.

Also, I wasn't considering putting an image on a separate page and calling that page inside an iframe - that would obviously be slower. I was thinking of putting some text on a separate page and calling it in an iframe, compared with putting that same text on an image and calling that directly into the main page. which would be faster?

Amzon still support the old, pre-iframes ads. Amazon ads in iframes are a fairly recent addition. I don't like the iframe ads, actually, because you can't modify them. Using the direct html link allows the site owner to complile the ad to suit themselves. But you lose out on some statistical feedback.

04-23-2011, 04:55 PM
I was thinking of putting some text on a separate page and calling it in an iframe, compared with putting that same text on an image and calling that directly into the main page. which would be faster?

I'm not 100% sure what you're asking. Are you saying you'd be adding the image to the page in both cases. In one case you place some text directly on the image and in the other you place that text in a separate document, which you call in an iframe. Is that right?

If so then placing it on the iframe is likely going to be slower.

Adding the text to the image will add a little extra weight or size to the image file. That extra weight is probably negligible and won't change how fast the page itself loads. Adding the text to a separate document means adding the weight of that new document, which is also likely negligible as it's only a going to be a few words and a few lines of html code to form the document. However to call that document you need to make an additional http request through the iframe, which won't be negligible.

Amazon ads in iframes are a fairly recent addition.

The reason you now see Amazon using iframes for ads and Facebook using them for widgets is because it's easier for them and it lets them keep control over their content. It ends up being less code for someone to copy and paste and Amazon or Facebook retains complete control over how the ad or widget looks.

04-23-2011, 06:55 PM
1. iframe vs. image

I don't think you get what I'm asking, VG, but I'm not sure. Let me explain WHY I'm asking as that may make it clearer WHAT I am asking.

Say I have 200 words on a web page. Say an important keyword is "grass" and the word "grass" appears 6 times. Overall keyword density for 'grass' is 3.0% - not good, from an SEO view, but I want to keep the text readable and enjoyable for humans. Suppose there is a passage about grass which doesn't use the word grass - the passage discusses mowing and roots and fertilizers and the color and thatch and so on. Suppose that passage is 80 words.

If I take that 80-word passage and create an image of pure text, the SEs won't be able to read that passage (because it's an image) but my human visitors will. The fact that the words are an image will be transparent to humans, but the SEs will see only 120 words (200 - 80) with 6 instances of the keyword "grass" - a keyword density of 5.0% Now that's much better.

Alternative : put the 80-word passage on a separate html/text file and call that file into the main page in an iframe (which also will not be read by SEs but can be read by humans.)

Which would be faster - image presentation of the 80-word passage or the iframe presentation?

Is that a better explanation?

04-23-2011, 08:10 PM
Given that explanation Frederick, go with the iframe. It won't be seen by google so it is a reasonable way of hiding text and will be faster and look clearer than any image.

04-23-2011, 09:07 PM
As far as the speed question I can't give an exact answer it because there are more variables that are unknown. How big is the image file for example. There are also limits to how many connections the browser can make to the same domain at the same time. It could depend on where the iframe is located on the page in relation to other http requests.

It's easy to test though. Build the page both ways and see which loads faster. My guess is the iframe will load faster, but unless the image ends up being a huge file I doubt the speed difference will be all that significant.

However if your rationale for all this is the seo stuff you mentioned you're wasting your time.

1. Keyword density is irrelevant. The page would probably rank better for grass if it included the paragraph about mowing and roots. If you're spending time optimizing pages around keyword density you're wasting your time.

2. If you hide that paragraph then you prevent the page from ranking for words like mowing and roots, either or both of which might bring targeted traffic to a page about grass.

The fastest way to load the page would be for the text to be included directly on the page as text. Since having that content on the page is more likely to help how the page ranks than hurt it both the iframe solution and the image solution are completely flawed.

04-23-2011, 10:40 PM
Although I expected the iframe would be a little faster, as you both say, I figured the difference would be miniscule, especially in such small quantities of text as 80 words.

The idea might be useful where there is more text to mask than one short paragraph, but I'd likely save a few more miliseconds by getting rid of the tables! I did speed up one page noticeably, though, by splitting one div into two.


04-23-2011, 11:20 PM
The idea might be useful where there is more text to mask than one short paragraph

Can you provide an example where it might be useful to mask text longer than a short paragraph by using an iframe? Or even when it might be useful to mask just a short paragraph of text with an iframe?

04-23-2011, 11:22 PM
VG, correct me if I'm wrong here, but if an image and a text file are the same size the load time should be the same. The thing is images tend to be larger than text files. Realistically, text files are usually quite small. I would think the text file would load faster unless there are some server issues I'm not aware of relating to serving iframes vs images.

I was also curious what your word density response would be as I haven't seen anybody putting importance on that in the last several years.

Spider, as long as you are playing around with this stuff, you might want to consider doing what we were discussing with David above. One line of code in your htaccess file will allow php to work on your pages. This will allow you to do things like use includes for your header and footer which will speed up the site more. You may not want to play with that now, but keep it in the back of your mind for down the road at least.

04-24-2011, 12:20 AM
Can you provide an example where it might be useful to mask text longer than a short paragraph by using an iframe? Or even when it might be useful to mask just a short paragraph of text with an iframe?Er.... no. It just occurred to me that if one gets a 1 milisecond faster download on one paragraph of text, 100 paragraphs would speed things up by 100 miliseconds and 100 pages of 100 paragraphs .....

Why one might want to mask that much text, I have no idea, but then I have no idea why people listen to rap or opera but they do!

Bill - php? I'm just getting my head around css, and at least css has some semblance of English in it!

04-24-2011, 02:07 AM
Bill - php? I'm just getting my head around css, and at least css has some semblance of English in it!

Just trying to plant the idea in the back of your head. You have learned html. You are working on css. Code is code. And with php you can start just like you "reluctantly" did with css. A line of easy code here and there. Eventually it all clicks.

04-24-2011, 02:47 AM
correct me if I'm wrong here, but if an image and a text file are the same size the load time should be the same.

I think you're right. Above I was allowing for the possibility that you could create an image smaller than the html file. As far as I know time for both would still be an http request and the size of the files.

It just occurred to me that if one gets a 1 milisecond faster download on one paragraph of text, 100 paragraphs would speed things up by 100 miliseconds and 100 pages of 100 paragraphs

If you want to speed things up then just have the text be text directly in the html file. I don't really understand why look to iframes to make things faster. An iframe might be faster than turning the text into an image, but why would you want to turn the text into an image in the first place? What I was really asking in my last post is what would you want to turn a paragraph or more of text into an image. If there's no reason to turn paragraph(s) of text into an image then there's no reason to look for a solution to do the same thing in a different way, but faster.

php? I'm just getting my head around css, and at least css has some semblance of English in it!

Fair enough. FYI though, the php Bill is talking about is really just a single line of code. You wouldn't really need to learn php beyond the following.

<?php include "header.php"; ?>

header.php could also be header.txt or header.html. The file could be the same html and css you're using now. The php include simply says go get the file between the " " and place all its content here.

On your site most of your pages use the same header (the image of Houston and the text to the left, the red area to the right, and some navigation below). That could be turned into one file called header.php, which you then include at the top of all the pages that use it. If later you want to change the text or the image it's all in one file as opposed to being in several files across your site.

You don't have to do the above of course, but it does greatly simply developing a website.

04-24-2011, 10:25 AM
So one can mix the different codes? -- php, css, html all on one page?.... interesting stuff, this!

I have always been more interested in saving time on the downloading of a page than saving time on coding - so, another question. When a browser downloads php include "header.php"; does header.php go into cache?

You might not have noticed but on my index page I have the two header graphics that are used throughout the site as tiny images well below the fold. That serves to preload those heavy header images (24kb and 36kb) while the visitor is reading the first part of the page. That way, the banners appear instantly a secondary page is entered. Would that happen using php? I see no reason why php would be any different but just wanted to check.

04-25-2011, 12:02 PM
header.php wouldn't be cached. The include happens before the page reaches the browser so as far as people, search engines, the browser itself are concerned there's just one index.php page served which is all html (css and javascript).

I don't think your image solution is really ideal.. The caching of the images only works if someone visits your home page first, which isn't necessarily the case. The right way to do things is just make the images smaller (in terms of file size) on the pages where they appear. If after optimizing them as best as you can you still think they're too large, then you probably don't want to use the image at all.

04-25-2011, 12:48 PM
header.php wouldn't be cached...That's a shame - although I will certainly test it to see if the repetition of 'including' the header file for each page downloaded is slower or faster than downloading once to cache and drawing from cache for each new page.

The process I currently use works very well. I don't think it matters how small one makes the image, it cannot be faster to download it for each page than draw from cache for each page. As you have observed in this or other threads, the server call is what delays things and is subject to what else is going on.

You are right, though - this only speeds things up for subsequent pages. The first page is always going to have the delay loading data into cache. The trick is to have the delay take place after fast-loading data has been loaded and presented to the visitor, which is what I have done by placing the pre-load below the fold on my index page.

For the occasions that a vistor lands on another page, they will suffer the delay for the first header image, as you noted, but not the second (which delay will take place on the first page to need that other image.) I could preload the other header image, below the fold, on every page but I haven't got round to doing that yet. (Not sure I will - the amount of work may not be worth the small gain in speed.)

Interesting discussion.

04-25-2011, 01:49 PM
No need to test caching of header.php. It doesn't get cached. When the page reaches the browser there is no header.php anymore.

it cannot be faster to download it for each page than draw from cache for each page.

It isn't, but once someone reaches the 2nd page with the image the image has been cached. Your solution is to slow down your home page by adding not one extra, but two extra images to it. Your solution also assumes someone will first visit your site at your home page, which isn't necessarily going to be the case.

The two images you're using look pretty much the same. I think one is just a slightly cropped version of the other. Why do you even need both. Visitors to your site aren't going to notice the difference. Pick one, optimize it as best you can, and forget about the home page thing. That way the image is always cached after the first page is visited.

In your solution it's not only possible, but likely that someone will need to visit 2 pages before the two images are cached.

For the occasions that a vistor lands on another page, they will suffer the delay for the first header image, as you noted, but not the second (which delay will take place on the first page to need that other image.)

Yes they will suffer delay for the 2nd image. The image isn't going to find it's way into cache until a page is visited with that image on it. The only place you have both images is on the home page so unless someone visits that page first they're going to have delays on 2 pages.

Adding both images on every page makes no sense. I know you aren't going to take my advice, but you're going about this the wrong way. Pick one header image, optimize is as best you can, and then move on.

04-26-2011, 09:45 AM
No need to test caching of header.php. It doesn't get cached. When the page reaches the browser there is no header.php anymore...I understand that - but it would still be interesting to see how fast it is compared to a cached header.

...I know you aren't going to take my advice, but you're going about this the wrong way...Don't fret over it, VG. I offer advice that isn't accepted quite often. It doesn't mean the advice is universally wrong - it just means it's not right for that person at that time.

04-26-2011, 12:15 PM
And sometimes the right advice isn't taken because the person receiving it refuses to listen to it and assumes they know better. I've been on both sides of that.

04-26-2011, 02:37 PM
The person receiving the advice, not listening to it, actually does know better - for themselves at that point in time. The advice may be right, generally speaking - but we are not speaking generally. The advice - any advice in such a case as we are discussing - is specific advice to a specific person. Whatever the advisee thinks and acts upon is right - for them, at that point in time.

This is something that I have had to learn as a coach, and is one of the more difficult things to learn. No-one can know more about a certain situation than the person IN that siutation. There will always be things that the advisor doesn't know or dismisses, that could lead to an erroneous judgement. Only the advisee can know the whole story, so only their assessment can be right - for them, at that time.

04-26-2011, 02:51 PM
The person receiving the advice, not listening to it, actually does know better - for themselves at that point in time.

So you've never been around human being before? People often ignore advice that is better for them at that exact point in time. It's part of what makes us human beings. We're fallible creatures. There are times when people need to follow their own incorrect advice in order to truly learn from it. There are also times people simply refuse to see anything except from their own perspective and never learn anything.

Only the advisee can know the whole story, so only their assessment can be right - for them, at that time.

Part true and part not true. The advisee certainly knows things the advisor doesn't. The advisor also knows things the advise doesn't. Neither really knows the whole story. None of us even fully understands our whole story and why we do all the things we do.

As for the second part of your statement, knowing the whole story (assume that's truly possible) doesn't imply that your assessment of the story is right. Again we're fallible creatures who often make mistakes. Some of us are willing to admit those mistakes and learn from them and some will go to great lengths to convince themselves they didn't make those mistakes and so never learn from them.

04-26-2011, 03:01 PM
Think of it this way Frederick. If you have an html only web page, all the server has to do is find the file and send it to the browser. Load times are only controlled by the speed of the network which at best is about 1.2 Mbs. The size of the file including images will be the bottle neck for the load speed. When you have the server do stuff to create a web page like execute programs such as anything in php or other languages, the server has to do work and will take more time to generate the page to send to your server.

The thing is, if you have a good host, they will have a good server and this is done in milliseconds. The html page is then sent to the browser at that same 1.2 Mbs maximum speed, probably slower. You can't change the 1.2 because that is the speed of the network today. If you have 30 M download from your ISP, it doesn't matter. The network is 1.2. So the bottle neck is not the server processing time for the type of stuff you are likely to be doing. Case in point. I would bet that most web sites on the network are dynamic. If its a shopping cart, wordpress (blog), Amazon or my site, its dynamic. Go to Vangogh's site and compare the load time to yours. His is completely dynamic (wordpress) which executes a LOT of scripts before sending you a html web page. What will also slow your site down is if you are getting lots of hits. You don't.

So to recap, the ways to speed up your site are by keeping the actual html including images sent to your site as small as possible. Caching images in your browser will work either way. Worrying about a php include is a spit in the ocean. It will have no affect.

04-26-2011, 07:57 PM
Yes, Bill. I got all that. It's quite logical, really. But I'm not worrying about an include - I just remarked that I would want to test it, to see how fast it is. That's all. I'm not likely to do anything with it any time soon. Although, it looks simple enough, so who knows - maybe I will.

It seems from what you have said, php include "header.php"; will be slower, not faster ...
When you have the server do stuff to create a web page like execute programs such as anything in php or other languages, the server has to do work and will take more time to generate the page to send to your server.... even though that extra time is miniscule. Still, you are saying this php include won't make anything faster.

It also seems to me, again from what you have said, that the header graphic sent as a result of php include "header.php"; will go to cache.
Caching images in your browser will work either way.... because the php include command is converted to html at the sending server and comes down to my browser just like any other html page. ie. the header graphic will be img src= and will thus still go to cache.

Good! Thanks for your post.

04-26-2011, 11:51 PM
I hope you play with it a bit Frederick, for the following reasons:

1. As Steve said, it is a good way to organize your site in the same way as external style sheets. You only need to modify your header for all pages in one place.

2. Its easy.

3. It will get your feet wet (or at least damp) which can lead to pursuing more interesting things you can do with php or server side code should you so desire.

04-27-2011, 02:52 PM
Item 1. is a non-starter for me. Of course it has value for someone who has hundreds of pages and/or works on other peoples' websites, but I don't. I have 30 pages or so, and while each banner may look the same, every one is different. Sure, I could make them the same but I see no point - 30 pages is not an excessive number to change occasionally.

Items 2 and 3 are valid and may lead me to it in the future. Right now, learning css is enough.