3 ms·

Show HN: HTML/Functional CSS Performance Test of HN Homepage

6 points by meerita 7y ago

This project was made to demonstrate the power of the functional CSS and proper HTML techniques on Hacker News frontpage. Everything started with this post: https://news.ycombinator.com/item?id=20854214 that talks about how good is that HN wasn't redesigned since the OP was browsing it with slow connection. I though I could make HN even faster without changing the essence of the design too much. So I decided to re-do Hacker News using pure functional css (https://github.com/meerita/utilcss) and some tweaks to the code to increase the performance and test both performance gains in HN on a local server. Code, notes and results available here https://github.com/meerita/hnredone

perilunar 7y ago
So how much of the speed up is due to removing the unnecessary nested tables, how much is due to reducing the page weight, and how much due to the 'Utilitarian CSS'? I know modern web dev (e.g. OOCSS) encourages lots of classes everywhere, but when you have a highly regular structure with many repeated elements (i.e. potentially hundreds per page on article pages), it really pays off to use descendent selectors instead of adding multiple classes to every element. Certainly in terms of page weight. I doubt rendering time would differ much. A few other things you could do to reduce page weight: - Remove any nested elements that are not absolutely necessary. e.g. why do you need the two nested divs inside each list item? Just set the paragraph margins. You don't need grid or flex either — it's just a plain list. - Remove the inline SVG. Use <img src="arrow.svg">, or make it a background image on the link, so it is only downloaded once, instead of being inlined potentially hundreds of times. (220 bytes x 300 = 60 KB) If you must inline it, then optimise it: you can get it down to half the size. - The inline onclick handlers on links should be added by an eventListener in the JS file instead of repeated on every link. You can use CSS attribute selectors to detect which type of link was clicked instead of adding different classes to the different link types.
- meerita 7y ago
  I will try to answer: 1. When you mention speed, there are two factors: downloading (size of the file and priority) and render (composition). There aren't many differences between one or another since, both use the browser default stylesheet. 2. I rely on CSS-grid to avoid floats. But it can be done too. 3. Inline SVG can be improved with imported embedding. But the benefit is really minimal to the point both structures are more or less similar (one has import instruction, the others has a path). 4. I respected all JS, ids from the original HN

6 points by meerita 7y ago

perilunar 7y ago

So how much of the speed up is due to removing the unnecessary nested tables, how much is due to reducing the page weight, and how much due to the 'Utilitarian CSS'? I know modern web dev (e.g. OOCSS) encourages lots of classes everywhere, but when you have a highly regular structure with many repeated elements (i.e. potentially hundreds per page on article pages), it really pays off to use descendent selectors instead of adding multiple classes to every element. Certainly in terms of page weight. I doubt rendering time would differ much. A few other things you could do to reduce page weight: - Remove any nested elements that are not absolutely necessary. e.g. why do you need the two nested divs inside each list item? Just set the paragraph margins. You don't need grid or flex either — it's just a plain list. - Remove the inline SVG. Use <img src="arrow.svg">, or make it a background image on the link, so it is only downloaded once, instead of being inlined potentially hundreds of times. (220 bytes x 300 = 60 KB) If you must inline it, then optimise it: you can get it down to half the size. - The inline onclick handlers on links should be added by an eventListener in the JS file instead of repeated on every link. You can use CSS attribute selectors to detect which type of link was clicked instead of adding different classes to the different link types.

meerita 7y ago
I will try to answer: 1. When you mention speed, there are two factors: downloading (size of the file and priority) and render (composition). There aren't many differences between one or another since, both use the browser default stylesheet. 2. I rely on CSS-grid to avoid floats. But it can be done too. 3. Inline SVG can be improved with imported embedding. But the benefit is really minimal to the point both structures are more or less similar (one has import instruction, the others has a path). 4. I respected all JS, ids from the original HN