He goes through the thirteen rules to help improve your website's performance including:

• Make fewer HTTP requests
• Gzip components
• Make JS and CSS external
• Remove duplicate scripts
• Configure ETags

For more information about the YSlow extension (available for Firefox, Chrome, Opera and mobile devices), check out the project's page on Yahoo's Developer section (including ten more rules it checks).

When it comes to optimization, there are two competing viewpoints in the PHP community. Some say that optimization should only ever be an after thought and to avoid premature optimization at all costs. Others will say that this is impractical, and you should make your application fast as you write it, since then you won't have to go back and clean it up to make it faster. While I can understand the viewpoints of both sides, I am firmly in the former category.

He talks about the "90/10 Rule" of development (most of the work is done by only a small part of the code) and what that critical 10% could be made of. He also touches on the "60/40 Rule", "instinctual optimization" and the emphasis people put on benchmarks for their tool or framework of choice.

Hopefully at some point, your website is going to get a lot of traffic. Yay, you've reached your goal of getting good traffic, but it is soon followed by issues with performance and load. I like to call these the growing pains of a website. So as a web developer, I suddenly have the epiphany of "Hey, I need to scale my website!" What follows next is the biggest mistake a web developer can make: They start looking at articles on how Google scales, or maybe how Facebook manages all of their traffic. This is a mistake! To be brutally honest, you are not Google. You are not Facebook. You are not Twitter. You are a website that receives less than 0.000001% of the traffic that some of the major websites receive.

He includes a "reality check" of the setup behind a popular social site, StackExchange, with comments from their own post about their infrastructure. He talks about things included in a move to "middle-scale" like adding caching, performance tweaking, moving to a multiple server model and using replication.

People like micro-optimizations. They are easy to understand, easy to apply... and useless. But some time ago, while reviewing pull requests for Twig, I read an interesting discussion about the performance of the ternary operator in PHP (thanks to @nikic for the investigation). Do you know which [example] snippet is the fastest (of course, they do exactly the same)? The right answer is: it depends.

He notes that it's all about the data being worked with. As some of his tests show (testing code included) there does end up being a difference between using it on a small and large dataset. After investigation, it was found that the ternary operator copies (copy-on-write) the value versus an "if" that just evaluates. He also mentions the new "?" version of the ternary syntax in PHP 5.3, but notes it still suffers from the same issue.

The true path to the downloadable content can be revealed easily and is not protected, allowing users to bypass web forms and download the content directly using a browser. [...] The Solution: A Secure and Efficient PHP Download Script

This tutorial is actually an update of their previous tutorial looking at a similar subject, with a few differences. Their code provides a way to limit the files a user can download, the number of times they can download it and a script to read the file and push it to the user without them ever knowing the path.

One such limitation that I've recently seen is the performance of Zend_Config. This class underpins the mechanism by which developers provide configuration to the application, and all this config is passed around in the form of Zend_Config objects. [...] For the purposes of this article, I'm referring specifically to config INI files, using Zend_Config_Ini to parse. This is a very common format for Zend applications to use - it is familiar to developers and infrastructure support teams - and is the case where the performance issues become apparent

He talks about parsing ini files and the complications that can come with the Zend Framework method of parsing them - conversion to objects via a recursive method, merging data from different sections and the overhead toArray can cause. He shows an alternative that uses array_replace_recursive to handle the parsing and a class version that offers backwards compatibility with the Zend_Config structure. He claims to have seen a sixty percent jump in performance using these methods over the Zend Framework's defaults.

Yesterday Dan Horrigan (another PHP framework user and developer) suggested we all have a go at "Benchmark 2011". A chance for every framework developer or interested party to take their framework of choice, make a hello world and post it up online for a fair and factual survey of how many requests per second the base of the framework can handle without APC, etc. [...] This is not a new idea and it is certianly not meant to be an all encompasing comparison of framework features. The logic here is the same as testing the speed of server software such as Apache vrs Nginx.

He's included some rules to follow in creating your examples including the use of the latest release of the frameworks, no modification to the core framework files is allowed and you must create a publicly accessible repository with the example's files. If you're interested in participating, you can create your example and tweet about it with the "#benchmark2011" hashtag or just post about it in the comments.

I understand the need for simplicity because of the wide audience of Smashing Magazine, but I'd wish they'd give something more than the absolute basics you could find in almost any other site out there [in their recent tutorial]. I also didn't like some of the methods mentioned there for profiling (or the code itself), so I here is my starter guide to optimizing database performance.

Tips included in his post center around a different set of questions:

• When should you optimize the database?
• Think about profiling first, optimizing last
• How EXPLAIN can find the big problems
• When caching should be used

Some code is included, but only briefly since his point is more about the server than the client (script) side of things.

Following our earlier entry about installing Magento Enterprise, we thought it would be appropriate to follow up with some tips for getting more from your Magento installation. One of the major criticisms leveled at Magento is its speed; many complain that it is far too slow. In this article we'll go through some steps you can perform to fine-tune your server to allow Magento to run more smoothly and more quickly in a production environment.

Among the technologies they recommend are things like memcached, mod_expires, APC, gzip and MySQLTuner.

Here are some points that come to my mind when talking about performances, scalability, PHP, ...First of all, there are many aspects/questions that are to consider : configuration of the server (both PHP, MySQL, and system) ; you might get more help about that on serverfault, I suppose, PHP code, database queries, using or not your webserver? Can you use any kind of caching mechanism ? Or do you need always more that up to date data on the website ?

He goes on to give tips about using a reverse proxy (like Varnish), using an opcode cache, caching data as well, profiling and optimizing SQL queries. He finishes it off with a more specific look at Kohana and how you can use some of its built in tools to accomplish these same goals.