I don't know. The landing page <a href="http://www.portent.com/" rel="nofollow">http://www.portent.com/</a> is painfully slow for me. The optimization listed are mostly frontend optimization. The first thing I would do is to figure out the bottleneck.<p><pre><code> curl -w "\nTotal time: %{time_total}\nTime pretransfer: %{time_pretransfer}\nTime starttransfer: %{time_starttransfer}\nSize download: %{size_download}\nSpeed download: % {speed_download}\n" http://www.portent.com/
Total time: 2.629
Time pretransfer: 0.375
Time starttransfer: 1.400
Size download: 32730
Speed download: 12449.000
</code></pre>
Ok. Not bad. Backend seems to be fine. But then I did the profiling in chrome. Some cdn requests are well past 25 seconds in the timeline. For a user, the site load takes more than 25 seconds. Your cdn is the bottleneck - you should work on fixing the cdn first.
I hate how overhyped this article is. It should be titled something like "five basic tweaks to speed up your LAMP webpage". Instead, they're hyping it up as if they'd written their own custom http daemon.
> When I first turned this on, I set the directive in the configuration file to “Conneption: Keep Alive.” Apache began laughing hysterically at my typing skills, and promptly crashed<p>So a syntax error is now a "crash?". Web developers...
Aren't these just standard website speedup techniques? If you ran YSlow on the site, then it's probably going to give you the same advise, but in more detail. And it won't miss obvious suggestions like combine the scripts/css into one file!
The site is still slow, but at least it's a start.<p>There are still quite a few external scripts loading in the head that have the potential to block the page. The waterfall diagram from a test at webpagetest.org [1] shows a pretty dramatic example. It's not hard to load the Google PlusOne script async [2], and most of the other social network widgets can be lazy-loaded the same way.<p>[1] <a href="http://i.imgur.com/niDK1.png" rel="nofollow">http://i.imgur.com/niDK1.png</a> <a href="http://i.imgur.com/MLdj8.png" rel="nofollow">http://i.imgur.com/MLdj8.png</a>
[2] <a href="https://developers.google.com/+/plugins/+1button/#async-load" rel="nofollow">https://developers.google.com/+/plugins/+1button/#async-load</a>
You missed:<p>- Write compact efficient CSS (arguably the current CSS file is far too big)<p>- Combine all CSS files<p>- Don't use question marks in a resource URL (.css?v=234)<p>- Write valid compact efficient HTML (duplicate meta tags like: ICBM, unnecessary tags like Google verify, inline CSS, depricated HTML: align="left")<p>- Dont use spacer divs (div clear="all" style="padding-top: 5px") for a better render flow<p>- Delay loading javascript to the body of your site.<p>- Combine javascript files<p>- Compress javascript and CSS files.<p>- asynchronous loading of web fonts and analytics code.<p>- Load all CSS files before JS files.<p>For the unoptimized 1000 images you can use a Wordpress plugin or roll your own batch script.
we're moving from apache to nginx + php-fpm + apc on linode. as well as all the stuff recommended by pagespeed. jquery cdn, gzip, css sprites, pngcrush, js-min + concat, css concat, async script loading via LABjs. the improvement is quite remarkable. sometimes i blink and miss the F5 refresh flash and wonder if the page actually reloaded. craziness.<p>one funny thing pagespeed tells me is that google's own analytics ga.js needs a longer expire time than 2hrs, they should fix that especially for scripts loaded from common cdns (especially their own) since web authors have no control over this.
To make a site really, really freaking fast serve static content.<p>That cool curl command against rakeroutes.com:<p><pre><code> Total time: 0.439
Time pretransfer: 0.175
Time starttransfer: 0.270
Size download: 17506
Speed download: 39888.000
</code></pre>
That's off a regular ol' shared Dreamhost account.
Be aware of the potential downside to setting very long "expires" headers. There are sometimes caches deep in the darknesses of the Internet that obey these, which can cause havoc if you redesign and reuse any filenames (for instance logo.png).<p>We've had situations where a site appeared broken to a subset of end users for weeks because we tweaked the look and feel, and the new logo (different size and look) was named logo.png just like the old logo...which had an "expires" header of about one month.<p>So even after clearing all local and server-side caches, some users were getting our new HTML with our old logo horribly jammed into it--dutifully being served from some unknown cache somewhere until it hit the "expires" time.