What is the best way to include the same content on multiple web pages? (e.g. SSI, PHP, Javascript...)
August 30, 2008 1:15 PM Subscribe
What is the best way to include the same content on multiple web pages? (e.g. SSI, PHP, Javascript...)
There are many times when it is very handy to include the same content on many web pages. For example, a navigation menu, banner, logo or footer. If a site is made up of 50 pages then it is much more convenient to make 1 change than 50.
I'm currently aware of 3 methods of doing this. Server Side Includes (SSI), PHP's include method and Javascript's document.write.
What are the advantages and disadvantages of each of these methods? Which of them is the fastest to the end user? Are there any better solutions out there?
Note: I'm not asking about template options like that offered by Dreamweaver.
There are many times when it is very handy to include the same content on many web pages. For example, a navigation menu, banner, logo or footer. If a site is made up of 50 pages then it is much more convenient to make 1 change than 50.
I'm currently aware of 3 methods of doing this. Server Side Includes (SSI), PHP's include method and Javascript's document.write.
What are the advantages and disadvantages of each of these methods? Which of them is the fastest to the end user? Are there any better solutions out there?
Note: I'm not asking about template options like that offered by Dreamweaver.
Best answer: If all you need is to include content, use SSI. It's the simplest method, doesn't require anything beyond Apache, and is probably marginally faster than PHP (though the speed difference will be pretty negligable I'd think).
If your webhost doesn't support SSI for reason or if need to do something fancier (e.g. a navigation menu in which the item for the current page is treated differently) go with PHP or some sort of (server-side) templating system.
You don't need Javascript for this.
On preview: I would recommend against
posted by enn at 1:29 PM on August 30, 2008 [3 favorites]
If your webhost doesn't support SSI for reason or if need to do something fancier (e.g. a navigation menu in which the item for the current page is treated differently) go with PHP or some sort of (server-side) templating system.
You don't need Javascript for this.
On preview: I would recommend against
IFRAME
s. They'll be slower (each frame has its own HTTP overhead), complicate your markup, and can cause weird focus issues and annoy people. This is a task better done on the server.posted by enn at 1:29 PM on August 30, 2008 [3 favorites]
What enn said. In general, don't do anything client-side that you could do server-side before the document leaves your control.
posted by scottreynen at 2:04 PM on August 30, 2008
posted by scottreynen at 2:04 PM on August 30, 2008
When the browser is parsing the HTML and encounters something like <script type="text/javascript" src="http://example.com/whatever.js"></script> it has to stop parsing the file right there, and initiate a new HTTP transfer to http://example.com/whatever.js. It has to wait for that transfer to finish, then parse and execute all that code. Only then can it pick up where it left off parsing the rest of the HTML file. This is horrible for performance. Without this limitation it could go ahead and start fetching images, stylesheets, etc. found later in the file, laying out and rendering the text, and so on. But it can't when there's a script tag with external JS; it has to stop everything and wait. So performance here is worse than with plain SSI or any other server-side manipulation like PHP or Perl or Python or ....
Also in the modern age you have to contend with people that disable scripting in their browser for various reasons. All in all I'd say javascript is the worst possible way to achieve this sort of thing.
posted by Rhomboid at 2:08 PM on August 30, 2008
Also in the modern age you have to contend with people that disable scripting in their browser for various reasons. All in all I'd say javascript is the worst possible way to achieve this sort of thing.
posted by Rhomboid at 2:08 PM on August 30, 2008
A server-side scripting language is the right way of doing it, whether SSI, PHP or whatever. Which you choose is largely a matter of taste, what technologies you have available to you or are using.
Don't do it client-side - don't use Iframes and don't use JavaScript. Using server-side scripting is the tidiest, simplest, fastest, most accessible and browser-independent way, and ensures the site's content appears in order.
N.B. If you were to write it in JavaScript for some reason (which I don't recommend), doing it with document.write would likely be the wrong way. The correct way would be to find an element in your HTML and change its innerHTML.
posted by HaloMan at 2:10 PM on August 30, 2008
Don't do it client-side - don't use Iframes and don't use JavaScript. Using server-side scripting is the tidiest, simplest, fastest, most accessible and browser-independent way, and ensures the site's content appears in order.
N.B. If you were to write it in JavaScript for some reason (which I don't recommend), doing it with document.write would likely be the wrong way. The correct way would be to find an element in your HTML and change its innerHTML.
posted by HaloMan at 2:10 PM on August 30, 2008
Also note that there are clever alternative ways to use Javascript that don't cause the browser to block. But they won't work if you plan to do document.write() because obviously the output of document.write() is what replaces the contents of the <script> block in the HTML file, so there is no way around waiting for the script to be fetched and executed before parsing can continue. Furthermore, from a visual and UI standpoint it will be very jarring if the page loaded as one lacking menus or common elements and then suddenly at the end of loading they all materialized out of nowhere, causing everything to shuffle and rearrange. (You notice this with Greasemonkey scripts that add new elements to the page, because Greasemonkey scripts are deferred in this manner so as not to block the browser loading and rendering the page.)
posted by Rhomboid at 2:17 PM on August 30, 2008
posted by Rhomboid at 2:17 PM on August 30, 2008
Another reason not to use JavaScript, and (to some extent) iFrames is that Google and other search engines will have trouble spidering and scanning your content.
For example, if you include your site's navigation menu on 100 pages using JavaScript, a search engine will end up seeing your pages as having no links at all, and won't crawl those links to include the rest of your site.
SSI or PHP is the way to go. SSI is probably easiest if you're not a programmer.
posted by mmoncur at 2:37 PM on August 30, 2008
For example, if you include your site's navigation menu on 100 pages using JavaScript, a search engine will end up seeing your pages as having no links at all, and won't crawl those links to include the rest of your site.
SSI or PHP is the way to go. SSI is probably easiest if you're not a programmer.
posted by mmoncur at 2:37 PM on August 30, 2008
4 ways:
(1) Frames/IFrames. Advantages: Plain html, no server support necessary. Fast (load frame content once). Disadvantages: Ugly, having to write frames-related html.
(2) Javascript. Advantages: can insert text in the page rather than use a frame. Disadvantages: Everything else. Slow, awkward, the wrong way to do it.
(3) SSI. Advantages: Cleaner presentation than frames. Only needs Apache. Fast. Disadvantages: User redownloads the repeated content for each page (not a big disadvantage unless you're in some weird bandwidth-restricted context). Updating the include path when you restructure your site.
(4) PHP. Advantages: Same as for SSI. Disadvantages: Same as SSI, plus you need PHP. If you're already doing pages in PHP, use this rather than SSI.
Better solutions: Storing your content in a CMS and using templates to display site content.
posted by beerbajay at 2:38 PM on August 30, 2008
(1) Frames/IFrames. Advantages: Plain html, no server support necessary. Fast (load frame content once). Disadvantages: Ugly, having to write frames-related html.
(2) Javascript. Advantages: can insert text in the page rather than use a frame. Disadvantages: Everything else. Slow, awkward, the wrong way to do it.
(3) SSI. Advantages: Cleaner presentation than frames. Only needs Apache. Fast. Disadvantages: User redownloads the repeated content for each page (not a big disadvantage unless you're in some weird bandwidth-restricted context). Updating the include path when you restructure your site.
(4) PHP. Advantages: Same as for SSI. Disadvantages: Same as SSI, plus you need PHP. If you're already doing pages in PHP, use this rather than SSI.
Better solutions: Storing your content in a CMS and using templates to display site content.
posted by beerbajay at 2:38 PM on August 30, 2008
PHP will let you add some simple logic & variables to do things like highlight the current section in the navigation, insert the page title, etc.. I can't recall ever building a site where the header/footer were absolutely identical across the site.
posted by malevolent at 12:50 AM on August 31, 2008
posted by malevolent at 12:50 AM on August 31, 2008
This thread is closed to new comments.
posted by Class Goat at 1:25 PM on August 30, 2008