I'm currently working on a website in which some pages are written in PHP, but not all of them.
I'm considering including the menu as a PHP file (so when the menu has to be changed I only have to change it in one file, instead of all my pages). But that requires converting my HTML pages into PHP.
Aside from the fact that changing for example the menus will be easier, will it make a difference in loading time at the clients side?
Just curious if it will make a noticeable difference.
It won't make any noticeable difference unless you add very heavy calculation or bad code inside. For include only and maybe some appearances of if and echo it won't make any difference that you could notice.
The load times will be slightly longer as each of the PHP files needs to be processed in order to generate the HTML which the browser can render. It would also need to load each included file for the page too.
The "slightly longer" won't amount to anything noticeable, it will be fractions of a second for the server to respond.
Will there be difference? Yes.
Noticeable by human? No.
Related
I actually ran into a problem today. I have got a site where multiple pages have the same layout. Today I had to change a thing on this layout and had to change every single page. This made me think about solutions for this.
So, my question:
Would the performance and loading speed of the website be affected if I had the layout HTML in one single file and read it using PHP on every page? This would make it a lot easier for me, since I only had to change the layout in that single file.
Also, how should I read this file. At the moment, I would use the following code:
for ($count=0; $count < $dirAmount; $count++) {
$path = " //path\\ ";
$fileText = split("--", file_get_contents($path));
echo " //code\\ "
unset($fileText);
}
But would there be a faster way?
BTW, if this is too trivial, please note. I couldn't find much other information that actually was clear enough to help.
Simply use php's include or require to include the file.
It will affect performance a little bit, but that tiny little performance cost is insignificant compared to the ease of having one file you can use in multiple places.
One suggestion would be to use full file paths on include/require statements. Normalizing a relative file path can be expensive; giving PHP the absolute path (or even “./file.inc”) avoids the extra step. - Source
I would suggest you consider using smarty or twig if you want to start using templates for your website. Those engines optimize page loads by pre-caching pages and optimizing them to load as quickly as possible.
As for your original question, no, especially if the file was called repeatedly by the entire website, it would most likely get cached into RAM and load pretty fast since it was being called often. As Cerbus mentioned, using include or require would probably be the fastest way to process the files.
I am new to Javascript and development in general and have an absolute beginner's question: I would like to know more about the advantages and disadvantages of the following two constellations, especially regarding execution speed and server load/requests.
Put all custom JS code inside PHP code and call it from there
Put all custom JS code inside a custom.js and just call the JS functions in PHP
On the one hand I prefer to keep all my JS code separated to have things tidy and clean but on the other hand I imagine that it takes longer to load the page due to an additional server request. Will there be a noticeable speed difference when I put all code in a custom JS file? Are there any specific scenarios where it's recommend to put the JS inside the PHP or keep it separated?
Thanks
Http requests run in parallel, so loading a js file may not be noticeable at all, assuming you have to wait for images and other assets to load as well. The benefits outweigh the potential drawback.
As an added bonus, js files are normally cached, while html is reloaded each time a page is requested.
NOTE: If you have a significant number of scripts, you will have problems with load speed since browsers have limits of how many requests can be made in parallel. In this case you should be looking into minifying and combining them. Try code.google.com/p/minify for automatic minification using php.
Last: Having js code in php is terrible for maintainability.
JS in separate file - additional request. But I would not say that is a problem because it will be cached by browser. If you have a lot of js files - collect them into a single file to avoid multiple requests (there are special tools to compile separate JS files into one file and minimize its size).
Placing it into PHP code is just terrible. It should be in separate file.
On the one hand I prefer to keep all my JS code separated to have things tidy and clean but on the other hand I imagine that it takes longer to parse the whole code.
Why? JS is executed on client side. Not on server side. PHP will not parse JS files. At the same time - if you will put a JS code in PHP file - PHP will need to echo it to browser and that is additional work for PHP engine. Plus, in PHP code it will be sent to browser any time when PHP is executed.
Always err on the side of clean readable code, lest you fall into the premature optimization trap.
You can always refactor underperforming code to make it faster, it's much harder to move from low-level optimizations to a more abstract design, than the other way around (abstract to low-level)
Continuing this question What is the best way to manage duplicate code in static HTML websites ...
I'm starting to create PHP variables for each chunk of duplicated HTML code. My website is divided into themes and each theme has its duplicated code. I have the option to:
save all variables into a single PHP file, and then include it at the beginning of each HTML page (even if the page only uses one or two of those variables);
create a PHP file for each "theme" and include at least two PHP files at each HTML (one with the common variables and other with the specific variables.
Which one is faster? Including several small PHP files increase the page's loading time? I think the "non-monolithic" version is easier to maintain... I just need to know if I'm sacrificing performance.
I just need to know if I'm sacrificing performance.
Except that you don't. This is premature optimization. Go for the one that maximizes maintainability and ease-of-programming.
I'd go with one file including all the necessary files or themes, that makes maintenance a lot simpler. If you mean faster to develop, that's also the one to go for.
I wouldn't worry about the performance. Your site is never going to be as slow including files you don't use as some of the frameworks out there.
I have an ad network script like the following
http://cdn.domain.com/ad.php?variables=etc
We have about 10,000 hits a second and we are looking at some improvements for our Pseudo code - this is what I have in mind - my question is - would PHP includes slow down my script like the if else codes and would it be worth minifying the PHP on this page:
<?php
// mysql connect
// get variables from publisher
// if publisher has no ads show advertise here banner
// if resolution from variables is 125x125 show that banner or whatever resolution from the vars
// example www.noadhere.com/image/advertishere_{var}125px.jpg
// if publisher has no ads show advertise here banner and also updated mysql with page views for this publisher
// if publisher has a banner then show it and update mysql with page views
// show also the click code that redirects and updates the record with a hit click
?>
I have updated the code. This is the Phase 1 draft for those who are interested. I think it is so much simpler and I am going to minify this - even though there may not be need - we had 4 mysql actions happening. And now there are 3 - I just made the update views a one liner.
# mysql
$c=mysql_connect("sqlmaster.adserver.com","user","************");
mysql_select_db("adserver", $c);
# vars
$a=mysql_real_escape_string($_GET["z"]);//id
$z=mysql_real_escape_string($_GET["z"]);//zone
$h=mysql_real_escape_string($_GET["h"]);//height
$w=mysql_real_escape_string($_GET["w"]);//width
$d=date("Y-m-d H:i:s");//date
$u=mysql_real_escape_string($_SERVER['HTTP_REFERER']);//url
# constructor
# do we have ads?
$r1=mysql_query("");
if(mysql_affected_rows()==0){
# empty ad code unit
echo 'Blog Empty';
} else {
# we have ads - so show random click code
echo 'Click here .php ? and redirect';
}
# update mysql view table for this ad unit - empty or filled
$r2=mysql_query("");
# end constructor
mysql_close($c);
Any suggestions on improving this would be welcomed. I think the mysql_real_escape is slow.
Using include only slows down your script by the amount of time it takes your server to open the file, which is usually just a fraction of a second. So it wouldn't drastically slow down your script execution.
When using a PHP cache, includes really don't matter that much. However, there definitely is a very minor difference.
My own build scripts automatically replace includes with "normal" code, using a self-made syntax that's backwards compatible with PHP:
/*safeinclude*/ include 'file.php';
My parser then reads the PHP file and notices this include. It grabs the contents of the file.php file and replaces the include with this code (after some cleanup, such as removing the leading <?php tag). It then gets saved to the bin directory, which is where the live files are.
This approach works very well, but you must always check for the <?php and ?> tags. Also, you'd have to split src and bin directories, because you can't change anything that's already live anymore.
Your primary focus area for optimizations should probably be the database though, and other CPU-intensive operations such as loops.
There are lots of ways of making code run faster. Usually splitting code into separate files will not improve performance (selectively including just the code you need instead of a huge library will probably help).
You may have noticed that there aren't a lot of off-the shelf solutions for minifying PHP code - there's a good reason for that. It won't make a lot of difference to the execution time (it does for javascript mainly due to the reduction in network transfer time - not in the reduction in parsing time). PHP code doesn't go across the network. And if you want to reduce parsing time, then using an opcode cache is a much effective solution.
Since this is presumably a significant revenue stream, then you should have the skills to know this already. However a lot of performance improvements come about by trial and error (and careful experiment design and measurement) - you might want to invest some time in developing these facilities.
The good thing about running if and else's is that only the code that is needed to be ran will run. Included pages are loaded in a split of a second and do not really make any difference on the speed. Most big websites have long trails of included files and you don't really notice it.
I have a few pages out (not too many though) and I was just thinking that I might want to change all of the pages to php instead of html. I am planning on using php in the future, I am just not quite ready yet to make it my full-time language. I know anythign you can do with html pages, you can do with php pages, but I just wanted to know, is there any reasons to stay with html compared to switching to PHP before my site gets too big and I wind up having to change 100 pages, and renaming hundreds of links?
The only reason I can think of is a small hit in performance.
Most web servers like Apache, LightTPD are configured to serve .html files as static files while .php files will have to first go through the PHP engine to be interpreted and only then delivered to the client.
Your pages will still be HTML. PHP allows websites to be generated dynamically, that is, you can display a username for users. However, what is sent to the browser is still HTML.
I recommend that you start switching to PHP because even if you choose not to use PHP, your pages will still work and render fine. However, if you stick with .html and then decide to switch to PHP, then you'll have to convert every single link. So convert now, and save time.
One thing I should note: It is possible, but usually not done, to have .html pages render as PHP by modifying server settings. However, in most cases, the .php is used, as most servers are already configured to run .php though the PHP engine. But in case anyone with a large site has this question, this is an option.
You pretty much answered your own question. If you ever reach the stage where you want to add dynamic content to an HTML document, you're going to need to change the file extension, or alter the webserver configuration to have PHP process .html files.
Generally, you will want every page to contain, if not dynamic content, then at least consistent content. Things like headers and footers, that require a massive amount of copy-pasting in straight HTML or a single include() in php. PHP allows for much cleaner organization and much less repetition, even if you're not after dynamic content for your pages.
The extension doesn't really matter. the PHP marker won't have any real effect until you begin embedding the tags into the files to engage the script processor.
Although it's true that you can do anything with PHP that you can do with HTML, the contrary is not true. With PHP you can do things that are not possible with HTML. Specifically, you can create dynamic pages with PHP, that is, pages whose contents are not fixed once you've written them.
If your pages are static, then you should continue to use HTML, if you need dynamic content, then you must use PHP (or another template/programming language).
why stay with just html when u can have both? u can have static html pages for static content and php pages for dynamic content. You can manage not just links but almost everything with php. I am creating a site with just 30 pages and I can say, while I do have both php and html, some things get out of hand (links, templates, data, etc). Imagine having 70 more...
Well, there aren't that many disadvantages maybe except for the fact that you might end up with this sort of code