Support For Google's Spdy, Pagespeed And Web Performance Best Practices

[Webspeed (Cinemag)]

As both a practical issue and a way of refreshing its “high performance” marketing claim, my suggestion is for Yii to support SPDY, PageSpeed mods and all of Google’s Web Performance best practices, the first of which could be added verbatim to the list of Yii’s key traits: “Yii keeps application data and logic off the network altogether, thus allowing for maximum speed.” This takes the “high performance” claim (which Symfony 2 has hijacked!) beyond the application itself into the web performance level which is what really matters to clients and developers alike.

Along these lines I would suggest updating Yii’s marketing tagline to this:

"Yii is a high-performance component-based PHP framework best for practical developers to build high traffic web applications."

Note the “practical developer” reference, I studied Makaroff’s slides on Yii2 and the “practical” word kept coming to signal that Yii is not trying to generate consulting business by code complexity (ie Symfony and Zend).

And if someone thinks that Web Speed is only a server-level thing that exceeds the framework and the application, here’s an excerpt of Google’s best practices at the Application level:

SPDY Best Practices

Application level

Use a single connection - it’s better for SPDY performance and for the internet to use as few connections as possible. For SPDY, this will result in better packing of data into packets, better header compression, less connection state, fewer handshakes, etc. It improves TCP behavior across the internet and reduces bufferbloat. Interacts better with NATs as well as it requires less state.

Don’t shard hostnames - This is a hack used by web apps to work around browser parallelism limits. For all the reasons that we suggest using a single connection, hostname sharding is suboptimal when you can use SPDY instead. Furthermore, hostname sharding requires extra DNS queries and complicates web apps due to using multiple origins.

Use server push instead of inlining - This is a hack used by web apps to reduce RTTs. Inlining reduces the cacheability of web pages and may increase web page sizes due to base64 encoding. Instead, the server can just push the content.

Use request prioritization - Clients can advise the server on relative priorities for resources. Some basic heuristics which clients should all do generally is to make sure that html > js, css > *.

Use reasonable SPDY frame sizes - Although the spec allows for large frames, it is often desirable to use smaller frames, because this allows for better interleaving of frames from different streams.

Don’t use CSS sprites with external stylesheets - Resources in external stylesheets are obviously only discovered after the external stylesheet has been downloaded, and only once the rule matches an element. The advantage they provide of reducing HTTP requests is unnecessary with SPDY due to its multiplexing. Therefore, CSS sprites just make it slower.

If Yii is a framework for building web applications, then it should also help both developers and project owners cope with web application success, Yii is not a front for generating consulting business or a new toy for web artisans, Yii is a serious tool for building web applications and therefore should come out of the box prepared to face the consequences of success: a ton of traffic.

[samdark (Alexander Makarov)]

As far as I know, SPDY has nothing to do with the framework itself, it’s about installing module for Apache or re-compiling nginx. Doing as less requests as possible is the job of the application, not a framework. Framework doesn’t do any requests by itself.

We already have HTTP-cache layer http://www.yiiframework.com/doc/guide/1.1/en/caching.page#http-caching that covers most of the best-practices. The rest practices, such as image re-compression, isn’t really a framework job.

[Webspeed (Cinemag)]

As far as I know, SPDY has nothing to do with the framework itself, it’s about installing module for Apache or re-compiling nginx. Doing as less requests as possible is the job of the application, not a framework. Framework doesn’t do any requests by itself.

Yes, but the application needs to support things like cache invalidation (a classic weak spot for Ruby on Rails, from which Yii got a lot of inspiration). I am working on a Yii/Redis/Nginx application and I cannot find documentation on how to get Yii’s caching working with Nginx’s caching for proper cache purging. (I read Flamp.ru’s presentation with great interest, but we use Redis as a database, they do not). So I would greatly appreciate if you could point me to resources to figure out how to get Yii to “talk” to Nginx for cache invalidation in high traffic sites (ours is 4x times busier than Flamp).

Best regards

[samdark (Alexander Makarov)]

So I would greatly appreciate if you could point me to resources to figure out how to get Yii to "talk" to Nginx for cache invalidation in high traffic sites (ours is 4x times busier than Flamp).

That depends on how you’re using nginx to cache content.

flamp.ru case is a bit special since they’re using SSI and are invalidating cached parials manually. Database doesn’t matter in the case and they’re using Redis for historical reasons. Also it was mentioned during their speech that flamp can work well w/o any caching and that all this caching is for them to be sure that they can handle much more traffic in the future.