Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Neither PWA nor AMP are needed to make a website load fast

tonsky.me

Post reply on HN
Print view View original

61–70 of 225 posts

Re: Neither PWA nor AMP are needed to make a website load fast

#61

Post by osrec »

Brahma111 wrote: post #56
osrec wrote: post #5

But you do need "PWA" if you want your site to work offline. PWAs were never really sold as something that would make your site's initial load time faster. Not really sure how the author got that impression. It's almost like saying "you don't need jQuery to make your site faster" - to those who understand the purpose of jQuery, it's a bit of a nonsensical statement.

Moreover..PWAs are not meant to replace websites. They are meant to replace Mobile Apps. Almost all business apps can be replaced by PWAs without the rigmarole of creating an app and publishing on Apple and Google store.

I absolutely agree with you there. I bet if we ran a compression algorithm on all the apps in the app store, we would achieve a 90%+ reduction, on account of all the repeated boilerplate code!

Re: Neither PWA nor AMP are needed to make a website load fast

#62

Post by mLuby »

spiralganglion wrote: post #42
writepub wrote: post #21

Earlier quoted context omitted.

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 millis…

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.

Re: Neither PWA nor AMP are needed to make a website load fast

#63

Post by briandear »

viraptor wrote: post #10
askaboutit wrote: post #6

Wikipedia is a static delivery website. Of course it’s easy if all you’re delivering is static content. Try that with an ecommerce site where dynamic information is sent from sometimes multiple sources. It’s better to load it once and have a reactive site call just the necessary apis after. Calling everything over and over again in eCommerce is a pain for users. Unless you can afford a database and servers to be dist…

Unless you have a very active community commenting and interacting around the items, you can definitely go almost entirely static, even in ecommerce. Regenerate pages after changes happen and you'll be fine. You'll still need dynamic search most likely, but even those can be pre-generated for many terms. (Your admin / content management part needs to be dynamic of course, but that's not customer-visible) If your cata…

> You'll still need dynamic search most likely, but even those can be pre-generated for many terms.

Have you ever worked on a high scale e-commerce site? I have and what you are talking about is impractical and pretty much impossible.

Products have multiple variants, photos for each variant. Various companion products that depend on what you already selected. Pricing options that can depend on quantities or packages. And search? Spend 5 minutes on any serious e-commerce search system and there is no such thing as “common search terms.” Of course there are common searches, but on any non-trivial e-commerce system, you have potentially thousands of distinct common searches.

I was one of the original engineers for https://www.matalan.co.uk and you can’t just “regenerate” pages after changes. You can regenerate the cache for images or product descriptions, but e-commerce isn’t like a printed catalog. We put exceptional engineering into that application and to trivialize that sort of application like it was some kind of blog site kind of demonstrates a lack of experience in building something that serves millions of visitors per month — visitors that all have different paths based on what they want to buy.

Re: Neither PWA nor AMP are needed to make a website load fast

#64

Post by dvtrn »

osrec wrote: post #38
ryandrake wrote: post #32

Earlier quoted context omitted.

To put it into perspective, that's larger than the entire post-install size of the original DOOM PC video game, including all sound and artwork.

Not really - imagine if you're looking to create a fully featured video editor, complete with 3d effects and whatnot. It could well exceed 15mb to deliver all the required functionality.

Shouldn't this be a native desktop application versus foisting it onto web clients? If we're talking "fully featured"?

Re: Neither PWA nor AMP are needed to make a website load fast

#65

Post by dvtrn »

osrec wrote: post #36
dvtrn wrote: post #14

Earlier quoted context omitted.

If, however, it's 15mb of useful functionality (perhaps an app that lets you edit and encode video), then in my eyes, it's acceptable You either have an abundance of high speed internet access, or benefit from internet usage that isn't metered by the amount of data consumed, or both. Functionality or not, heavy web experiences leave out a lot of people who would otherwise be willing and capable users of %product% if…

I agree that the initial hit to download 15MB is a lot. But if we think of native apps, users would need to download them from the app store as well. If their internet is slow, both experiences are bad. Having re-read your post, you seem to have misunderstood my point. You seem to be arguing that keeping things lightweight is good. I agree with you there! But remember, for certain applications, this is not always pos…

Okay but why even are web editing applications even being pushed to the web? Why even is this hypothetical relevant for a discussion of AMP here? I understand more and more former desktop operations are being pushed to web clients but full-fledged video editors?

As I mentioned to another commenter: can you show me an example of a full-featured, web-based video editor using AMP?

I'm not sure if I can buy in that this is the example to rest upon here.

Re: Neither PWA nor AMP are needed to make a website load fast

#66

Post by seanwilson »

Solar19 wrote: post #13

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…

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

Re: Neither PWA nor AMP are needed to make a website load fast

#67

Post by zdragnar »

dvtrn wrote: post #24
zdragnar wrote: post #20

Earlier quoted context omitted.

> but perhaps can't because they're downloading 15, 20, 30MB websites just to fill out a form element? Parent post (in fact, the segment you quoted) literally says that it's okay when it is useful functionality, i.e. not when it's just to fill out a form. Sadly, these aren't going to get to experience a decent chunk of the internet anyway, since video, gifs, and images all frequently weigh significantly more when put…

Parent post (in fact, the segment you quoted) literally says that it's okay when it is useful functionality, i.e. not when it's just to fill out a form. Since when did forms become useless and what web-based video editor are you (or the original reply-er) pointing to that uses AMP?

We're talking about two completely separate types of websites. Nobody said forms are useless. Web-based video editing was a hypothetical example. AMP wasn't really part of this discussion; presumably, lots of JS + PWA functionality in the hypothetical video editing example was the referenced useful functionality.

Take Google Sheets as an example. I don't know what the total download size is for the JS (certainly not 15mb), but it's an example of a JS heavy website where you wouldn't want to serve -> submit form -> serve cycle for every user input.

Re: Neither PWA nor AMP are needed to make a website load fast

#68

Post by osrec »

dvtrn wrote: post #65
osrec wrote: post #36

Earlier quoted context omitted.

I agree that the initial hit to download 15MB is a lot. But if we think of native apps, users would need to download them from the app store as well. If their internet is slow, both experiences are bad. Having re-read your post, you seem to have misunderstood my point. You seem to be arguing that keeping things lightweight is good. I agree with you there! But remember, for certain applications, this is not always pos…

Okay but why even are web editing applications even being pushed to the web? Why even is this hypothetical relevant for a discussion of AMP here? I understand more and more former desktop operations are being pushed to web clients but full-fledged video editors? As I mentioned to another commenter: can you show me an example of a full-featured, web-based video editor using AMP? I'm not sure if I can buy in that this…

I assume you mean video editing.

Many reasons, but the top one in my opinion is having a single code base across all devices. I think it's a worthwhile goal, personally.

Re: Neither PWA nor AMP are needed to make a website load fast

#69

Post by megy »

untog wrote: post #35
Solar19 wrote: post #13

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…

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 of them are probably images.

Re: Neither PWA nor AMP are needed to make a website load fast

#70

Post by askaboutit »

briandear wrote: post #63
viraptor wrote: post #10

Earlier quoted context omitted.

Unless you have a very active community commenting and interacting around the items, you can definitely go almost entirely static, even in ecommerce. Regenerate pages after changes happen and you'll be fine. You'll still need dynamic search most likely, but even those can be pre-generated for many terms. (Your admin / content management part needs to be dynamic of course, but that's not customer-visible) If your cata…

> You'll still need dynamic search most likely, but even those can be pre-generated for many terms. Have you ever worked on a high scale e-commerce site? I have and what you are talking about is impractical and pretty much impossible. Products have multiple variants, photos for each variant. Various companion products that depend on what you already selected. Pricing options that can depend on quantities or packages.…

Extremely performance store. Mind giving a brief overview of the stack?
Post reply on HN