logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

Conservative-web-development.md (6187B)

    

  1. ---
  2. date: 2018-09-04
  3. layout: post
  4. title: Conservative web development
  5. tags: ["philosophy", "web"]
  6. ---
  8. Today I turned off my ad blocker, enabled JavaScript, opened my network monitor,
  9. and clicked the first link on Hacker News - a New York Times article. It started
  10. by downloading a megabyte of data as it rendered the page over the course of
  11. eight full seconds. The page opens with an advertisement 281 pixels tall, placed
  12. before even the title of the article. As I scrolled down, more and more requests
  13. were made, downloading a total of 2.8 MB of data with 748 HTTP requests. An
  14. article was weaved between a grand total of 1419 vertical pixels of ad space,
  15. greater than the vertical resolution of my display. Another 153-pixel ad is
  16. shown at the bottom, after the article. Four of the ads were identical.
  18. I was reminded to subscribe three times, for $1/week (after one year this would
  19. become $3.75/week). One of these reminders attached itself to the bottom of my
  20. screen and followed along as I scrolled. If I scrolled up, it replaced this with
  21. a larger banner, which showed me three other articles and an ad. I was asked for
  22. my email address once, though I would have had to fill out a captcha to submit
  23. it. I took out my phone and repeated the experiment. It took 15 seconds to load,
  24. and I estimate the ads took up a vertical space equal to 4 times my phone's
  25. vertical resolution, each ad alone taking up half of my screen.
  27. The text of the article is a total of 9037 bytes, including the title, author,
  28. and date. I downloaded the images relevant to the article, including the
  29. 1477x1082[^1] title image. Before I ran them through an optimizer, they weighed
  30. 260 KB; after, 236 KB (using only lossless optimizations). 8% of the total
  31. download was dedicated to the content. 5 discrete external companies were
  32. informed of my visit to the page and given the opportunity to run artibrary
  33. JavaScript on it.
  35. [^1]: Greater than the vertical resolution of my desktop display.
  37. If these are the symptoms, what is the cure? My basic principles are these:
  39. - Use no, or very little, JavaScript
  40. - Use raster images sparingly, if at all, and optimize them
  41. - Provide interactivity with forms and clever CSS
  42. - Identify wasted bandwidth and CPU cycles and optimize them
  44. I've been building [sr.ht](https://meta.sr.ht) with these principles in mind,
  45. and I spent a few hours this optimizing it further. What do the results look
  46. like? The heaviest page, [the marketing page](https://meta.sr.ht), today weighs
  47. <strong class="text-info">110 KB</strong> with a cold cache, and <strong
  48. class="text-danger">4.6 KB</strong> warm. [A similar page](https://github.com/)
  49. on GitHub.com[^2] weighs <strong class="text-info">2900 KB</strong> cold,
  50. <strong class="text-danger">19.4 KB</strong> warm. [A more typical
  51. page][srht-main] on sr.ht weighs <strong class="text-info">56.8 KB</strong>
  52. cold and <strong class="text-danger">31.9 KB</strong> warm, after <strong
  53. class="text-warning">2</strong> HTTP requests; on GitHub [the same
  54. page][github-main] is <strong class="text-info">781 KB</strong> cold and
  55. <strong class="text-danger">57.4 KB</strong> warm, <strong
  56. class="text-warning">118</strong> requests. This file is 29.1 KB.  The sr.ht
  57. overhead is <strong class="text-info">27.6 KB</strong> cold and <strong
  58. class="text-danger">2.7 KB</strong> warm. The GitHub overhead is respectively
  59. <strong class="text-info">751.9 KB</strong> and <strong class="text-danger">28.2
  60. KB</strong>. There's also a 174-pixel-tall ad on GitHub encouraging me to sign
  61. up for an account, shown before any of the content.
  63. [srht-main]: https://git.sr.ht/~sircmpwn/linux/tree/master/init/main.c
  64. [github-main]: https://github.com/torvalds/linux/blob/master/init/main.c
  66. [^2]: You may have to log out to see this.
  68. To be fair, the GitHub page has more features. As far as I can tell, most of
  69. these aren't implemented *in* the page, though, and are rather links to other
  70. pages. Some of the features *in* the page include a dropdown for filtering
  71. branches and tags, popups that show detail when you hover over avatars, some
  72. basic interactivity in the search, all things that I can't imagine taking up
  73. much space. Does this justify an order of magnitude increase in resource usage?
  75. Honestly, GitHub does a pretty good job overall. Compared to our New York Times
  76. example, they're downright *great*. But they could be doing better, and so could
  77. we all. You can build beautiful, interactive websites with HTML and CSS alone,
  78. supported by a simple backend. Pushing the complexity of rendering your
  79. single-page app into the frontend might save you miniscule amounts of
  80. server-side performance, but you'd just be offloading the costs onto your
  81. visitor's phone and sucking their battery dry.
  83. There are easy changes you can make. Enable caching on your web server, with a
  84. generous expiry. Use a hash of your resources in the URL so that you can bust
  85. the cache when you need to. Enable gzip for text resources, and HTTP/2. Run your
  86. images through an optimizer, odds are they can be losslessly compressed.  There
  87. are harder changes, too. Design your website to be usable without JavaScript,
  88. and use small amounts of it to enhance the experience - rather than to *be* the
  89. experience. Use CSS cleverly to provide interactivity[^3]. Find ways to offload
  90. work to the server where you can[^4]. Measure your pages to look for places to
  91. improve. Challenge yourself to find the simplest way of building the features
  92. you want.
  94. [^3]: For example, check out how I implemented the collapsable message details on the [lists.sr.ht archives](https://lists.sr.ht/~sircmpwn/sr.ht-dev/%3C20180830183221.32377-1-hilobakho%40gmail.com%3E)
  95. [^4]: I did this when I upgraded to Font Awesome 5 recently. They want you to include some JavaScript to make their SVG icons work, but instead I wrote a [dozen lines of Python](https://git.sr.ht/~sircmpwn/core.sr.ht/tree/70e75e96dc664a1b487ef02cb9936cb8f69105c0/srht/flask.py#L49) on the backend which gave me a macro to dump the desired SVG directly into the page.
  97. And if anyone at Google is reading, you should try recommending these strategies
  98. for speeding up pages instead of pushing self-serving faux standards like AMP.