Well, first off, how does it impact a site engineer?  According to the official post:

it doesn’t carry as much weight as the relevance of a page. Currently, fewer than 1% of search queries are affected by the site speed signal in our implementation

Its not clear to me which 1% are affected or how that’s decided.  Is it just a test affecting queries for 1% of users, or is it uniformly applied to all users but is only being applied to 1% of queries?  Which queries and why?

Anyway, given that its only one of “more than 200 signals” clearly its not the major factor in determining relevancy.  But still, Google can’t throw out a challenge like this and not expect people to obsess over it.  Which is part of the point, I think.

When working on optimizing site performance engineers typically consider a variety of KPI:

• Time to first byte
• Base page download
• Progressively rendered elements:  headers, above-the-fold
• Full page download, including all resources

So what is Google actually measuring as “web site speed”?

The official post displays a chart indicating

Labs > Site Performance shows the speed of your website as experienced by users around the world as in the chart below

Furthermore, they link to an earlier post describing site performance in webmaster tools which says

The performance overview shows a graph of the aggregated speed numbers for the website, based on the pages that were most frequently accessed by visitors who use the Google Toolbar with the PageRank feature activated

Matt Cutt’s post on site speed links to the blog post containing the above information indicating

Google’s webmaster console provides information very close to the information that we’re actually using in our ranking

So there it is.  Google are measuring web site speed as Full Page Download, including all resources across ALL pages on your site.  All pages.  They confirm this

As the page load times are based on actual accesses made by your users, it’s possible that it includes pages which are disallowed from crawling. While Googlebot will not be able to crawl disallowed pages, they may be a significant part of your site’s user experience

So to recap:

• They’re measuring full page load including all resources.  Your scripts, your images, third party display ads, third party scripts etc.
• They’re measuring all pages visited by users on your site, not just crawlable pages.
• They’re measuring from users actual web browsers.  No simulations.  From real bandwidths.

Clearly, most of the well-documented best practices for speeding up your website still apply.  So is there anything else to consider?

• Post-loading content is looking pretty interesting to us, if it can be done in such a way that it is not factored into page load time.
• Minimizing 3rd party content, such as display ads, could have a huge impact.  We have little control over 3rd party creative.  I’ve seen ads make up to 7 additional HTTP requests for XML, Flash, images etc.  Steve Souders has a complete initiative around Performance of 3rd Party Content.
• Focus on pages that might be contributing to longer load times even if they aren’t your primary experience.
• Beware of links on your page that are served from your domain but redirect to other sites.  E.g. http://your-site.com/redirector?target=<some_other_url> that 302s to some_other_url.  I believe Google is counting the foreign site load times as part of the linking domain’s performance.  I’ll have concrete numbers on that in a few weeks.
• Continuously monitor and measure your web-site performance over typical user bandwidths, for example using Keynote KITE.  Optimizing for your office LAN and a low-end DSL connection are two different propositions.

So to conclude… If you’re already focused on site performance, you don’t really have much to worry about.  Keep optimizing pages for your real end users on real bandwidth and continuously monitor your sites performance.

During a recent tech workshop, Phil challenged some of us to think about our roles from a different perspective; to give our “job descriptions” a bit of a different spin — focusing on job expectations. One of these exercises was to finish the thought, “I am a …”.  I see a lot of job candidates with Architect titles on their resumes with a huge variety of skill sets and experience.  Looking beyond technical skills and trying to distill the qualities of an Architect was certainly an interesting exercise.

Here is my take on the expectations of an Architect:

I am an Architect

• I am a strategic business partner, creating value through technology.
• I clearly understand the “why”; I create the context and articulate the need to our delivery teams.
• I enable my business partners to discover new possibilities through technology.
• I lead by example.
• I can visualize a solution before it exists.
• I guide the design of high quality solutions, striking a practical balance between value and risk.
• I am persuasive; I direct, not dictate.
• I focus choice without limiting solutions.
• I reduce complex problems into manageable pieces, define their interactions and communicate these concepts to all.
• I respect the expertise of designers and engineers with more in-depth knowledge of their discipline.
• I own my solutions at every level – from concept to production, software to hardware, cradle to grave.
• I actively cultivate my partnerships with our Business, Quality, Project Management and Technology leadership.
• I create principals and practices that advance business goals rather than place arbitrary restrictions.
• I consider every problem an opportunity to learn something new.
• I understand what’s at stake.
• I know that if I don’t, maybe nobody will.

I am an Architect and above all, I am relentless in my drive for continuous improvement.

Finally, what differentiates an architect on a smaller team from an enterprise architect or from a Chief Architect?  I found an interesting paper - Role of the Chief Architect – that suggests there are many dimensions, but organizational scope could be the primary factor.