Hacker News Reader

Comment by Solar19 | Hacker News Reader

The author says you can do these things anyway without AMP, but what he doesn't get is that web developers were not doing them. It took the nudge of AMP to get decent performance on the mobile web.

He also failed to mention a key AMP rule: all CSS is in the head, a max of 50 KB. There is no external CSS at all. That's crucial. It reverses a persistent anti-pattern in web development that calls for a bunch of separate files for CSS and JS. Almost all CSS on most webpages is unused (this is still true of a lot of AMP sites -- 50 KB is way too much CSS for an article).

I think the reality here is that early 21st-century web developers are terrible at web development. They stuff massive amounts of JS and CSS down users throats, distributed across 50 or a 100 requests, and call themselves "engineers".

AMP, or something even better, needs to be the default way to build websites.

View on HN

> AMP, or something even better, needs to be the default way to build websites.

No. We don't need AMP or something else. The existing tools are more than enough. What we need are actual, trained engineers/developers on the platform.

The real problem with web performance is that any random guy with questionable or non-existent knowledge thinks he can whip up a website by mixing any library he comes across. That is fine for a personal site or some random trivial web page. However we over glorify them and appoint them in critical jobs. And then we wonder why 21st century web is horrible. insert shocked pickachu meme in here

Can you imagine what would happen if we started appointing surgeons by putting random guys through a 1 month bootcamp which consists of showing them youtube video courses? We used to do something like this in the middle ages. We also had a surgery in that era with a 300% mortality rate.

What we need are standards on who can actively work at what positions/level based on their training/skills. Just like any other critical industry.

As others here are saying, they like AMP because they as developer do not ha e final say on what goes in The product. They can only do what The boss/client tells them to do.

This isn't about engineers. This is about businesses. Up until now there apparently hasn't been a business case for fast websites.

Fast website costs a lot of money in development time. If a website loads fast enough, nobody wants to invest X amount of dollars to make it somewhat faster.

Since AMP sites are prioritized on mobile, there is now a very clear business case for supporting AMP.

Most people do not work in an Dilbertesque organization filled with pointy haired bosses. And this is a very bad excuse for all sorts of startups that are generally behind these atrocious websites. And as a startup your whole damn company is filled with engineering people.

If your management that is filled with engineering people fails to understand the importance of fast websites then the I am afraid the problem is with the engineers. Whether that is incompetence or actively cutting corners can be debatable.

Actually, most of do work in corporate dystopia. Not sure what experience you are drawing your opinion from.

Fast sites are significantly cheaper to develop, it's just a case of _not_ adding things, but that's an impossible choice to make when the website for a new channel is entirely not what the company is for.

If there are 50-100 requests on a page then the vast majority of them are crap ad network code shovelled onto sites. Most developers hate them just as much as users do.

Ironically, with the advent of HTTP2, more requests might be a better thing. Separate out bundles into per-page (or even per-component!) chunks and ensure you're only sending the user the content they need, without additional overhead.

Most developers hate them just as much as users do.

Which is one of the selling points of AMP.

Sorry Mr. Marketing VP, we simply cannot add all that crap ad network code! The AMP framework doesn't permit it, and if we stop using that we lose all our SEOs!

Most of them are probably images.

I think if more web developers understood how browsers actually render a page we'd get much better web pages. In the case of CSS, the browser won't render until all the CSS files are loaded and parsed. Having lots of them is terrible for time-to-first-paint performance. That's reason enough to inline styles in the head and only have one CSS link on a page if you want something simple, or to use media queries in links to create different contexts if you want to minimize download sizes.

CSS Wizardy (Harry Roberts) wrote a great article about this topic recently - https://csswizardry.com/2018/11/css-and-network-performance/

Ok, except the advice has been to move CSS to files for a long time, so that they can be cached easily. That way other pages are loaded quickly, since they css file is already stored on the device.

Caching is still important, but there's no point in designing a good caching strategy if the user's very first impression of the site is poor - if they don't come back then they won't benefit from caching. If you use the more advanced media query links mentioned in the article you get the benefits of a minimal first load and the benefits of caching.

Thank you for sharing this, looks great at first glance.

To be fair, industry standard practices make it harder than it should be. We're making a very simple Vuejs app in our group (first one we've done in our group although we use Vuejs in other groups in our company). Our first stab out of the gate netted us nearly 500k of JS (production build, minified, etc) -- for something that basically takes a bunch of JSON and renders pretty tables.

Now, admittedly we've obviously done something horribly wrong, and the people on our team are senior enough programmers to accept that. However, if you're right out of a boot camp, or don't have a lot of confidence, then it might be something you overlook. If you've got a manager breathing down your neck saying, "It looks fine to me! Why are you wasting time trying to shave a few KB?", it can be hard to say, "Wait! This could potentially cost us customers". Having that conversation of "If we make the customer wait an extra second, they may walk away", is tough in the best of cases.

Ideally it would be very difficult to make as bad a mistake as we've made, but it really isn't. I suppose it gives us justification for larger salaries for experience :-)

50KB isn't hard to reach, because CSS rules are very repetative. Compressed, it shouldn't be 50KB, no.

I know nothing about AMP, but isn't having the CSS in the head pretty bad for caching? An external file can be fetched once by the browser and then cached forever, while having the CSS in the head forces that part to be downloaded over and over again?

Edit: I just realize that others posted the same concerns below...

If I'm pulling the page over an encrypted connection, is there any opportunity for caching?

Yes: your device can always cache it, if you use a trusted proxy (think enterprise networks) it can be cached, and if the site uses a CDN it can be cached there as well.

It's mixed: that CSS file is only cached until the next time you change it and browsers, especially mobile ones, do not have enormous caches. As with most engineering problems the best solution is a balance: put enough CSS in the page for the document to render and either prefetch or demand-load resources which aren't as important, all the while working to keep the absolute size down so your worst-case performance is reasonable.

As an example, if you had something like an item page and a detailed viewer which the user could choose to open, the item page's HTML could have its critical CSS inline and a <link rel=prefetch> tag to tell the browser to preload the viewer's CSS so it will likely be in the cache by the time the user opens the viewer.

If you visit several pages on a single website, then yes. But if you want to scroll through AMP pages from different websites in the search results, caching doesn't help much.

AMP is unnecessary. All it would take is making site speed as a major factor in rankings and sites would get faster overnight.

We work with 1000s of publishers. Decisions about websites come from business and marketing, not from the dev team. Performance is a low priority unless it is critical.

> all CSS is in the head, a max of 50 KB. There is no external CSS at all. That's crucial. It reverses a persistent anti-pattern in web development that calls for a bunch of separate files for CSS and JS.

This means CSS and JS cannot be cached between page loads however so you're requesting the same data every time while navigating pages. It's a tradeoff against faster page loading. I'm surprised there isn't a better solution for this yet.

Also, with HTTP/2, splitting up your CSS and JS is actually a good idea because you can include only what you need on each page and the parts are cached between pages.

I think the basic problem is people including way too much CSS and way too much JS. For even desktop pages, 50KB of CSS should be enough for most pages.

I wonder if one of the user stories being addressed by AMP identifies that users don't typically visit more than a couple pages from any particular site before a style update is pushed by the developers that invalidates the cache anyways.

Well, fast initial page loads would improve the experience a user gets when they're using a search engine to find an answer, especially if they have to visit multiple websites.

For a site like Hackernews though where you probably visit many pages each visit, downloading the same e.g. 50KB of CSS every page is wasteful.

Hackernews has 7KB of css - 2KB with compression. The html for this document is 200kb - 30kb with compression.

I meant hypothetically; sites where most users visits many pages.

Caching helps if you visit several pages on the same site. But AMP might be optimized for scenario when you scroll through several AMP pages from different sites in the search results. Using an external stylesheet would only make loading slower in this case. Another problem is that on an unreliable connection external CSS can fail to load.

One trick I'm interested in trying: use external CSS if the referer is coming from the same site, otherwise include CSS inline. That way people who only view one page (a large percentage of visitors) get it inline, and people who view multiple pages get it cached.

Eh, the 'trick' is to discard javascript. You can build a functional website without it.

If you really want you can build a very fast site if you only download the part of the html that change between loads and still not break the back button. This is more work though.

Is this what NextJS does? I assume you couldn't do that without Javascript either way right?

I think it could be done with iframes but it wouldn't be pretty.

This is a hack to accelerate heavy websites. If your site is lightweight you might not need it. Or you can load such JS code later in an unobstructive fashion.

While everything you note is true, it's hardly the fault of the engineers. One cannot expect engineers to hand code css and optimize every time. These things should be handled by tools.

With the advent of css-in-js and compilers, this is slowly but surely happening.

What amp did was prove at scale, and with tooling, that performance can be achieved. That philosophy is dripping into other tools.

In some cases, sure, it's not the fault of engineers — if an engineer is in an environment where they're not able to take the time to do things right.

In some cases, it is the lack of tools.

But I think it's often not either of those, and it is in fact the chosen priorities of the engineers. A lack of attention to craft.

We see a similar split in GameDev. Some game developers (Carmack, Blow, Acton) sweat every millisecond and byte and cache hit. If you work on engines in AAA, that's a job requirement. Others are happy to use Unity (etc), never optimize, and don't mind that their simple 2d platformer is bloated and wastes cycles. But many simply don't care — why spend time cutting down on bloat and waste when the game plays well enough.

I see plenty of engineers who have a "it works, ship it" mentality. To me, that's not the attitude of someone who cares about their craft.

To many people, programming isn't a craft. It's just a way to get things done.

It's a combination of the tooling getting better, and expectations/parceling for a product solidifying at a higher level in the org chart. "Engineers" are devolving into technicians as a result.

I see plenty of engineers who would love to keep polishing their work far after PMs and other stakeholders have decided it's good enough to ship. Some even do it after hours.

I think a lot of people program at work purely for monetary reasons. For this reason they follow the “it works, ship it” mentality because then they can focus on other tasks to make money from. If a sluggish program makes a million dollars but a beautifully written program makes 0, which shows more better craftsmanship? Admittedly that’s an unrealistic situation, but people have different motivations for coding.

I am afraid that a lot of web devs don't care about speed at all they just use the trendy frame work.

This is from direct experience working with many major brands to improve their sites - its not improving at all.

Reply on news.ycombinator.com