6 ms·

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

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.

writepub 8y ago
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.
- spiralganglion 8y ago
  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.
  - goldenchrome 8y ago
    To many people, programming isn't a craft. It's just a way to get things done.
    - arbie 8y ago
      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.
  - mLuby 8y ago
    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.
  - reidjs 8y ago
    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.
  - C1sc0cat 8y ago
    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.
untog 8y ago
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.
- ip26 8y ago
  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!
- megy 8y ago
  Most of them are probably images.
devwastaken 8y ago
50KB isn't hard to reach, because CSS rules are very repetative. Compressed, it shouldn't be 50KB, no.
onion2k 8y ago
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/ https://csswizardry.com/2018/11/css-and-network-performance/
- megy 8y ago
  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.
  - onion2k 8y ago
    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.
- scns 8y ago
  Thank you for sharing this, looks great at first glance.
craftyguy 8y ago
Eh, the 'trick' is to discard javascript. You can build a functional website without it.
- Moru 8y ago
  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.
  - mcintyre1994 8y ago
    Is this what NextJS does? I assume you couldn't do that without Javascript either way right?
    - wlkr 8y ago
      I think it could be done with iframes but it wouldn't be pretty.
  - codedokode 8y ago
    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.
mikekchar 8y ago
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 :-)
seanwilson 8y ago
> 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.
- cheschire 8y ago
  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.
  - seanwilson 8y ago
    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.
    - im3w1l 8y ago
      Hackernews has 7KB of css - 2KB with compression. The html for this document is 200kb - 30kb with compression.
      - seanwilson 8y ago
        I meant hypothetically; sites where most users visits many pages.
- 8y ago
quantummkv 8y ago
> 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.
- Moru 8y ago
  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.
- emerongi 8y ago
  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.
  - quantummkv 8y ago
    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.
Lukas_Skywalker 8y ago
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...
- criddell 8y ago
  If I'm pulling the page over an encrypted connection, is there any opportunity for caching?
  - acdha 8y ago
    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.
- acdha 8y ago
  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.
- codedokode 8y ago
  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.
manigandham 8y ago
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.

writepub 8y ago

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.

spiralganglion 8y ago
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.
- goldenchrome 8y ago
  To many people, programming isn't a craft. It's just a way to get things done.
  - arbie 8y ago
    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.
- mLuby 8y ago
  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.
- reidjs 8y ago
  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.
- C1sc0cat 8y ago
  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.

untog 8y ago

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.

ip26 8y ago
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!
megy 8y ago
Most of them are probably images.

devwastaken 8y ago

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

onion2k 8y ago

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/ https://csswizardry.com/2018/11/css-and-network-performance/

megy 8y ago
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.
- onion2k 8y ago
  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.
scns 8y ago
Thank you for sharing this, looks great at first glance.

craftyguy 8y ago

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

Moru 8y ago
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.
- mcintyre1994 8y ago
  Is this what NextJS does? I assume you couldn't do that without Javascript either way right?
  - wlkr 8y ago
    I think it could be done with iframes but it wouldn't be pretty.
- codedokode 8y ago
  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.

mikekchar 8y ago

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 :-)

seanwilson 8y ago

> 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.

cheschire 8y ago
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.
- seanwilson 8y ago
  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.
  - im3w1l 8y ago
    Hackernews has 7KB of css - 2KB with compression. The html for this document is 200kb - 30kb with compression.
    - seanwilson 8y ago
      I meant hypothetically; sites where most users visits many pages.
8y ago

quantummkv 8y ago

> 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.

Moru 8y ago
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.
emerongi 8y ago
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.
- quantummkv 8y ago
  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.

Lukas_Skywalker 8y ago

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...

criddell 8y ago
If I'm pulling the page over an encrypted connection, is there any opportunity for caching?
- acdha 8y ago
  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.
acdha 8y ago
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.
codedokode 8y ago
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.

manigandham 8y ago

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.