Malte Ubl
medium.com/@cramforce · Personal blog · on HN since 2014
Malte Ubl, a Google engineer and tech lead on AMP, writes about large JavaScript apps, web performance, concurrency and rendering tradeoffs.
What HN saysHN links his posts mainly in AMP debates, where he is cited as the source for why AMP is fast, while others question the claims.
22HN people shared it
5linked it in comments
39stories submitted
603story points
6 years agolast shared
2014people per year2026
Most-shared posts
- 1Designing very large JavaScript applications5 people · 450 points · first shared 2018 · 154 comments on HN
- 2Introducing splittable5 people · 10 points · first shared 2016 · discussion on HN
- 3Why AMP is fast5 people · 4 points · first shared 2015 · discussion on HN
- 42016 will be the year of concurrency on the web3 people · 81 points · first shared 2015 · 34 comments on HN
- 5Why AMP HTML does not take full advantage of the preload scanner3 people · 2 points · first shared 2015 · discussion on HN
- 610x engineer 10% of the time2 people · 10 points · first shared 2015 · 1 comments on HN
- 7But what about the ads?2 people · 5 points · first shared 2016 · discussion on HN
- 8Tradeoffs in server side and client side rendering2 people · 5 points · first shared 2015 · discussion on HN
- 9Developer Experience VS User Experience?2 people · 4 points · first shared 2017 · discussion on HN
- 10Not so micro optimizations1 people · 6 points · first shared 2015 · discussion on HN
- 11Hacking Business Negotiations1 people · 6 points · first shared 2016 · discussion on HN
- 12Designing Even Larger Applications1 people · 5 points · first shared 2020 · discussion on HN
- 13The diversity bad bank1 people · 4 points · first shared 2017 · discussion on HN
- 14Anecdotes about front end and back end engineering1 people · 2 points · first shared 2015 · discussion on HN
- 15Hostility in Open Source Is Good. Too Much Collaboration Leads to Monoculture1 people · 2 points · first shared 2018 · discussion on HN
What HN people wrote when they linked it
cromwellian · 2021-02-06
Closure Compiler's advanced mode, besides having the best minification (it is actually a full compiler with many different optimization passes) and being slow, has a feature that often goes untested externally (but is used heavily inside of Google) and that's cross-module-code-motion.
So if you split your code into modules, some of which are loaded later, the compiler can figure out which code in the initial download is used, but not yet and move it into the late loaded modules, whereas ordinarily this code gets retained in the initial load, because it looks like it is referenced.
A long time ago Malte Ubl demonstrated this with the Splittable add on for Babel.
https://medium.com/@cramforce/introducing-splittable-1c882babca7e
cramforce · 2017-08-23
https://github.com/ampproject/amphtml
https://medium.com/@cramforce/why-amp-is-fast-7d2ff1f48597
https://medium.com/@cramforce/why-amp-html-does-not-take-full-advantag…
People here are opinionated about it, but users love it.
jacksmith21006 · 2018-06-02
That is NOT true. AMP is a lot faster in most cases.
"Why AMP is fast"
https://medium.com/@cramforce/why-amp-is-fast-7d2ff1f48597
But why the half truth? Can you share the back story?
e1ven · 2017-08-24
I appreciate the info!
I'm really curious to see where using AMP as a proxy speeds up the page, versus applying similar optimizations on origin server?
If it's a cached page (served from any normal CDN), and crafted with similar optimizations [1] wouldn't it be just as fast, without needing to do the URL redirection?
Even if it were difficult to convince developers to implement the changes, couldn't many of the optimizations could be rolled into a module like PageSpeed [2]?
[1] - https://medium.com/@cramforce/why-amp-is-fast-7d2ff1f48597
[2] - https://developers.google.com/speed/pagespeed/module/
Edit - Reformatted links; I forgot HN doesn't use Markdown.
Zarel · 2018-01-09
I never said it was all it does. It's the reason AMP exists, and the reason certain users like it.
The "hijacks content" part is by itself unobjectionable, especially with this latest update we're discussing which fixes the URL bar issue. The other server will serve a checksum so Google can't tamper with the contents. That makes it just a free CDN.
Is the problem that you do not want Google to see your content at all? You'll need to use robots.txt to ban Googlebot. You can't simultaneously want to appear in Google search results and also not let Google see your website.
The required JavaScript is legitimately frustrating, I know. The AMP project has an article about why they did it that way:
https://medium.com/@cramforce/why-amp-html-does-not-take-full-advantag…
Specifically, it's to prioritize resource loads. I personally don't think their explanation is very convincing. But whatever, maybe it's easier for them to do it this way or something.
I don't think Google is doing it to push changes which are profitable for them, though. I legitimately believe they're doing it to make the pages load faster and otherwise be better for the users. I don't even understand how it could be profitable in any other way.