Can you give us a bit of style check please?
I'm afraid we can't hear you right now.
Can you give us a bit of style check please?
If you have a question during the talk, since it's such a small crowd, let's think about it as interactive as possible.
If you have a question, raise your hand and say something.
What I'm going to do now is I'm going to switch and I'm going to...
Let me figure this out.
Well, that's going to be a challenge.
Okay, let's see.
Okay, I'm going to...
Of course I've got a PowerPoint deck and I just realized I can share that with you over the screen.
But okay, that might work out. Let's try it.
Let's see. Hold on.
Yeah, that's not awful.
Okay, hold on just a second.
I've got to change my preference.
You show...
I'm not sure what to do.
Okay, create a PowerPoint deck.
I'll just have to step through the slides this way.
So now I'm going to do this, boom, and there we go.
Okay, so one thing I wanted to point out is if you go to my website here,
you can see the slides are right over here.
So if anyone wants to download the slides, you can do that.
So you don't have to take a lot of notes or anything.
Okay, so... Oh, and here's the URL to that ring as well.
Okay, so this is kind of the story of my life.
I don't like things that are slow.
I like things that are fast and very efficient.
So this is really frustrating.
I don't know if you have this in Germany.
This is the DMV, Department of Motor Vehicles, here in the US.
And it's notorious for having really long lines.
The oldest daughter is getting her driver's license now,
so she's coming off a lot of time here.
And it's very frustrating.
In general, things that are slow are not a lot of fun.
Whereas things that are fast are exciting.
They make you smile and laugh.
They can be exhilarating.
They're fun to do with a friend.
And you never know what's going to happen.
So what does all this have to do with the web and the notebook?
Well, it turns out that fast is good on the web, too.
And it's really a strong selling point for vendors who work in the internet space.
So here's an app from Xfinity, where, you know, I've circled some of the things.
We've talked about speed, lighting effects, high speed, fastest internet.
This is an amusing set of commercials during the US for AT&T's network,
where faster is better.
And it's not just network connections.
It's also a hardware.
Your Apple is pounding the A6 chip in the iPhone,
and it's being twice as fast and delivering fast performance.
So speed and performance is a differentiator.
It's a competitive advantage for these players in the internet space.
And so it's not surprising that users who see these ads
have increased expectations.
They want this faster internet.
They want these faster devices.
Here's a chart that shows the results of four surveys
over the last 10 years in users,
how fast they expect their web experience to be.
And you can see that it's come dramatically fast,
so fast in fact that people are expecting web pages to come in under half a second a day.
And this isn't just conjecture.
There are a lot of studies that show these expectations that users have
actually affect the way that they integrate with our websites.
What they visit, what they view, and what they buy.
Here's an example of a study done at Bain
where they intentionally slowed down the search results for a subset of users,
and they saw all their goodness metrics drop off.
Perhaps most importantly revenue per user dropped off
by four percent with a two second delay.
They from Mozilla.
It's not always about marketing.
In the case of Mozilla, they're a non-profit.
Their goal is to get people to download their browser.
And when they made their download page two seconds faster,
downloads increased by 15 percent.
Here's a study that touched on several points from Shopzilla.
They made their site quite a bit faster, from seven seconds to three seconds.
And they saw conversions go up.
They saw the number of users coming into marketing more than double.
And the most interesting point of this study for me was
they cut the amount of hardware needed in half
from 400 servers to 200.
And more recently, here's a study from the developers
of Obama's campaign website from last year
where they made the website 60 percent faster
and donations increased 14 percent.
So...
Advertisers and members are selling faster experiments.
Users want faster experiments.
Businesses have shown that a faster experience produces better results.
So how fast are we actually going?
Let's start off by looking at something that we're all painfully aware of.
It's very damn mobile, this connection speed.
How fast is your connection speed?
So for this, I'm going to look at something from Akamai
called State of the Internet.
It releases reports every quarter.
And part of the report is showing connection speeds
for different regions around the world.
So unfortunately, they don't have aggregates in charge.
So I went back over the last four or five years
and reports, oh, they've never been reported and extracted data.
And here are the results.
If we look over the past few years,
we see that worldwide connection speeds have gone up 4 percent.
And in the U.S. it's gone up 18 percent.
Now this is for all internet connections.
They go through the Akamai Network.
They use any resources on the Akamai Network.
We can also rank it up as not only by mobile carriers in the U.S.
Akamai is hidden in the names of the carriers,
but these are presumably three of the top carriers in the U.S.
And the U.S. one is the same carrier over the entire life of the report.
So U.S. one might be AT&T.
Probably the others are Verizon and T-Mobile.
We can see that U.S. carriers,
one has gone up 68 percent over the last year.
The other one is more than double in speed.
And one is, the third has gone up 30 percent.
So overall, the last year,
global speeds were up about 4 percent.
U.S. speeds up about 18 percent.
And mobile, somewhere between 30 and 131 percent.
And then here.
So that's pretty good.
Okay.
Let's look at another major part of the web experience when it comes to performance.
And that's browsers.
Now, I don't necessarily want to talk about
the more contentious discussion of which browsers are battles.
What I'm trying to show is that,
is what I'm trying to explore is,
how fast are things progressing?
Are we getting faster or are we getting slower?
Well, what we can see here is,
if each would release a browser,
that browser is getting faster.
Chrome is getting faster when it deletes Firefox and Quality, IE.
Now, this is a great study.
This is actually based on real world data.
This is from Go.Net.
It's now part of the company there.
This is their real-user,
one of them trying to draw the data.
But these are real users visiting real websites,
and it's aggregated at the browser level.
So this looks like really, really valid data.
The problem is, it's about two years old at this point.
A year and a half, two years old.
And they had a refreshing study.
So we can look at other sources for browser comparison.
And the one that typically is looked at is JavaScript performance.
So we have these benchmarks that the sun's higher.
And again, we can see,
so for one regression of Firefox 18,
browsers in general are getting faster with each release.
So here's the sun's higher benchmark.
Here's the V8 benchmark.
And each release of a browser,
the browser is getting faster.
Okay, let's look at another dimension.
This one is something that as web developers,
we don't have a lot of control over the browser that our users choose
or our users' election speed.
But we do control the payload that we deliver to our users.
So let's look, and certainly if that payload is bigger,
it's going to take longer to download.
So let's look at this dimension of page weight,
which is something that web developers would do control.
So overall, this is a chart of the HTTP archive that this project had run.
And overall, we can see that the total transfer size
and the total number of requests has increased year over year.
Now, this chart actually,
we probably shouldn't spend too much time analyzing
because this is the data across all websites
that are being analyzed by the HTTP archive.
The HTTP archive is still growing.
So over the last year,
a year ago we were doing about 70,000 URLs
and now we're up to about 300,000.
So it's actually a different sample set of URLs.
So instead, let's look at this chart.
This is just the top 1,000 URLs worldwide.
And we can see again that that total number of requests
and total transfer size is coming year over year.
But this also has a little bit of a volume,
where in October, we changed our testing configuration
instead of stopping measurements at the window on load,
we actually stopped once network traffic subsided.
And of course, since we're measuring the longer window of interaction,
we detect more HTTP requests.
So instead, I manually looked through the data
and found just the request up to the on load event.
So we don't have a chart for this customer analysis,
but here's the data in the table format.
We can see that overall,
the total went from 822K to 1053K.
And this is for just the top 1,000 URLs.
So across the top 1,000 URLs,
the average size is over 95.
And this is transfer size.
This is after everything is compressed
and the website over is compressing.
So it's hung up, 231K, over 25%, just in one year.
And we can break this down into the typical content types
to see where that growth is mostly accounted for.
And it's images.
Images went up, 114K in one year.
JavaScript went up, Flash went down.
I think that's good for performance.
Each email CSS influence all went up a little bit,
not too significant.
But the thing that's interesting is,
if you look across all these major content types
and we add up their size increase,
the average increase per page if they went up,
it only adds up to 151K.
And yet the total says pages went up 231K.
So somewhere there's another 8K increase
that happened over the last year
that's not showing up under any of these content types.
So where's that even made?
It's in a category that I call Other.
So there's no 100% accurate way
to look at an HTTP request and response
and put it into a content type category.
Websites, every major website,
are returning JavaScript with a content type of image chip
or video with a content type of application octet screen.
So what I did was I,
all of these missed class apply responses
I just put into a category called Other.
And two years ago when I started the HTTP Archive,
Other was very small.
It was only about 10 or 20K on that page.
And now it's ballooned being almost 80K per page of data.
So I need to start classifying these responses better.
So I looked into these Other responses
and I broke them out by the content type
that the publisher of the website owner has specified.
And as far as size of the page,
the biggest contributor has a content type of text printing.
And then we have video I made for video XFLV,
an application octet screen.
The video ones I wasn't catching before
because I was focused on just Flash.
And really I should expand that Flash category
to just be a video category and throw these in there.
But the text plain with the octet screen,
those are still somewhat unknown.
What are we sending?
They appear for over 30K per page on the average website.
So what are those content types?
What are those responses?
If we look at text plain,
when I looked at the URLs,
I saw some very obvious patterns.
So there's these FLV, F4V video responses
and these TTFEOT wall extensions.
And video, by and large,
was the main content type being returned as a text plain,
which doesn't make any sense.
But that's what websites are doing.
So that's another 31K per page is being done as a video.
And octet screen is the same thing.
I saw these file extensions.
And so for octet screen,
about 7K per page is video and another 4K per page is font.
So as I go back and I reorganize these content type categories
and add this previously unclassified data into it,
we get the more active numbers,
where images have gone up 114K.
JavaScript has gone up,
we all fair about 15%,
but the big increase is in video responses.
They've gone up 62K in your open viewer.
That's a 67% increase.
Why is that?
I don't know.
Someone should take the data out of the ACB archive
and do a viewer analysis.
My guess is more websites are using video.
They might think they can do that
because more browsers support video
and connection speeds are faster.
We now have an HTML5 video tag,
so that makes it easier for me to video.
And we also have high resolution displays.
So the videos that we have websites are serving are probably larger.
So all of this is accounting for a dramatic increase in video.
The viewer can see a program in March Arts
and certainly images of the blue as a dramatic increase.
Red is JavaScript is still the second biggest.
But video, green, or it's size, is the biggest increase.
So we need to keep our eyes on video.
Certainly pages are getting heavier in a year.
28% are here in Europe and here.
And images by far are more than 50% of that content
and they're still increasing dramatically here over here.
So for something that us web developers do control,
we're not really controlling that too now.
Page weight is growing and it's not very well in check
and it's not very well understood why it's increasing so quickly.
So another thing that we web developers control
is what I call quality of track.
And this might, you might think this is kind of hard to quantify,
but there's actually quite a bit of data in the API archive
that touches on this quality of track.
How good of a job does web developer artisans want to do it?
And unfortunately, the story that I'm working with,
at least across the top, is the URL of the web.
So one measure of performance was offered for page-sheet score.
Page-sheet is about plugging into Google.
You can put it to your browser and measure to get a score of 0 to 1,200.
The 100 is really good.
Zero is really bad.
And so here you see that it's only gone up one point over the last year.
1.6 point over the last year.
Not very significant.
Really flat.
We can look at the size of the HTML document
and the number of documents in the page.
The number of documents in the page is a reflection of the complexity,
the depth and size of the page.
And that's going to slow down performance.
It's more work for rendering, more work for layout,
more work for applying CSS styles and doing selective matching.
And that's gone up from 12 to 13, 13, 13.
So about 10 to so many things.
And back to its size, I would expect it to go down or go up
if we were doing a better job in performance.
It would go down if people were realizing that they needed
to pave up the page to the frontiers to do it possible.
They would reduce the size of the HTML document.
Or it would increase if people were thinking about
in mind more resources, small scripts, small images,
and reducing the amount of HTML files.
But really you see a same kind of flag that's got a 2K increase,
less than 5% growth in the last year.
So there's really not much focus on the initial HTML document size at all.
We can look at the number of obeys per page on average.
That's increased from 15 to 19.
So no surprise, this is most likely due to third-party content.
Websites are adding more and more widgets, ads to the pages.
And all of these different domains require a DNS lookup.
So that would be able to slow down websites.
But this is also unfortunate.
The number of downloads,
the largest number of downloads on one domain,
has actually increased.
Let me explain this for an actual request on what domains
got a little more clearly.
On average today, the website has 19 domains that it works out of use.
In the HTTP Archive, we count the number of HTTP requests on each of those domains.
And then we find the domain that has the largest number of HTTP requests,
and that's what we report in this yellow one, in this orange one.
That's the maximum request on one domain.
So we see that it's actually gone up from 40 to 41.
Now if we keep in mind that browsers only download six requests at a time,
and then the average round trip for a request, even just a few days worldwide,
is over 500 milliseconds closer to a second,
we realize that it's going to take seven round trips to download these 41 requests.
And at half a second, that means the fastest that a website can load is three and a half seconds.
And really it's closer to a second page,
which is going to mean the fastest these websites can load is seven seconds.
So just because of the way that we structure our resources
and the ways that we're downloading them from,
we're setting up bottlenecks for how quick our website is.
The main charting is a good alternative to this large number of requests from one domain.
But we're not seeing a lot of adoption of that performance in this practice.
We all know that being able to read resources out of the cache
and not have to make it make sure that you request a disaster,
and yet a number of resources that are cacheable actually dropped 4% over the last year.
Compressing responses reduces the download size that basically stayed the same over the last year.
It went from 76% to 77% of resources were compressed.
Of compressible resources are compressed.
So we don't look at video or images here.
We only look at scripts, style sheets, JSON, HTML.
Hanges with errors stayed the same.
This is bad if, for example, the error is a script or a style sheet
because the browser is still waiting, blocking, rendering, making a wasteful request.
And it's also bad for the user experience.
Redirects, one of the worst things you can do in campaigns,
especially if it's a redirected HTML document, redirects actually went up 4%, 67% to 71%.
So year over year, there's been no significant improvement in these budget practices.
And in fact, five out of seven of these best practices got worse.
So that's how to do this sign.
Especially for someone like me who's evangelizing performance best practices worldwide,
this is not a good report card.
Well, let's look at something that really is a bargaining focus,
and that's how fast are these recommendations.
That's what we're really trying to do at the end.
Look at all of these things.
Browser speed, performance, connection speeds, best practices, quality of credit.
We're really trying to make agents faster.
So how are we doing on that?
One thing you can look at is a blog post like this,
where Joshua did speak from Stray Street.
He reported that public e-commerce sites are 22% slower year over year.
So this is pretty long.
Certainly, you know, catches your attention.
But I have to say, the way this data is gathered,
we really have a lot of details.
I don't think this data is really that accurate.
And it comes down to, for the same reason,
why I don't show the time data that we gather in the HTTP card.
What we're doing, twice a month, we look at 300,000 URLs.
We load each of those URLs three times,
so we're doing 900,000 page loads.
And here, this is the chart that I'm currently hiding,
because it's just too erratic.
You can see that like on, what was that,
November of, February 1st of this year, all of a sudden it's fighting.
It went from about nine and a half seconds to 14 seconds.
But keep in mind, the infrastructure that we're losing
for the HTTP archive crawl stays the same.
Every crawl does the same, right?
How can the page load drive vary so much,
especially across such a large sample size,
we're gathering almost a million data points, right?
And the answer is, this is synthetic data.
We've gathered this from one type of browser,
we use IDM, from one location, we're in Redwood City, California,
over one network connection in and out of our data center.
So this doesn't necessarily reflect the performance of the web at large.
For real users on real browsers,
real hardware, geographic images around the world,
I doubt that there's this kind of variability in page load times.
And certainly, whenever I see a spike like this,
and I try to import that to real world websites
where I have real feature data, I see no confirmation.
So even when we're getting a large sample size,
using synthetic testing is not good to use
for long-term trend witnesses.
It's okay to use synthetic testing
and do 80 comparison right now today.
It's maybe even okay to do short-term trend analysis
like over a few days or a week.
But long-term, it's really not a good way to do it.
There are just too many assumptions
built into your model of how you can have these data.
And that, I think, keeps in mind,
is problematic with these page load times.
All of these studies and, you know, how the page load time is.
Five years ago, the window upload was a fine window measure of websites,
with websites for mostly images, HTML,
and when the network requests stop, that's when most of the people use it all.
But today, with JavaScript, Ajax, CSS,
a lot of dynamic behavior built into websites,
the window upload is not necessarily an accurate reflection
of users' perception of how fast the website is.
This is not where we see users more engaged
or their searches increasing or their conversions increasing.
That's based on their perception.
It's not necessarily correlated with window upload.
I'll give you two great examples of that.
Here we see Gmail.
And at the top, we can see what happens at window upload.
In this test, window upload happened at 3.3 seconds.
But the only thing visible in the stream is the progress bar.
It's not even all the way done.
Whereas, at the point where I see the content that I'm waiting for,
what do I expect to see?
That doesn't happen until a second and a half, almost 50%,
longer after the window upload.
Excuse me, 4.8 seconds.
So here, if you were tracking window upload,
it's much too optimistic.
It's being avoided in the frozen picture
when the actual user's perception of the performance is much worse.
And in terms of executives, Amazon is a big one.
We, I don't know about you, I use Amazon a lot.
And there's a lot of stuff below the fold,
all the reviews and other sales offers.
And I don't necessarily look at it.
What I'm waiting for is I'm waiting for content above the fold
so I can see the price, I can see the green picture,
I can see how many stars there are across all the reviews.
And here we can see that at two seconds,
88% of that above the fold content is already displayed.
And the window on-load doesn't happen until 5.2 seconds.
So here, if you were tracking window on-load,
it would be in a much more pessimistic picture
of what the user's actual perception is.
And we can see how much of this is the below the fold content.
It might be hard for you to see, but you can see here,
at this point, the elevator, or whatever you call it here in this room,
picks up a majority of the elevator shaft.
And so we can see that they focused on rendering this above the fold content
very quickly.
But by the time on-load happens, that elevator shaft
is only about 10 or 15% of the fold page.
And so there's a bunch of data that's been downloaded
and rendered below the fold.
And so window on-load really isn't a good measurement
of the user's experience, the user's perception
of the speed of this website.
So I mentioned these numbers actually for some.
What we really need is a metric that focuses on rendering.
And a good version of that is speed rendering.
This is something that's available in web page tests.
It's the average time at which visual parts of the page are displayed.
So you can think of it as, if you put all the pixels on the page
and you took the median pixel,
how long did it take for that median pixel to get drawn?
So it's actually a number in milliseconds.
The lower the number is, the better the best for page renders.
And we can do a side-by-side comparison of Gmail compared to Amazon.
And even though Amazon has a much slower window on-load,
you can see that the user experience is much better, much faster.
So speed index is something, or something like it is something
I hope we will move to in the future as a replacement
for window on-load for measuring website speed.
And here you can see a plot of Gmail and Amazon over time
based on the rendering of these pixels in the page.
And again, Amazon pixels more or less are getting rendered more quickly.
And so it has a much harder speed index.
So we don't have a replacement for window on-load now.
So as much as in synthetic testing,
it has another better location for synthetic testing,
we can gather those measurements with speed index.
But rendering information is currently not available
as a rum data point.
It's not available in real user browser,
but in real user background.
So for now, we're still stuck with window on-load.
But luckily, we'll go back home and study as one of your example.
Google Analytics recently blogged
about the average Google Analytics rum data
across all of the sites that have opted into the terms of service.
And across all of those sites,
Bestop each of those times got 3.5% faster
and mobile got 30% faster.
So overall, the scorecard is connection speeds are faster,
faster, browsers are getting faster with each release.
The things that we let the knowledge control aren't getting much better,
pages are getting heavier,
or not seeing an increase in the adoption of best practice data.
So with these pluses and minuses, overall pages are getting faster,
but it's mostly due to connection speeds and faster browsers.
So we're going to take the ways that I see.
We need to keep an eye on this growth in video,
and we need to develop more best practices for that.
We need to develop a better performance metric than window on-load,
something that captures a better production of page speed.
We need to evangelize these best practices.
We can get more automated performance improvements from browsers and networks,
but that's not going to fix everything,
especially in complex websites,
where it's just too complicated to automate these best practices.
So we need to evangelize and drive the adoption of these best practices
across the web development community.
Two things that I think will help us is areas where I am looking for improvement
in browsers going forward that will help performance.
It's taking advantage of multiple CPUs.
We're already seeing this in Chrome.
I'm not sure about other browsers.
There are things like rendering web workers can be off-loaded to another CPU,
and even multiple devices now are important to use.
And another area for improvement is caching.
We've seen great improvements in caching over the last couple of years,
but we're still part of the time,
especially when people are on the mobile devices,
where their internet usage is more predictable.
And I think as we give browsers to be more personalized
and understand the model and individual's behavior,
we can give more updated caching,
and that will make websites faster for the mobile.
Oh, so that's about it.
I just wanted to mention, we've got Velocity coming up here in Santa Clara next month.
We've got Velocity in New York in October,
but for folks in Germany, we'll be over in London in November, November 13, 2015.
And you can make it there.
There can be a lot more discussions and experts about web performance.
You might want to consider that.
And with that, that's it.
So I'm happy to stay online for as long as you guys want for a question.
Thank you.
Can you hear me?
Oh, I can hear you.
So my name is Thomas. I'm from Keynote Systems.
I totally agree to your point that we are lacking a better metric
or as a completion event with performance monitoring.
But also I disagree with your statement about the synthetic monitoring.
My question is, why didn't you limit yourself in your application
with these minor K measurements?
Because the simplest and best practice for performance monitoring
is to use at least three locations for that.
Yeah, so that's a really good question.
And one, I want to give a shout-out to Keynote Systems.
I've spent some sort of velocity from the very first event over five years ago.
And of course, Keynote does a lot of work in performance, a lot of great work.
And I think I'm speaking at your press work about how you can actually
so you have a small spot in the parking lot.
Yeah, so I can think of it.
The HD archive is a non-profit, you know, un-funded project.
I'm the only one really working on it.
That means it does a lot of work, actually, too.
I use what the HD has to do with it.
And so it's just a matter of resources, you know, what we think.
More hardware, more logs, more boarding.
Or maybe it's going to cross multiple locations.
But even with that, you know, that's something that we hope to grow.
What HD has to do with over 50 locations worldwide,
and it's starting to match that with multiple browsers instead of just IE.
You know, that would just require some renewal aid
and some improvements in our charting.
But even with that, you know, I've been using synthetic testing for a long time.
And in my experience, synthetic tests are usually,
the times that you get out of them do not reflect the real world.
Most of the time, the synthetic times are about twice as fast
as what really uses our experience.
Now, if you keep that in mind, and you can do that with your deputy,
you can say, well, we want to do synthetic testing
because it helps us with speed index.
We can integrate it whenever we do a build.
We can integrate it into our build process
so we can catch performance regressions much earlier.
All of that is really good.
The problem is, when you share those numbers outside of the desk,
and even if you put a foot sign, it tells these are synthetic times,
these are not necessarily accurate, what real users are experiencing.
People don't read the signals.
They don't keep that in mind.
And that PowerPoint slide, or that internal email,
it's working around and around and around
until eventually the CTO is replaced
while internally the site is simply one and a half seconds past.
But externally, it's being measured and reported
by these external sources as being three or four seconds.
And so it causes its confusion.
So synthetic testing is great.
But for the actual performance for users,
I don't think it is that well for the real users.
More questions?
Excuse me?
More questions?
Sorry, I have another question.
Regarding the issue that Windows on Build
is not a very good indicator of page load time.
I think I recall the blog post by you,
which was some kind of call for action,
probably pointed to browser manufacturers.
Do you see any progress there?
Do you hope that we can see something better
available via run data soon?
Yeah.
So, Kat
includes information about the paint rectangle.
And so he's actually re-implemented this feedback algorithm
using these event messages about paint with paint load.
And soon after these run a bunch of tests side by side
with the old algorithm, the new algorithm,
and they're very highly important.
So he can actually measure speed index in the browser.
He doesn't even have this external monitoring.
Now, the problem is in Chrome,
there's two problems.
One, Chrome is the only one firing those events.
The other problem is those events are not visible
to JavaScript.
They're only visible to extensions inside the Chrome.
So we're working with the Chrome team
to see if we can make those events visible to JavaScript.
And we can do that without harming the browser performance.
So, you know, if you had a million of these events
firing during a typical page load,
you could imagine that that would slow things down,
especially if someone was listening to those events
and doing some computation on them.
So, I think I'm pretty confident that we'll have something there.
I don't know if I'm actually European, you see one.
He's got a working human patient,
and so it's just a matter of figuring out how we can do that
in real travel without harming the user's experience.
And then it's complicated because this really involves rendering,
and there are different rendering engines on the browsers,
so we would like to make it a stinger,
but that's only to run into some difficulties
where perhaps some of the browser's rendering engine
isn't able to publish those events.
We can't do it in their common fashion.
We can't do it in a way that doesn't harm
the experience.
So, we are making part of this there,
but it's still early on.
Any more questions?
Thank you, Steve, for your time.
Okay.
Thanks for tolerating all these technical issues.
We're going to be sorry about that, but finally we made it.
Yeah, it was great to be here.
I think it was Google's problem.
I noticed, at least for me, there was a new Google regroup site
that came out over the last week,
so maybe there was something about visibility of accounts
or something like that that changed.
But I'm glad we got connected.
Finally made it.
So, thank you.
Have a round of applause for you, and thank you so much.
I'm going to go to work.
You guys have another beer.