Are websites getting “fat”? Page weight, HTML size & Googlebot limits explained

[MUSIC PLAYING]
GARY ILLYES: Hello, and welcome to a new episode of "Search Off
the Record," a podcast coming to you from the Google Search team.
I am Gary today.
And I think I'm joined by our Martin, who I call Morty.
Hello?
MARTIN SPLITT: Hello, yes, I'm here.
Morty is here.
I don't know, Rick.
I don't know.
GARY ILLYES: Why do I call you Morty?
I call you Morty, but I don't know why.
MARTIN SPLITT: I do not remember.
I think at some point, you started singing "O Tannenbaum,"
but with, like, (SINGING) O, Mortimer, O, Mortimer, [GERMAN].
GARY ILLYES: Oh, so nice!
MARTIN SPLITT: You're not here to talk about my eye color
though, I think.
GARY ILLYES: I mean, we could talk about it for half an hour,
for sure.
But I think not.
I'm afraid that while our customers would
be very interested in that topic, I am not.
So I don't have a topic.
So I looked at what you prepared.
MARTIN SPLITT: Yeah.
GARY ILLYES: And it's weird.
MARTIN SPLITT: You don't like my topic.
I know.
GARY ILLYES: So you're coming in hot with a question-- looking
at the notes now.
The first question is, are websites getting fat?
MARTIN SPLITT: Yeah, I think that's a reasonable question.
GARY ILLYES: OK.
I think this question is not even meaningful.
MARTIN SPLITT: Ooh, look at you!
Why is it not meaningful?
GARY ILLYES: Because it does not matter,
in the context of a website, if it's fat.
MARTIN SPLITT: Why?
GARY ILLYES: In the context of a single page, yes.
MARTIN SPLITT: Oh, nice!
GARY ILLYES: But in the context of a website,
it really doesn't matter.
MARTIN SPLITT: Ah, that's an interesting one.
Cool.
OK.
So we can talk about either things or both things.
We'll see if time permits.
GARY ILLYES: Yeah.
MARTIN SPLITT: We can talk about websites
or we can talk about web pages.
Do you want to do that?
GARY ILLYES: So I think, first, we step back a little
on another word.
And that would be "fat."
MARTIN SPLITT: OK, fine, yeah.
That's a bit--
GARY ILLYES: OK.
Let's start again.
Are websites-- or web pages-- getting fat?
What is fat in that context?
MARTIN SPLITT: That's a really nice one,
because I struggle with it.
And I kind of posed it in a stupid and not great way.
And I used "fat" for that, because heavy, big, large?
I don't know which term to use because I realized recently,
when I asked on Bluesky, that people are understanding
different things when it comes to--
s it page size.
GARY ILLYES: OK.
MARTIN SPLITT: What is page size?
It's a surprisingly difficult answer.
GARY ILLYES: Well, an individual page's size can be defined.
MARTIN SPLITT: Yeah, yeah, yeah.
GARY ILLYES: Because the raw bytes, that's easy.
MARTIN SPLITT: Ah.
But that's not what everyone talks about when they mean size.
That's what some people talk about when they mean size.
GARY ILLYES: Right.
MARTIN SPLITT: And that's the rabbit hole I fell into.
GARY ILLYES: [LAUGHS] So what you are thinking here
when you say fat is basically the raw bytes from the parent
HTML, plus the resources that need to be brought in,
plus any media.
MARTIN SPLITT: Maybe.
GARY ILLYES: OK.
MARTIN SPLITT: I started at a slightly different position
where I asked myself, like-- so back in the days
when I started making websites, I had dial-up internet.
So I couldn't be online all the time.
So some of that happened on my hard drives
locally with the file and the text editor.
GARY ILLYES: Yeah.
MARTIN SPLITT: Then I needed to transfer
that between the computer that was actually hooked up
to the internet and my laptop, because sometimes I
was working on my laptop.
And I had a really old, really, really old laptop.
It didn't even have USB.
It sounds super stupid.
But the only reasonable way I could transfer data
was with floppy disks.
GARY ILLYES: OK.
MARTIN SPLITT: I know.
And I realized that some--
GARY ILLYES: I was living in the same era.
So yeah, I distinctly remember this.
MARTIN SPLITT: Yeah, but John, for instance,
also lived in the same era.
And he is like, who thinks of floppy disks?
So I thought I'd explain--
GARY ILLYES: I'm pretty sure our boss, John Mueller,
was born roughly when the pharaohs were still
running around, but anyway.
MARTIN SPLITT: He was probably here
when electricity was invented, yes.
GARY ILLYES: Yes.
MARTIN SPLITT: But-- hi, John, if you're listening.
But I realized that I usually, even
if I built relatively elaborate things,
except for if I had to transfer images,
then the floppy was problematic.
But otherwise, with just HTML and maybe some CSS,
and maybe even some JavaScript, it worked fine.
And a floppy disk would fit more or less the whole website,
minus images, which was fine because images sometimes--
back in the days, I had no notion of copyright.
So I just hot-linked, effectively,
to images of other websites.
So it wasn't really transfer size that I had to deal with
or that I needed web space for.
But then I read the 2025 Web Almanac, which is great.
We're going to link that in the description as well.
It's a great look at how the web is changing
and how websites are changing.
And they found that in 2015, the median mobile home
page was 845 kilobytes.
And that's the data that needed to be transferred
over the network into the browser, onto someone's disk.
That's how they define page weight.
GARY ILLYES: And that is just a parent page?
MARTIN SPLITT: That's just the home page.
That's just, like-- they are only looking at home pages,
I think, from the crawl.
GARY ILLYES: OK.
But that's just the parent page.
It's not the resources?
MARTIN SPLITT: Yeah, yeah.
See?
That's where I'm not so clear about their definition of page
weight.
That's really interesting.
They have a paragraph where they are trying to explain
what they mean by page weight.
That's why I used fat, to just blatantly call out
that I don't understand the differences in what these things
are.
So they say, "Page weight, also called page size,
is the total volume of data, measured in kilobytes
or megabytes, that the user must download to view a specific
page."
In my book, that includes images and whatnot.
GARY ILLYES: Yeah.
MARTIN SPLITT: Because I have to download that to see.
And that's why I was surprised to hear that, 2015,
that was 845 kilobytes.
That, to me, was surprising.
GARY ILLYES: Why?
MARTIN SPLITT: Because I would have assumed that with images,
it would be more than 800 kilobytes.
GARY ILLYES: Ah, I see what you mean.
MARTIN SPLITT: Right?
GARY ILLYES: Yeah.
MARTIN SPLITT: But anyway, 2015, 11 years or longer,
depending on when you hear this, 845 kilobytes.
July 2025, the same median page is now 2.3 megabytes.
GARY ILLYES: Holy-- that's three-times growth.
MARTIN SPLITT: Yeah.
And it goes roughly from a little more than half
a floppy disk to almost two.
It's almost two floppy disks.
GARY ILLYES: Almost two.
MARTIN SPLITT: Yeah, floppy disk was able to--
under normal circumstances, 1.44 megabytes, I think.
That surprised me, because I knew it was growing.
I knew we were also doing more complicated things.
I mean, obviously, if you basically
built AutoCAD, a software that does computer-aided design
in the browser, then, yeah, that's not
going to work in 800 kilobytes.
GARY ILLYES: Yeah.
MARTIN SPLITT: How?
But then again, on the median, I would assume that a lot of it
is just websites.
And that is quite big.
GARY ILLYES: Yeah.
MARTIN SPLITT: When you ask people what they think,
if this is big or not, you start getting very different answers
depending on how they think about page size.
And there is no one true definition of it.
GARY ILLYES: So I think, based on what
you said, that we probably need to do a better job at explaining
what page size is.
And if you look at our documentation about crawlers--
I think about Googlebot, but I could be wrong--
we say that, by default, we fetch
15 megabytes of the content, of the raw bytes,
from a specific URL, and then we stop.
And that's per URL.
So basically, if you reference stuff in your HTML,
then those have their own 15-megabyte limit, right?
MARTIN SPLITT: Yes.
GARY ILLYES: And that to me, from a search perspective,
not from a user's perspective, that makes more sense.
From a user's perspective, it probably
doesn't make sense because, well, they don't care.
Why would they care about it?
It's like, what do I need to download--
MARTIN SPLITT: I need this document, full stop.
GARY ILLYES: Yeah.
But I imagine that we could propose
a change in the documentation for the HTTP archive or the web
almanach to better explain what page weight is.
MARTIN SPLITT: I mean, I wouldn't
change their documentation, because for their purposes
and intents, I think they're explaining what it is.
And they're defining it rather well.
I'm just surprised that with all the resources that go onto
my disk at the end, it used to be only 800 kilobytes,
800-something kilobytes, in 2015.
GARY ILLYES: Sure.
MARTIN SPLITT: But I don't think that the page weight or the page
size or whatever--
let's phrase it differently.
When I think about page size, I, depending on the context,
think about different things.
GARY ILLYES: Yeah.
MARTIN SPLITT: And I realized that when
I asked this question publicly that different people had
very different notions of how they understood page size.
Depending on the layer you're looking at,
it gets confusing as well, because there's also
compression.
So some people are like, ah, but this website
downloads 10 megabytes onto my disk.
And I'm like, yes.
And they're like, but the internet is slow here.
And I'm like, but maybe, if you look
at what actually goes over the wire,
you might find that this is five or six megabytes, not
the whole 10 megabytes, because you can compress things
on the network level.
And then you decompress them on the client side level,
which, again, if you are strapped
for space on your phone, for instance, which, in the past,
my phones typically, because I took so many pictures
and videos and stuff and I was really, really
bad at deleting things.
I'm kind of like a digital hoarder
sometimes, especially when it comes to my phone.
I ran out of disk space.
As simple as that.
And so you want me to install an app?
Nah, this app is, like, seven megabytes.
I don't have seven megabytes.
GARY ILLYES: Yeah.
MARTIN SPLITT: So then the compression
is nice for reducing the transfer time.
But I don't care as much.
I care more about the space on my phone
that it actually occupies.
So I have a different angle on this,
depending on what I'm looking for myself.
And then it gets worse.
Have you looked at the HTML version of the HTML standard?
GARY ILLYES: No.
[LAUGHS]
MARTIN SPLITT: It's funky.
I never really fully understood why they have a one-page version
and they have a multi-page version.
GARY ILLYES: OK.
MARTIN SPLITT: But if you look at what you have on your disk
once you download the single-page version of the HTML
specification, you end up with 14--
1-4, 14 megabytes-- of HTML.
GARY ILLYES: That seems reasonable.
MARTIN SPLITT: It's text with a bit of extra sprinkles on top.
That's huge!
GARY ILLYES: And it's not even a fancy website.
I think you are talking about the WHAT working group,
the WHATWG.org or something, WHATWG, right?
MARTIN SPLITT: Yes.
GARY ILLYES: If you look at that spec, the HTML spec on WHATWG,
it is not a fancy website.
It is really just text with some default styling, nothing else.
So yeah, 14 megabytes, that really
means raw content, basically.
MARTIN SPLITT: That is wild.
And I'm not sure if they have images in there.
I don't think they do.
But maybe they have some explanatory diagrams
or something.
I don't know.
But, 14 megabytes, that is a lot.
And I know that I've seen websites
out in the wild that are quite heavy,
just the HTML that gets transferred as well.
And I know some extreme cases-- and I've heard of extreme cases
through the Bluesky question that I asked and the replies--
where people are in-lining images.
So you can turn an image into, effectively,
a very long string of characters and put that straight
into your HTML, quote, unquote, "to avoid having to do another
network request and fetch that image."
So you're embedding images and stuff into the HTML.
And then obviously, you end up with a 50-megabyte HTML file.
GARY ILLYES: So while you were talking,
I found the single-page version of HTML living standard.
And when you finished your sentence,
that's when I clicked the link to the one-page version.
And it just finished loading.
MARTIN SPLITT: [LAUGHS]
GARY ILLYES: So basically, that was, like, what?
About 45 seconds, more or less?
MARTIN SPLITT: Yeah, yeah.
GARY ILLYES: That's a lot.
MARTIN SPLITT: I know.
GARY ILLYES: And I'm on a fast connection, so.
MARTIN SPLITT: It gets wilder.
If you use Print to PDF in Chrome,
you get a 96-megabyte file, I think, or I got one.
And then if you look at the PDF version
that they offer, it's, I think, 15 megabytes?
Wild.
GARY ILLYES: I mean, different kind of compression.
MARTIN SPLITT: Yeah.
I think it's interesting to see, the PDF version of web pages
oftentimes are either a lot smaller or a lot larger.
And this one is-- you can tell, this is really dense content.
GARY ILLYES: Do you think stuff like the reader mode
alleviate anything on the user's side?
MARTIN SPLITT: Ooh, I don't really
know what the reader mode--
I know what it does from a user's perspective.
But I don't know what it does in the background.
GARY ILLYES: I was thinking about it a little bit
a while ago.
And my conclusion was that it doesn't change much,
from a loading perspective, at least,
because you still have to first get the resources.
And then the phone or the app does some magic locally
to remove fluff and present you with a more readable version
of the page.
But it at least makes the internet kind of more bearable
to enjoy.
MARTIN SPLITT: Yeah.
GARY ILLYES: Wow.
I used two weird words together.
But trying to think about it holistically,
do you think that this even matters,
what the weight of a web page or a website is?
Which we still haven't clarified, by the way.
MARTIN SPLITT: Correct, yes.
GARY ILLYES: Because for example, for me at home,
I have a 10-gigabit connection.
MARTIN SPLITT: Yeah.
GARY ILLYES: Right?
MARTIN SPLITT: I have a 10-gigabit fiber here as well.
GARY ILLYES: Yeah.
And I don't feel the pain.
For example, if something is, I don't
know, what did you say, 96 megabytes or whatever for a PDF
file?
It will still come down in a relatively short period of time.
And at that point, it's dependent on the server that's
sending the stuff, not on my connection.
So to me, it really doesn't matter that websites
are getting bloated.
On my phone also, I have permanent 5G from Swisscom,
my phone company.
So again, it is super fast.
It really doesn't matter.
It just comes down like that, in a snap.
MARTIN SPLITT: Ah, that's nice.
Ah, sweet summer child.
I'm so happy for you.
GARY ILLYES: Yeah, right.
But I live in a bubble, right?
MARTIN SPLITT: Yes.
GARY ILLYES: But I do travel a lot.
And then if I go to less developed countries,
for example, then suddenly it becomes problematic,
because the cell phone towers will advertise that they have
5G.
But in reality, they have a really weird, I don't know,
3G or something, not even 3G.
Yeah, I guess it depends on where you are living
and what kind of connection you have as well.
MARTIN SPLITT: It's wild.
I remember when we went diving in Antarctica.
We were on this ship where we had a metered satellite
connection.
And I believe, if I'm not mistaken, what did I pay for?
100 megabytes.
100 megabytes, which, again, the spec for HTML is 15.
GARY ILLYES: Yeah.
MARTIN SPLITT: So just to keep that in mind, I
think $20 or something?
GARY ILLYES: Yeah, yeah.
MARTIN SPLITT: So it was expensive, yeah.
And that made me think about things.
Like, I activated Data Saver mode on my phone.
I set the connection to metered.
I did not open things.
Like, most of the social media apps, I just never opened,
because they would suck this 100-megabyte dry in minutes.
So I think it still matters.
But it begs the question, at what level is
what kind of weight acceptable?
GARY ILLYES: Right.
MARTIN SPLITT: And I don't have a good answer to that.
And then on Bluesky, I got into this conversation
about HTML size.
So in this case, there's a document that is 15 megabytes.
And we both agree that pretty much, most of these 15 megabytes
are actually useful content, because there is not
much in terms of images or stylesheets or whatever.
It's just pure HTML.
And it's minimal markup around maximum content.
GARY ILLYES: Yeah.
MARTIN SPLITT: And then people were like, yeah, well,
in that case, it's kind of OK to have 15 megabytes of HTML
that you need to deal with.
And we both know that our browsers, even on our relatively
latest technology, laptops and fast internet connections,
take a while to process that 15 megabytes of HTML.
Actually, I wonder how much goes over the wire,
because I'm pretty sure there's compression involved.
Oh, god, OK.
I tried to also open this page in reader mode
and that kind of crashed the browser tab.
Great.
So in this case, it's kind of acceptable.
But then, what if the markup is only overhead?
And I mean, what do you mean?
It's like, well, if it's like five megabytes,
but it's only very little content.
Is that bad?
Is that worse as, in this case, the 15 megabytes?
And I'm like, that's tricky, because then we
come into this weird territory of the ratio between content
and markup.
And I said, well, but what if a lot of it
is markup that is metadata for some third-party tool,
or for some service, or for regulatory reasons,
or licensing reasons or whatever?
GARY ILLYES: Yeah.
MARTIN SPLITT: Then that's useful content, but not
necessarily for the end user.
But you still have to have it.
It would be weird to say that that is worse than the page
where the weight is mostly content.
GARY ILLYES: You know, this is interesting,
because historically, I have some beef with structured data,
for example, because--
I mean, this is a very long thing, or long-running thing,
because at one point, early in Google's life,
Sergey Brin, one of our founders,
said that computers should be able to figure out anything
from the text that they receive.
So site owners, slash, back then, webmasters,
wouldn't need to provide anything extra.
And the context was something around spam.
And then structured data comes in.
And structured data is specifically not for users.
It is specifically for machines.
And depending on how much structured data
you add to a page, it can increase the bloat considerably.
If you look at, in our documentation, what kind
of structured data Google supports, it's a lot.
You can fill a page, easily, with just the links
to the documentation.
And then if you keep piling on structured data on your pages,
basically stuff that users will never actually see, then what?
Is that good?
Is that bad?
For the site, it's probably good,
or it can be good, because it can
bring in additional traffic through whatever magical stuff
search engines might be able to show
based on the structured data.
But for the user?
I don't know.
MARTIN SPLITT: Yeah.
GARY ILLYES: Well, this begs the question--
and it came up in discussions at IETF, IETF
being the Internet Engineering Task Force,
basically, who create the standards for the internet--
whether we should think about separating, holistically,
in general, separating metadata stuff from user-visible content.
What if we would have something like, for clients, HTTP clients
that you trust, you would expose an API sort of endpoint
on your site where you just give the metadata that they
would want, right?
MARTIN SPLITT: Yeah.
GARY ILLYES: Like, in an ideal world,
that is not the most insane idea.
For example, if you had the HTML standard,
all the text for an LLM is irrelevant.
It would process the stuff differently than you and I.
MARTIN SPLITT: True.
GARY ILLYES: Wait, can you read?
MARTIN SPLITT: I can read sometimes.
GARY ILLYES: You can read, right?
OK, just checking.
And you could have something like append parameters,
like, question mark output equals json-ld, let's say.
MARTIN SPLITT: Yeah.
GARY ILLYES: And then if the client
is trusted, say through cryptographic authentication
or something like that, then you would serve the machine
purely machine-readable version, even in binary format.
Doesn't matter.
But then, unfortunately, this is a utopistic thing,
because not everyone on the internet is playing nice.
MARTIN SPLITT: That's true.
GARY ILLYES: We know how much spam we have to deal with.
On our blog, we say somewhere that we catch, like,
40 billion URLs per day that's spam, or some insane number.
I don't remember, exactly.
But it's some insane number, and definitely billions.
Will that just exuberate the amount of spam
that search engines receive and other machines receive?
Maybe.
I would bet $1.05 that will actually
increase the amount of spam that search engines and LLMs
and others ingest.
So yeah.
MARTIN SPLITT: Yeah, and I think that's an interesting--
there was this principle that was quite popular in the early
2000s, early 2010s, hypermedia as the driver of application
state or something like that, where the idea is to have
separate URLs with different representations depending on who
consumes it.
And I think, generally, that makes sense.
And you can do this to whatever degree.
But I'm not seeing it happening as much anymore.
GARY ILLYES: I don't know how much
sense it makes, because one of the things that we had when--
what is it called?
Mobile-first, mobile-first indexing.
One of the things that came out of that
was lots of documentation based on stuff
that we observed when we were trying to switch over sites.
And one of the--
actually, do we still have the documentation
for mobile-first indexing?
We might actually have this still, if it's there.
But one of the things that we noticed
is that there's no parity between the mobile version
of a website and the desktop version of a website
if there's different URLs for the two.
So mobile would be martinsplitt.com/m/content.
And then the desktop version would be
martinsplitt.com/content.
MARTIN SPLITT: Yeah.
GARY ILLYES: And for a very large number
of pages that we observed, there was
no parity between the content, or no exact parity.
Content was missing.
That was the worst, because then you're
not going to rank for the stuff that your desktop version was
ranking before.
And then we had outreach campaigns about it.
But then links were also missing.
To me, that's harder to explain.
MARTIN SPLITT: That's bad.
GARY ILLYES: And the navigation was different.
The whatever was different.
Metadata was missing.
Hreflang was missing.
Link elements were missing.
And yeah, it was a pain in the--
MARTIN SPLITT: Lower back.
GARY ILLYES: --lower back, thank you.
Otherwise, Lisa, our producer, makes me rerecord stuff.
And, yeah, so even for trivial stuff
like a mobile version and the desktop version of a web page
served under different URLs, even
for trivial stuff like that, there can be large differences.
So wait, I want to go back to the first question.
MARTIN SPLITT: OK.
GARY ILLYES: The question that got us here, basically,
in this really, really deep and dirty, dirty hole,
are websites getting fat?
MARTIN SPLITT: I think if we rephrase it to,
are web pages getting larger, I think that is true.
GARY ILLYES: Yeah.
MARTIN SPLITT: The answer is yes.
Is that a problem?
I think that depends on the context,
because we identified that some people are constrained
by either slow internet connections--
and that can hit us here in Switzerland as well.
I know in some parking garages, I have very bad reception.
GARY ILLYES: Oh, yeah.
You are in an atomic bunker and then you don't have reception.
It's like, oh, I will cry you a river, Martin.
MARTIN SPLITT: Correct.
I was very surprised and not very happy with it.
Correct.
[LAUGHS] So internet connection speed is still playing a role.
And I think, in the last couple of years,
the increase in transferred byte size
has outgrown the increase in transfer speeds,
if you look at the median transfer speed increase
for mobile connections.
I think so, as a hypothesis.
I would have to check the data.
But I feel like that's the case.
The other thing is, there are mechanisms to alleviate
this, like caching.
So of course, you get the full painful hit
in the first place, the first time you visit the website.
But for instance, the HTML specification uses caching.
So when I reload, I don't have to download all the 15
megabytes again.
GARY ILLYES: Yeah.
MARTIN SPLITT: Compression on the transport level,
on the network level, helps as well,
because then you have less data that you need to transfer.
You still have as much data to store on the user's device
or on the crawler's end.
So yeah, that's only helping you so far.
But there are ways to make this less painful.
There's also this lazy loading thing,
where you can say, OK, so there's
a lot of heavy content, lots of images, for instance.
We're only loading those that you actually
scroll to or go to and possibly see,
rather than loading all of them in the first place.
But I still think it's worthwhile thinking about,
how much data are we throwing around?
GARY ILLYES: Yeah.
But the website versus web page distinction, do you think--
or do you agree with me now-- that the original question
is meaningless?
MARTIN SPLITT: Yes.
GARY ILLYES: OK.
That's good.
MARTIN SPLITT: You caught me there.
That's a very good catch.
GARY ILLYES: OK.
Well, it's Friday today.
So this just made my day because someone finally agreed with me.
MARTIN SPLITT: Yay!
GARY ILLYES: Do you think that we
need to do anything to reduce the size of pages
on the internet?
MARTIN SPLITT: That's a tricky one.
GARY ILLYES: And I mean you and I,
as people who like the internet and work on standards and stuff.
MARTIN SPLITT: I think, yes.
I think we are wasting a lot of resources.
And I mean, we had that in another episode,
where we said that we know that there are studies that
show that websites that are faster
have better retention and better conversion rates.
And speed is, in part, also based
on size, because the more data I ship,
the longer it takes for the network to actually transfer
that data and the longer it takes
for the processor of whatever device
you're on to actually process it and display it to you.
GARY ILLYES: Yeah.
MARTIN SPLITT: And again, if storage is a problem, then
you're excluding some people there as well.
I think, yes.
I think that makes sense.
I also think that not everyone is-- and I myself know this.
I'm now building a new website.
And I'm looking specifically for a workflow that makes it easier
for me to deal with images, for instance, because so far,
I've just been like, here is this 59-megapixel image.
I know you're on a smartphone but I don't care.
Here is the five-megabyte image.
Good luck.
Which is not the right way to do it.
GARY ILLYES: May the odds ever be in your favor.
MARTIN SPLITT: Yeah, exactly.
GARY ILLYES: For that specifically,
internally, we have a linter that prevents submission
to the developer site that we are using for the search
documentation, if the image is over one megabyte.
MARTIN SPLITT: Yeah, interesting-- arbitrary limit,
in my opinion, but, yeah.
GARY ILLYES: Well, I like to think that they came up
with that number using some methodology,
not just, I woke up and chose violence.
MARTIN SPLITT: Yes.
GARY ILLYES: And like, I was thinking about it a lot,
because it's like, should I ask for an exception?
Because our images often are, like, seven megabytes or so.
And then I was looking at the compressed
versus the less compressed versions of the images.
And my non-blue eyes could barely tell the difference.
MARTIN SPLITT: I know what you mean, yeah.
GARY ILLYES: And at that point-- on a big screen.
And at that point, does it matter
that we lost some pixels or some shades in pixels?
MARTIN SPLITT: Yeah.
GARY ILLYES: Because our images are not fine art, right?
MARTIN SPLITT: No.
GARY ILLYES: For fine art, sure.
So what's our takeaways?
Are websites/web pages getting fat?
Are they?
MARTIN SPLITT: Yes.
I think pages, yes.
GARY ILLYES: Connections are getting faster.
So does it matter?
MARTIN SPLITT: I think it still does.
GARY ILLYES: OK.
How do we fix it?
Maybe we talk about it in another episode.
MARTIN SPLITT: Yeah, sounds like a plan.
GARY ILLYES: Because there's a lot that you can do.
And I'm pretty sure that every little bit helps, not just
with search engines--
and we shall talk about that a little bit later--
but also with your users, because users definitely
do like snappy websites.
And bloaty pages don't help with that.
Agree?
MARTIN SPLITT: I agree.
GARY ILLYES: Your Honor.
You have to say, Your Honor.
MARTIN SPLITT: I agree, Your Honor.
GARY ILLYES: Thank you.
Objection!
MARTIN SPLITT: Objection.
I'm not honorable.
GARY ILLYES: All right.
Well, Martin, thank you for the chat.
MARTIN SPLITT: Thanks a lot for you.
GARY ILLYES: This was our second chat today,
because we recorded two episodes.
And I will leave you for two days-- three days,
because it's the weekend.
And on Monday, I'm not going to the office
because I don't want to.
MARTIN SPLITT: Yeah, especially if there's still snow.
GARY ILLYES: So I would like you to remember
this face and this voice and have nightmares, please.
MARTIN SPLITT: I thank you for the lovely conversation.
GARY ILLYES: But thank you nonetheless
for chatting with me.
MARTIN SPLITT: Thanks.
GARY ILLYES: If you liked this episode,
please like and subscribe wherever you get your podcasts,
and have a very nice day, please and thank you.
MARTIN SPLITT: Bye-bye!
[MUSIC PLAYING]
GARY ILLYES: We've been having fun with these podcast episodes.
I hope you, the listener, have found
them both entertaining and insightful, too.
Feel free to drop us a note on Twitter, @GoogleSearchC,
or chat with us at one of the next events we
go to if you have any thoughts.
And, of course, don't forget to like and subscribe.
Thank you, and goodbye!
[MUSIC PLAYING]