igrigorik

You can increase your sampling to rate to as high as you want, even 100%: https://developers.google.com/analytics/devguides/collection...

The cap is 10K visits/day.

You can put as many img tags as you want, with any format that you like, today. If your visitors support the formats you're emdedding, then you're good to go. Strategy #2: javascript detection, ala modernizr webp tests.

Most users who don't run their own servers also don't know a thing about image formats - so the point may be moot. :-)

In fact, this is why this problem should be automated. Most blogs are serving uncompressed images, which are resized on the client - worst of all cases.

Yep, flipped the billing bit. All I need is the extra bandwidth though.. The sole Go app instance is standing up like a champ!

There is a bit of lag for the hnsearch API to pickup the latest vote count.

Check one of the bgr.com articles, they have it installed in the sidebar.

The instructions are for the async install, so even if the widget is broken or goes down (it shouldn't), your site rendering will not be blocked, or affected in any other way.

Unfortunately, not that I've found.. Twitter and G+ also reserve the space and run into the same problem. The root issue is the lack of automagic iframe resizing.. which is what "seamless" attribute will solve, once it arrives and is supported by the browsers.

Fixed - plenty of quota now!

I honestly didn't realize how much traction it picked up over the past 6 months.. It was a (pleasant) surprise to login into my GAE console and realize that it was serving, on peak days, over 1M impressions.

Interestingly enough, the "exceeded quota" was not for CPU resources! Instead, it was all egress bandwidth. On busy days, it would reach the free 1GB egress limit sometime between 6-12PM, and hence the error. I've upgraded the app, and it should be good for terabytes a day. ;-)

P.S. I've also pushed an update to enable more aggressive HTTP caching on the assets.

If your upstream bandwidth to Google is poor, chances are, your upstream bandwidth is poor for most other users. In other words, I would consider this an issue on its own, and one definitely worth investigating.

CDN's are popular for static content, but there are a number of very good reasons to proxy dynamic content through your CDN as well. The most obvious advantage is that you can terminate the TCP connection much closer to the user, and then can leverage the optimized backhaul network to fetch from origin. This alone can be a huge win, especially if you have SSL in the mix, which requires 2-3 RTT's before it can even send the request.

Mostly just hooking up all the API's - aka, "making it work", and making it work in the context of nginx. As a reference point, the Apache implementation took a while to get right even just because understanding all of the gotchas of Apache's worker model and surrounding API's took time - half a dozen false starts, etc. Now it's solid.

If someone has good understanding of nginx internals, then any input, guidance, etc, would be awesome, as it would short circuit a lot of that extra work. We have a design doc in progress, I'll work on making it public and will share it in the project readme. In the meantime, if you have any suggestions, open an issue on the repo and let us know!

Just a heads up.. ngx_pagespeed is a work in progress. As in, the skeleton is there and there is a filter or two running as a proof of concept, but there is still a lot of work to be done. Contributions would be most welcome.. :)

In my own case, Sublime + codekit + chrome.. Hand editing the HTML. :-)

Yup, I believe there are CSS selectors for that as well. The best way to play with it is to checkout the devtools source and take a look at the default structure: https://developers.google.com/chrome-developer-tools/docs/co...

Confusingly enough, HTTPArchive.org, and HAR the file format are two different projects (although one depends on the other).

httparchive.org - captures web trends http://www.softwareishard.com/blog/har-12-spec/ - HAR file format

And that may be just fine for your product. Having said that, I'm a big proponent of treading speed as a feature - evaluate it, quantify it, and prioritize it as such. Then, you may have the time to use these tools :-)

I have a writeup on some of the chrome network internals here: http://www.igvita.com/2012/06/04/chrome-networking-dns-prefe...

As you found in the code above.. the idea is simply to complete the TCP handshake and keep the connection idle until the request is ready to be dispatched. Doing so allows Chrome to shave off one RTT (TCP handshake) of latency.

If you care about this, and you should.. Please open a bug to fix this: radar.apple.com

(unfortunately we cannot see bugs opened by others)

Yes, you could definitely do that. A good example would be an offline app.. Having said that, in a recent turn of events, iOS 5.x+ decided to make localStorage non-persistent... Ugh.

Thanks for pointing this out, will definitely look into it. One tip is, and it sounds like you're already using it, is to download the webfonts to your local machine, which would avoid any future downloads. (Except, that still wouldn't resolve the blocking of the dynamic CSS).

Poor wording on my part. Font hinting meta data is removed for platforms that do not support it. Ex: windows does, and hinting data is retained for improved rendering.

Instead of relying on a few pings, run the test for yourself: http://code.google.com/p/namebench/

The Google DNS team built the tool above, and it allows you to test your current setup against a number of DNS vendors + allows you to share the data, etc.

I believe that comment by Doug is not referring to "SPDY server push" specifically, but is instead making a broader argument for a need to standardize a push mechanism for HTTP 2.0.

In theory, SSE/WebSockets should be able to fill in that gap (based on his described use case).

"Chrome for iOS has some pretty major technical restrictions imposed by the App Store, such as the requirement to use the built-in UIWebView for rendering, no V8, and a single-process model. As a result it’s been challenging to re-use critical Chromium infrastructure components.

That said, there is a lot of code we do leverage, such as the network layer, the sync and bookmarks infrastructure, omnibox, metrics and crash reporting, and a growing portion of content."

https://groups.google.com/a/chromium.org/forum/?fromgroups#!...

This is just silly. Time to first byte does matter, when you know what to put in those first bytes.

https://plus.google.com/114552443805676710515/posts/GTWYbYWP...

If you know the exact dimensions you're going to query, then you can construct a data cube to fit your exact scenario up front, and indeed, those will return fast.

BigQuery allows you to explore the data without the pain of setting up your star schemas upfront. Think of it this way: you've got XXX Tb of log data, and you have a new question you want to ask it. At this point, you're heading back to Map-Reduce, or Pig/Hive, etc. BigQuery is based on Google's Dremel (check the paper, great read), and has all the operational + performance learnings from wide deployment at Google. Type in your "SQL like" query and BQ takes care of all the rest.. within an order of seconds.

tl;dr: you're comparing apples and oranges.

Cute, but I don't think it works.

It's similar to saying "terse code is better code". Unfortunately terse, also often leads to "clever". And clever code, as we all know (I hope), is a liability. I'll take verbose and well documented code (speaking of which, you need to strip comments if you want a fair playing field), over "well compressed" code.

Having said that, the less unnecessary ceremony in the language the better. The trick is finding that balance.

TCP connections take a lot of time to setup, and go through a ramp phase (slow start), especially on mobile where RTT is 200-1000ms. The theory is that by multiplexing multiple requests over the same connection, you'll get faster overall load time.

You can think of domain sharding as a workaround for the fact that HTTP does not allow true multiplexing. With SPDY, we can avoid that complexity and reuse the same connection.

I'm saying the oppposite. I have no reason to proxy twitter.js or other ads scripts on my site. If CF is taking the step to rewrite those to the same domain, then they also have to guard for respecting all the cache implications of that.

Looking through CF's own site, plus a few of their "case study" links, I don't see the domain rewriting happening on these scripts. And as you indicated, with additional complication of user cookies / HTTP vary, I'm not sure that's necessarily a good idea either -- if either of those in place, all of your cache optimizations go out the door. Best gotcha example: ads.

Seems like there is a bit of false advertising going on here.

Do you rewrite the hosts on all third party sites to be the site domain? I'm still not following this setup.

Silk is an entirely different setup. Silk (a) manually sets their SPDY gateway as a browser proxy, which is a system level setting, and (b) silk does not tunnel HTTPS requests. CloudFlare obviously doesn't have control over my browsers proxy settings, so if the page I'm loading is abc.com/page, and that page has a request to twitter.com/widget.js, then the browser should open a connection directly to twitter.com to fetch that resource.

P.S. SPDY does allow tunneling HTTPS, but once again, that requires a system level proxy setup.