> 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
So a syntax error is now a "crash?". Web developers...
I.e run the proper init script (which might also do other checks), not just test the apache config, as you wouldn't also just start apache with apachectl.
Even if you have your own version of apache compiled, you should still provide your own init script, and write in in the standard service way.
Lots of production installations don't use distro-supplied binaries for their critical services (and there are lots of good reasons for doing this). They generally won't work with (or have) the distro-supplied initscripts.
Note that systemd makes it a lot cleaner and simpler to supply your own service definitions, so eventually your intuition will probably be right, and systemctl will be the proper interface to everything.
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.
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!
pretty sure pagespeed tells you to minimize http requests. that's one of the top things. one of the points from what i remember was to combine js and css files.
I don't know. The landing page http://www.portent.com/ is painfully slow for me. The optimization listed are mostly frontend optimization. The first thing I would do is to figure out the bottleneck.
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
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.
The site is still slow, but at least it's a start.
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.
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.
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.
The same applies for when you have to demo something to your boss that you just tested 50 times, and of course it crashes on the first try when you demo it!
"- Don't use question marks in a resource URL (.css?v=234)"
why? if you get the cache headers right, this is the way to go to let it cache forever. that's a nice thing.
(i don't really get why they do not use a caching proxy in front, there even is a wordpress plugin for varnish, so wordpress behind a caching proxy does not suck that much.)
unfortunately some suggestions are not possible with wordpress, so that alone could be a thing worth replacing.
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).
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.
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.
38 comments
[ 4.5 ms ] story [ 55.4 ms ] threadSo a syntax error is now a "crash?". Web developers...
Why go ghetto? You should be doing something like "/sbin/service httpd restart".
For this reason, there's zero excuse for ever having an Apache install crash from a typo.
Even if you have your own version of apache compiled, you should still provide your own init script, and write in in the standard service way.
The 'service' equivalent is: service httpd configtest
> Why go ghetto?
What does 'going ghetto' mean exactly?
Yep, typo-ed it.
>What does 'going ghetto' mean exactly?
The slang meaning of the term in this case: a low level, jury rigged solution.
Note that systemd makes it a lot cleaner and simpler to supply your own service definitions, so eventually your intuition will probably be right, and systemctl will be the proper interface to everything.
curl -w "\nTotal time: %{time_total}\nTime pretransfer: %{time_pretransfer}\nTime starttransfer: %{time_starttransfer}\nSize download: %{size_download}\n Speed download: %{speed_download}" www.example.com
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.
[1] http://i.imgur.com/niDK1.png http://i.imgur.com/MLdj8.png [2] https://developers.google.com/+/plugins/+1button/#async-load
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.
Aaaaand I think we're done here.
That cool curl command against rakeroutes.com:
That's off a regular ol' shared Dreamhost account.- Write compact efficient CSS (arguably the current CSS file is far too big)
- Combine all CSS files
- Don't use question marks in a resource URL (.css?v=234)
- Write valid compact efficient HTML (duplicate meta tags like: ICBM, unnecessary tags like Google verify, inline CSS, depricated HTML: align="left")
- Dont use spacer divs (div clear="all" style="padding-top: 5px") for a better render flow
- Delay loading javascript to the body of your site.
- Combine javascript files
- Compress javascript and CSS files.
- asynchronous loading of web fonts and analytics code.
- Load all CSS files before JS files.
For the unoptimized 1000 images you can use a Wordpress plugin or roll your own batch script.
why? if you get the cache headers right, this is the way to go to let it cache forever. that's a nice thing.
(i don't really get why they do not use a caching proxy in front, there even is a wordpress plugin for varnish, so wordpress behind a caching proxy does not suck that much.)
unfortunately some suggestions are not possible with wordpress, so that alone could be a thing worth replacing.
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.
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.