The user has a default font, who am I to say that I know a better one?
If you want to be more pragmatic you can accept that most browsers use awful fonts by default. However coming soon is system-ui, ui-serif and ui-sans-serif which allow you to let the user to continue picking the font, expect not awful.
(I still don't understand why browser didn't just update initial, serif and sans-serif to be non-awful, but I'm not a browser maker)
> The 3 that my blog[0] uses are base64 URLs in my single 100k CSS file.
This is not an efficient approach. Base64 will make the fonts about 30% bigger, and webfonts are already too big. The fact that it's in CSS also means that it's now render blocking, and font-display can't be used.
You're likely delaying your render time versus standard font loading. Do a comparison in WebPageTest and examine the waterfall.
woff2 is already a highly-compressed format so you shouldn't expect much in terms of savings. Maybe gzip could offset some of the fat added by base64 though.
100KB for a font is a lot of data on a website. I'm using a custom subsetted version of Source Sans Pro at just 6.7KB.
That tweet seems to contradict itself. If it being an old issue makes it more important, than isn't it also important to call out that it's an old issue? Sure, a date (in the far past) on the post might make people question if the issue still exists, but also points out how long the issue has been around.
So it appears his opinion is "If I arranged things so that readers could easily find out how old my articles are, some people would ignore them even though they still contain some useful content, so I will try to hide this information".
> I previously got a lot more comments about dates on posts, so removing dates from posts was a pretty large net win on the number of comments I get about dates.
When most articles of his posted to HN has people complaining about dates, instead of talking about the content, I'd hide the dates from my site too. I've been here a while and I find the majority of those comments to be low quality and are a net negative to everyone else's reading experience.
In the waning days of my own blogging, the second time around, I noticed a pattern that I would sort of build up a list of things to talk about, work through it after 14 months and then struggle to say anything I hadn't already said before. And maybe it was projection but I felt like I saw the same thing in some of the bloggers I followed. At the time I was following my Lit friend who was trying to find her way in the professional writing world and talking about problems of motivation and practice.
In later years I started to wonder if I wouldn't have been better off just embracing the repetition, because sometimes my opinion would change, or I'd encounter new arguments or counter-arguments from or while talking to my peers.
Mini-MSFT for instance had very few qualms about beating the same drum over and over every time new data came in. And as prolific (and promiscuous) as Martin Fowler is, he still ends up treading old ground.
It might be better for Dan if he dated things, and for us to see how his opinions refine over time as he retreaded old posts. My priorities have to shift when the sub-problems become more or less contentious. Some problems stay even as code reviews or automated testing becomes a de facto standard. Some intensify.
There are evergreen problems in human interaction. We have some of the same conflicts that Shakespeare talked about. We even have some of the same ones Homer talked about. But awareness and tools change and those can subtly affect how you address them. What is mastery but subtlety? If you think you are talking as a master or a wannabe master, then you should always have things to say.
I talked about Tai Chi last week. One of my favorite things about my first teacher was the experiences I had in the month after a field trip to train with a lineage holder, seeing how the focus of the instruction shifted, how the senior students changed, in movement and in conversation, and seeing how I notice these shifts. Things I might have missed when I was a neophyte - when you see your teacher and the craft as static instead of dynamic. Things I still miss (I know you said this was different, but it looks the same to me.)
And so I wonder if Dan either is wrestling other 'traumas', stuck in a very long plateau, or seeing past my horizon.
Denying people information to make a decision because they might react in an uninformed manner is so hilariously on-brand for Dan Luu.
Remember his blog post about walking into an Apple store and harassing (and then writing a long blog post mocking...) a poor retail employee because he wanted a laptop of a specific weight, they were understandably a bit confused and thought there was some sort of XY problem and asked for more information......and for some inexplicable reason he could not simply take 15-30 seconds of his life to detail the need to them? No, see: Dan Luu is Very Important, Very Very Smart and Completely Unique Needs and you are just a lowly NPC service worker who could not possibly understand his needs or brilliance. And he never explains himself in that article either, because he's a troll.
The problem in the screencapped comment is the groundless accusation the information is incorrect, not asking if it's still correct. On many, many technical subjects, information that is five years old is uselessly out of date.
I've pissed away hours because I trusted a writeup or forum post about a problem or configuration method that stopped being relevant or even correct years ago. These days if I'm searching on almost anything technical, I immediately select the "last year" filter on google, or throw in the current year in quotes because I've been so consistently burned by this problem.
> Denying people information ... on-brand for Dan Luu.
Just to be clear, he does not deny the information. Chronology matters a lot, danluu knows this, and he does make it available. He also made finding it a personal journey for any first-time visitor looking for a date, costing about 60s per user lifetime.
He's unduly sensitive to bad criticism by ignorant people and admits as much. Reducing his exposure to them helps get him through the day, and so all the power to him.
As for the arrogance, I love this site and would keep coming here even if danluu were Pol Pot himself. Users and moderation make the site.
Not having the dates and versions was the main reason I switched to nginx. Every new project or company I had to try to get Apache and Tomcat to work together, and there was no runbook or cookbook for this. Just a series of articles that were very good, but only if you found the right article for the right IPC strategy for the correct versions of Apache and Tomcat.
Eventually the only thing to work reliably was mod_proxy, which is also the slowest option. And if I'm going to do that, I might as well run nginx, whose proxy configuration is only about half as mystical.
Of course the longer I use nginx, the more I need the subscription based features, so I'm experiencing an in-kind phenomenon where all of the google searches take me to the pro version. We aren't complete hobos. We have licenses for ingress and between services. If you're trying to reverse proxy in front of a process-oriented web server (Rails, Nodejs, Python, etc) you're talking about another order of magnitude and they are not interested. Every six months I keep looking at how hard it would be to implement a strategy better than round robin in the built-in implementation.
Just wait until HN adds the date, it usually doesn't take that long. That in itself also completely negates the reason for why he doesn't display the date in the first place.
"I'm not going to try to convince you to start writing a blog, since that has to be something you want to do, but I will point out that there's a large gap that's waiting to be filled by your knowledge. When I started writing this blog, I figured almost no one would ever read it; sure Joel Spolsky and Steve Yegge created widely read blogs, but that was back when almost no one was blogging. Now that there are millions of blogs, there's just no way to start a new blog and get noticed. Turns out that's not true." - Dan Luu https://danluu.com/about/
There's a number of people who can take what they do in their day job and then write about it (this example clearly is not that, but he spend 30 minutes speeding up his site, and probably an hour documenting it; that's less time than many of us will waste on HN today).
Dan Luu's posts show up here pretty often. His posts are generally well thought out and often involve quite a bit of research and deep-diving into whatever topic he's chosen to write about.
He doesn't post super often -- a quick perusal of his archive shows at most 3x per month, often less, and often not even once during a random month. So while each post might take a lot of time and effort, it's often spread out over weeks or more.
(Not trying to criticize your lack of knowledge here, just aiming to fill a knowledge gap.)
Meh. They're half good, half snobby and self-righteous.
He famously refuses to date his blog posts. And in this case, the page is years old, no longer relevant to the content of his blog and contains techniques that are not recommended and will in fact slow down your page load.
Either keep content relevant, or put dates on it so people can be aware that content might be outdated.
I run a few websites on a single Linode, they're quite snappy if you don't do too much. No fancy optimizations required, just keep it vanilla, you can make great websites with just modern HTML, JS, CSS: https://krisshamloo.com
> What if we move the scripts to source/_includes/custom/after_footer.html?
Please don't do this, this is the slowest possible way to load these resources and the longest duration possible until a fully interactive page. Use "async" or "defer" attributes instead.
Footnote: if the scripts are not necessary for interaction, moving them to the footer and marking them deferred/async allows you to prevent the browser preloader[0] from being too eager with downloading them during downtime.
This is effectively a poor man's resource priority hints[1], allowing the developer the ability to prioritize downloads for the browser.
Yes, the end of the document + `async` is probably still the way to go for analytics scripts and similar things. (`defer` will still block the initial render.)
Other way round. Neither blocks parsing/render during downloads, but async scripts execute immediately onLoad – blocking render. defer "defers" that until after document parsing is finished. https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Fi...
In favor of the article, it has to mentioned that putting any script tags at the very end of documents was apparently taught in bootcamps, could be found in numerous tutorials, and was generally acknowledged. (There were even quite authoritative feelings about this. A few years ago you could have been downvoted for a comment like this. At least, I was.)
This is really funny to me, because I generally view danluu.com as a pretty clean, "low design", low-complexity site, so it's odd to see how complex it actually is. (Or at least was, since this is an old post; the current version seems to be much lighter.)
Also I'm now realizing that it's a bit silly to call things like these "static sites". Sure, it's not backed by a database, but it's by no means "static". The entire point of Javascript was to make web pages more dynamic! If you're loading and using JS on your site, it might be "statically generated", but it's certainly not "static".
"static" was more of the server side requirements than if it's interactive or not. like "static" sites that can be hosted serverless from an S3 bucket.
I tried using the Wayback Machine to see what it looked like back when this article was first published, and discovered that danluu.com has been excluded from the Wayback Machine.
Is the "finite connections" thing even a thing any more?
As far as I understand things, HTTP/2 kinda solved that problem (within reason) and you don't have to worry about combining JavaScript and CSS and images etc into giant bundled files so much any more?
Is it really true that the page originally took >10s to "start rendering", or is that an artifact of the way it's measured? Was the page literally blank for ten full seconds?
Does anyone have a hunch on what caused the 100ms reduction in the time to first byte? Is it just having a much better and broader spread on where Cloudflare has datacenters serving DNS lookups?
The site was moved from a host that got a D rating on TTFB from whatever precursor to lighthouse he's using here onto an edge cached CDN. I expect the distance to server is helping but most of the improvement is from github pages having a pretty substantial built-in slowdown at the time (this is a 2014 article).
In the long run they would have been better off just coding it all themselves with the purpose of efficiency in mind, instead of relying on work of other people.
The biggest misconception I've found, to date, regarding performance, is that people believe everything's fast, because a compiler/JIT makes it fast.
Only a small percentage of programmers actually know how to do things right, the rest of every-thing is built up upon the same nonsense everyone gets to not just learn, but also gets to spread it even further out, creating a faulty norm everyone just accepts as true, because everyone says it's true.
Fact of the matter is that, as an analogy, a garbage collector is pure and utter nonsense, because it's a bandaid to fix the issue with people having no clue how to actually handle memory properly. Instead, they believe garbage collectors are a good thing, while also struggling with it interfering when it shouldn't.
To extend this analogy: Everyone would be better off just learning the simplicity of handling ones memory by ones self. Making at least ones own library for proper memory handling and management once, should be mandatory.
It's not that far away from "proper memory handling" to "setting up and accessing data in a cache efficient manner" ... and further.
> Everyone would be better off just learning the simplicity of handling ones memory by ones self.
I've found the difficulty of memory management increase quadratically to the linear increase in program complexity. So simple programs have simple memory management and even modestly complex programs have very complex memory management.
My personal application is the front half of an operating system written in JavaScript (TypeScript). The browser portion fully loads with render and state restoration in about 175ms according to the Chrome performance tool in the dev tools. That JS is about 380kb unminified bundled into a single file. The CSS includes 2 custom fonts in base64.
The Node side of the app loads a bit slower in about 250ms but it’s also executing about 10x more code.
> First, it seems to likely show that the advice that it's very important to keep line lengths short is incorrect since, if that had a very large impact, it would've overwhelmed the other changes and resulted in reduced engagement and not increased engagement.
Well, I can't speak for anyone else, but I read all articles on that site with Reader view since they're impossible to read any other way. There's good content there, but man is it a pain in the ass to read!
Shouldn't that somewhat be the point, though? Shouldn't we have control over the look & feel, layout, design of the websites we visit?
I'm feeling like you did exactly what you should have done. You chose to read the site in a style (Reader Mode) that benefits you. Maybe someone else chooses a style, set of fonts, or overrides the margins manually.
I think we've gone too far with HTML styling. I'd much prefer unstyled semantic markup and then let my theme choices display the content. Early HTML was quite a bit more like this. Gopher protocol and Project Gemini might be other examples of content without "design."
76 comments
[ 0.18 ms ] story [ 148 ms ] threadYeah, you can definitely go overboard with webfonts. The 3 that my blog[0] uses are base64 URLs in my single 100k CSS file.
Reducing javascript and deferring the rest gets some solid speedups.
Serving everything from a single domain reduces total load time, due to DNS lookups.
You might even get away with not having social media widget JS, too: https://www.hanselman.com/blog/add-social-sharing-links-to-y...
[0] https://theandrewbailey.com/
The user has a default font, who am I to say that I know a better one?
If you want to be more pragmatic you can accept that most browsers use awful fonts by default. However coming soon is system-ui, ui-serif and ui-sans-serif which allow you to let the user to continue picking the font, expect not awful.
(I still don't understand why browser didn't just update initial, serif and sans-serif to be non-awful, but I'm not a browser maker)
This is not an efficient approach. Base64 will make the fonts about 30% bigger, and webfonts are already too big. The fact that it's in CSS also means that it's now render blocking, and font-display can't be used.
You're likely delaying your render time versus standard font loading. Do a comparison in WebPageTest and examine the waterfall.
Does this actually change the transmitted size significantly?
100KB for a font is a lot of data on a website. I'm using a custom subsetted version of Source Sans Pro at just 6.7KB.
> This comment is a nice illustration of why I don't have dates directly on posts and "make" people click once to get the date.
> This has been an issue for decades. The fact that it's an old issue makes it more important, not less.
> https://news.ycombinator.com/item?id=30935064
My opinion of that is low.
> I previously got a lot more comments about dates on posts, so removing dates from posts was a pretty large net win on the number of comments I get about dates.
When most articles of his posted to HN has people complaining about dates, instead of talking about the content, I'd hide the dates from my site too. I've been here a while and I find the majority of those comments to be low quality and are a net negative to everyone else's reading experience.
In later years I started to wonder if I wouldn't have been better off just embracing the repetition, because sometimes my opinion would change, or I'd encounter new arguments or counter-arguments from or while talking to my peers.
Mini-MSFT for instance had very few qualms about beating the same drum over and over every time new data came in. And as prolific (and promiscuous) as Martin Fowler is, he still ends up treading old ground.
It might be better for Dan if he dated things, and for us to see how his opinions refine over time as he retreaded old posts. My priorities have to shift when the sub-problems become more or less contentious. Some problems stay even as code reviews or automated testing becomes a de facto standard. Some intensify.
There are evergreen problems in human interaction. We have some of the same conflicts that Shakespeare talked about. We even have some of the same ones Homer talked about. But awareness and tools change and those can subtly affect how you address them. What is mastery but subtlety? If you think you are talking as a master or a wannabe master, then you should always have things to say.
I talked about Tai Chi last week. One of my favorite things about my first teacher was the experiences I had in the month after a field trip to train with a lineage holder, seeing how the focus of the instruction shifted, how the senior students changed, in movement and in conversation, and seeing how I notice these shifts. Things I might have missed when I was a neophyte - when you see your teacher and the craft as static instead of dynamic. Things I still miss (I know you said this was different, but it looks the same to me.)
And so I wonder if Dan either is wrestling other 'traumas', stuck in a very long plateau, or seeing past my horizon.
Remember his blog post about walking into an Apple store and harassing (and then writing a long blog post mocking...) a poor retail employee because he wanted a laptop of a specific weight, they were understandably a bit confused and thought there was some sort of XY problem and asked for more information......and for some inexplicable reason he could not simply take 15-30 seconds of his life to detail the need to them? No, see: Dan Luu is Very Important, Very Very Smart and Completely Unique Needs and you are just a lowly NPC service worker who could not possibly understand his needs or brilliance. And he never explains himself in that article either, because he's a troll.
The problem in the screencapped comment is the groundless accusation the information is incorrect, not asking if it's still correct. On many, many technical subjects, information that is five years old is uselessly out of date.
I've pissed away hours because I trusted a writeup or forum post about a problem or configuration method that stopped being relevant or even correct years ago. These days if I'm searching on almost anything technical, I immediately select the "last year" filter on google, or throw in the current year in quotes because I've been so consistently burned by this problem.
Just to be clear, he does not deny the information. Chronology matters a lot, danluu knows this, and he does make it available. He also made finding it a personal journey for any first-time visitor looking for a date, costing about 60s per user lifetime.
He's unduly sensitive to bad criticism by ignorant people and admits as much. Reducing his exposure to them helps get him through the day, and so all the power to him.
As for the arrogance, I love this site and would keep coming here even if danluu were Pol Pot himself. Users and moderation make the site.
Eventually the only thing to work reliably was mod_proxy, which is also the slowest option. And if I'm going to do that, I might as well run nginx, whose proxy configuration is only about half as mystical.
Of course the longer I use nginx, the more I need the subscription based features, so I'm experiencing an in-kind phenomenon where all of the google searches take me to the pro version. We aren't complete hobos. We have licenses for ingress and between services. If you're trying to reverse proxy in front of a process-oriented web server (Rails, Nodejs, Python, etc) you're talking about another order of magnitude and they are not interested. Every six months I keep looking at how hard it would be to implement a strategy better than round robin in the built-in implementation.
> the sender SHOULD generate its field value as the best available approximation of the date and time of message generation
It's message generation date, not resource date.
That's offensively fast by 2022 standards.
As of late he is also supported on patreon: https://www.patreon.com/danluu
It's impossible to waste time on HN.[1]
[1] That's what I keep telling myself.
He doesn't post super often -- a quick perusal of his archive shows at most 3x per month, often less, and often not even once during a random month. So while each post might take a lot of time and effort, it's often spread out over weeks or more.
(Not trying to criticize your lack of knowledge here, just aiming to fill a knowledge gap.)
He famously refuses to date his blog posts. And in this case, the page is years old, no longer relevant to the content of his blog and contains techniques that are not recommended and will in fact slow down your page load.
Either keep content relevant, or put dates on it so people can be aware that content might be outdated.
I'm sure it's been posted to HN before, but I love this blog post about it: https://idlewords.com/talks/website_obesity.htm
Please don't do this, this is the slowest possible way to load these resources and the longest duration possible until a fully interactive page. Use "async" or "defer" attributes instead.
This is effectively a poor man's resource priority hints[1], allowing the developer the ability to prioritize downloads for the browser.
[0] https://andydavies.me/blog/2013/10/22/how-the-browser-pre-lo...
[1] https://wicg.github.io/priority-hints/
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sc...
In favor of the article, it has to mentioned that putting any script tags at the very end of documents was apparently taught in bootcamps, could be found in numerous tutorials, and was generally acknowledged. (There were even quite authoritative feelings about this. A few years ago you could have been downvoted for a comment like this. At least, I was.)
Now the page load even faster !
Related post from his blog: https://danluu.com/web-bloat/
Also I'm now realizing that it's a bit silly to call things like these "static sites". Sure, it's not backed by a database, but it's by no means "static". The entire point of Javascript was to make web pages more dynamic! If you're loading and using JS on your site, it might be "statically generated", but it's certainly not "static".
As far as I understand things, HTTP/2 kinda solved that problem (within reason) and you don't have to worry about combining JavaScript and CSS and images etc into giant bundled files so much any more?
The biggest misconception I've found, to date, regarding performance, is that people believe everything's fast, because a compiler/JIT makes it fast.
Only a small percentage of programmers actually know how to do things right, the rest of every-thing is built up upon the same nonsense everyone gets to not just learn, but also gets to spread it even further out, creating a faulty norm everyone just accepts as true, because everyone says it's true.
Fact of the matter is that, as an analogy, a garbage collector is pure and utter nonsense, because it's a bandaid to fix the issue with people having no clue how to actually handle memory properly. Instead, they believe garbage collectors are a good thing, while also struggling with it interfering when it shouldn't.
To extend this analogy: Everyone would be better off just learning the simplicity of handling ones memory by ones self. Making at least ones own library for proper memory handling and management once, should be mandatory.
It's not that far away from "proper memory handling" to "setting up and accessing data in a cache efficient manner" ... and further.
I've found the difficulty of memory management increase quadratically to the linear increase in program complexity. So simple programs have simple memory management and even modestly complex programs have very complex memory management.
The web will never be as fast as it was in 1999.
The Node side of the app loads a bit slower in about 250ms but it’s also executing about 10x more code.
> First, it seems to likely show that the advice that it's very important to keep line lengths short is incorrect since, if that had a very large impact, it would've overwhelmed the other changes and resulted in reduced engagement and not increased engagement.
Well, I can't speak for anyone else, but I read all articles on that site with Reader view since they're impossible to read any other way. There's good content there, but man is it a pain in the ass to read!
I'm feeling like you did exactly what you should have done. You chose to read the site in a style (Reader Mode) that benefits you. Maybe someone else chooses a style, set of fonts, or overrides the margins manually.
I think we've gone too far with HTML styling. I'd much prefer unstyled semantic markup and then let my theme choices display the content. Early HTML was quite a bit more like this. Gopher protocol and Project Gemini might be other examples of content without "design."
That’s probably zero.
Why would you even make people have to take an extra step to comfortably read your content?