Hacker News new | past | comments | ask | show | jobs | submit login

Connection count multiplied by number of bytes transferred.

That would get rid of the cruft on the web in a heartbeat.

Every SEO consultant would suddenly have an actual job, playing code golf on CSS and HTML to deliver the content in the minimum number of bytes possible.




Google already wrote AMP which parses page content and presents the user with Google's ideal version of the page. Just include the delta in the ranking. The more a page has to be "cleaned" by AMP the lower it ranks.


That’s... not really what AMP does.

I mean, kinda, but not really. You have to cater to it specifically


Yeah good point. In general something like that could still work though. Whatever characteristics of a page Google is trying to "fix" with AMP could just be added to the ranking algorithm.


Absolutely


Exactly, make it an internal delta signal thing rather than pushing it externally on the entire web. Yes they can because of their position and size, but should they? No they shouldn't.


Clever!


This penalizes data-heavy websites, though, no? For example, I can see how a photojournalism piece with lots of photos would be ranked to hell, whereas a content-free text piece would be ranked very highly.


But on the same subject all pages would be data heavy. Only where a data heavy page would compete with a similar page that was lightweight would the one be ranked above the other.

But your average news page would weigh in roughly the same no matter what the source was. Assuming you'd strip out all the cruft.

For reference, I optimized my website a while ago and ended up with the average page being < 15K.

https://jacquesmattheij.com/the-fastest-blog-in-the-world

Try it, on any connection in normal use today it should load faster than you can blink.

Add a few pictures and it would still work quite comfortably.


> But on the same subject all pages would be data heavy.

Not all of them. For a trivial example, an in-depth article about a topic would be penalized more than a more epidermic one, because it would contain more text, graphs, etc.

> For reference, I optimized my website a while ago and ended up with the average page being < 15K.

I feel you, I absolutely hate that my website uses a bunch of stuff for almost no reason. 80 KB of CSS or 90 KB of font isn't awesome, and I started a project to provide information on how to create lighter websites (https://www.lightentheweb.com/, stalled a bit).

All I'm saying here, though, is that the solution is more nuanced than "heavier = lower". AMP is definitely not a step in the right direction, though. I wonder if Google could give sites that used a specific CSS file and no JS a bump, rather than loading things on their own domain.


> For a trivial example, an in-depth article about a topic would be penalized more than a more epidermic one, because it would contain more text, graphs, etc.

But such trivial examples should be trivial to get right no? It's all about the relative weight of the various factors that determine the ranking and a 'lightweight' article could be recognized as such.


Well, that's my point, it's not trivial to automatically recognize which photos are content and which are style. You want to have many content photos, but having many style photos probably means cruft.

How do you recognize which is which?


Same way almost all browsers offer a Reading view. They still show the article image. Doesn't seem to be that hard of a problem.


How does AMP recognize this right now?


It doesn't, it just forces you to display the pages through Google, stripping everything else, which is much easier to implement than recognizing if a web page's heft is because of legitimate content or ads.


So what difference would it make? After all, this is the result after AMP has done all its cleaning, which would give you a pretty accurate measure for page weight. What remains is the actual content of the page. It's the cruft that should be penalized, not the actual content.


Exactly what my sibling comment said, it's the publisher (presumably a human) who does the cleaning. It's not as easy to get a bot to clean things up and then measure weight, and the various "Readability" views aren't always correct (they're using heuristics).

Sounds like a publisher-assisted "readability view" would solve both problems, though. It would allow the user to view a "lighter" version of the page and search engines could just measure how large the "non-light" version is and penalize accordingly. I'm afraid that would incentivize the publisher to put ads and other crap in the "light" view, though.


AMP doesn't do the cleaning.

You as the publisher/author have to implement an AMP page yourself and then alert Google of its existence.


A photojournalism page would have a low connectivity count. It wouldn't be connecting to various other 3rd party websites


Most useful content on the web is text. Photojournalism is a niche exception and those pages could be linked to from articles.

A lot of the useless pages are 3 stories of scrolling through large images with very little text.

Also, "data" as in tables and small/vector charts isn't all that big.


> Most useful content on the web is text

Tell that to a photographer, designer, artist, illustrator, etc


I would, their requirements are niche. Most people need text, possibly with one or two small photos or illustrations.


Think you may be looking at this only through a developer lens. Bet if you showed anyone under 15 an internet without pictures and video they'd consider it broken.


Weight photos differently to js?


What does the connection count bring anything? All that matter would be the total number of bytes transferred.

I don't think that would be a good metric for relevance though and in most case, the total size isn't an issue. Which is why AMP is good, low file size when it's needed, full size when it's not.


Connections^2 to penalize the worst offenders with 20+ cross site scripts most.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: