41–50 of 225 posts
Out challenge has been that we have to load a lot of images, so we spent a lot of time optimizing everything around it and optimizing everything around it. From TLS1.3 to the CDN, to every part of our stack.
Try it out
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…
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, 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.
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.
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!
I agree on AMP, you can just pack less JS and be done with it. But AMP is REALLY about rich search results online. Google creates more interactive search results for AMP pages than non-AMP versions. As for PWA's, I'm honestly a fan, to a certain limit. I really like Gatsby.js, especially because the rendered pages work with Javascript disabled. Django/Rails/$FRAMEWORK with Turbolinks.js is also great, for the same re…
At Tock we had been obsessed with page load performance since the beginning and I agree with the author. We avoided PWA mostly due to it's broken behavior. Often times we are faster than loading the same restaurant page on Google search. Out challenge has been that we have to load a lot of images, so we spent a lot of time optimizing everything around it and optimizing everything around it. From TLS1.3 to the CDN, to…
Earlier quoted context omitted.
It is the only available solution to a real problem. If you have a better solution, by all means, be a hero. Meanwhile, the rest of the search and content aggregation industry has gone with AMP, which works today.
> the rest of the search and content aggregation industry has gone with AMP Because Google effectively gave them no choice.
I'm talking about link aggregators and search engines, not publishers. They could have come up with another solution, but they decided to use AMP, which provides the same benefits to them as it provides to Google.
I agree on AMP, you can just pack less JS and be done with it. But AMP is REALLY about rich search results online. Google creates more interactive search results for AMP pages than non-AMP versions. As for PWA's, I'm honestly a fan, to a certain limit. I really like Gatsby.js, especially because the rendered pages work with Javascript disabled. Django/Rails/$FRAMEWORK with Turbolinks.js is also great, for the same re…
Microdata is for rich search results. AMP is for instant (not fast, as the author mistakenly stated) loading from a search results page or content aggregator.
I may be wrong, this just was my understanding from reading all the Google search guides last week.
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…
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…
What do you think all those little "Edit" buttons all over wikipedia do?
Well yeah but the author is missing the point: these tools allow your site to load faster than the theoretical limit without them. AMP buys you Google's CDN and prefetching on Search. And PWA buys you a 0 distance cache hit on your second visit, the ability to prefetch unvisited resources, and with the ability to update the cache in the background. Not saying these aren't negligible on a 15MB site but they are tools…
on a 15MB site Good lord, friend. Why put your users through this to begin with?