5 ms·

This is a worthy goal for any site you build, not just a blog... that said, it's not even that hard to get crazy bloated CMSes like Drupal, Wordpress, etc. as f

This is a worthy goal for any site you build, not just a blog... that said, it's not even that hard to get crazy bloated CMSes like Drupal, Wordpress, etc. as fast (or faster), as long as you set up basic caching (e.g. Nginx, Varnish, CloudFlare, etc.). I have a basic-ish theme, and I use Drupal's AdvAgg module to aggregate and minify JS and CSS, as well as a few other tricks to get page loads smaller. Finally, I use Nginx's dead-simple proxy cache to make most page loads take < 600 ms (and faster, if you're near NYC, where my DO Droplet is located). See, for example: https://www.jeffgeerling.com/blog/2017/tips-managing-drupal-8-projects-composer https://www.jeffgeerling.com/blog/2017/tips-managing-drupal-... (~600 ms from STL, MO, USA). Obviously, the more images and other elements (e.g. social embeds, analytics and other junk), the more time spent downloading the page. But, IMO, there's no excuse for your personal blog to take more than 1s to render and fully deliver a page, with an exception if you embed videos/audio (e.g. podcasters).

devwastaken 10y ago
CMS's are designed to be behind a caching layer like Varnish. a CMS takes in user input and renders to html, which should only change in-page on ajax requests. I really wish there were more public configs for Varnish, some things like Mediawiki are impossible to find well-written and documented configs for, and creating one yourself can have a lot of pitfalls. There's four versions of Varnish, so that too makes it a PITA.
- cies 10y ago
  > CMS's are designed [...] The popular CMSes that are mentioned here (WP, Drupal), are not designed. They where mostly hacked together and became immensely popular before any thorough software design took place. They come from a time where software design was not much applied to "web scripts". > [...] to be behind a caching layer like Varnish. Varnish 1.0 is from 2006. WordPress is from 2003 and Drupal from 2000. These popular CMSes where certainly not made with proxy-caching in mind. You can properly architect and write "your own" CMS in a compiled language (like Go, Rust, C++, OCaml or Haskell) and have <10ms response times (including the db queries). It will just lack the features, plugins/modules, and market pull that WP/Drupal have.
  - mobilefriendly 10y ago
    Drupal 8 was re-architected from scratch and builds on the excellent Symfony components.
  - devwastaken 10y ago
    >The popular CMSes that are mentioned here (WP, Drupal), are not designed. They where mostly hacked together and became immensely popular before any thorough software design took place. They come from a time where software design was not much applied to "web scripts". Hacked together is still a design. It may not be a Good design, but regardless they are made to be behind a caching layer. Also, Drupal 8 is pretty well designed and thought out. >Varnish 1.0 is from 2006. WordPress is from 2003 and Drupal from 2000. These popular CMSes where certainly not made with proxy-caching in mind. Software changes over time, and regardless of timelines the nature of CMS's is to generate output that stays the same, which is good for caching layers. >You can properly architect and write "your own" CMS in a compiled language (like Go, Rust, C++, OCaml or Haskell) and have <10ms response times (including the db queries). It will just lack the features, plugins/modules, and market pull that WP/Drupal have. This highly, highly depends upon what you're building. Plugins and modules are not the reason for slowdown in CMS's, the reason is that the data is abstracted into understanable constructs that can take in all forms of data. This requires lots of queries and code to standardize things. In many cases, you're not going to build something better that is as functional or friendly to future developers.
    - cies 10y ago
      > Hacked together is still a design. That's degrading the definition of design. WP was not even hacked-together/designed to be a full-fledged CMS in the first place! > Drupal 8 is pretty well designed and thought out. It is certainly more designed then the early versions of popular CMSes. But one thing for sure, Drupal 8 is still not designed to be fast. > the reason is that the data is abstracted into understanable constructs that can take in all forms of data. Not all languages suffer from slowness by abstractions. Rust, OCaml and Haskell come to mind. These languages are "designed". Again I'd argue that PHP is not designed but hacked together without much thought for design -- find some Rasmus quotes and you know what I mean.
movedx 10y ago
With Wordpress you can even produce static content from your blog using the many plugins that are available.
- tluyben2 10y ago
  That is something by far most WP bog owners should do. It works, in my experience, faster and more reliable than caching does. Because users like the user friendliness of WP editing but I do not like the bugs, security misery etc, I tend to export WP sites to HTML and make things that must be dynamic with some webservices and React.
austinjp 10y ago
Apposite, I'm working on a personal WP theme currently. Got HTML, CSS and JS down to under 20k so far for a reasonably presentable responsive front page, less on the wire gzipped. CSS and JS minified. Experimenting with inlining "critical" CSS, ie "above fold" content. JS is for parallel loading of CSS to prevent delays in rendering, so content displays before styles are applied (may reverse this decision). This means the critical CSS has to focus on layout, font sizes etc to minimise that awful reshuffling that happens when styling is applied. It's turning out to be quite a fun challenge, reminiscent of early web days when I'd muck about trying to shave 2k off a JPEG. Hopefully notions such as "critical" CSS and inlining to reduce requests might encourage the re-emergence of lean yet visually pleasant websites.
- laumars 10y ago
  I don't understand why 20k is such a challenge for web developers. I don't think I've ever gone even near 20K for HTML, CSS and JS combined. My current blog, which is the most bloated one I've ran yet, is still only around 17K. I do roll all my own code (never touched jQuery et al), mostly because I can and I find it weirdly enjoyable. But threads like these do make me wonder if all these nice tools we have these days are really just a crutch for bad programming practices. I mean I know tech jumps exponentially with each iteration but I swear the performance gained by newer technology is just eaten up straight away by developers writing heavier code to accomplish the same things as before. I know this all sounds hyper-cynical and I do like my compositing display manager with wobbly windows et al so I'm hardly in a position to moan about bloat. But I guess my rant is about how poor web markup is for expressing modern documents (let alone full blown web applications). Well that, and I just needed to rant because I'm stuck in a hospital waiting room at 1 in the morning...
  - Radim 10y ago
    Does anyone remember "Volkov Commander"? An old DOS file manager [1], written in assembly. Super fast and responsive, tiny size -- a fraction of Norton Commander &co's, never mind any modern tools. Whenever I have to deal with the insanely inconvenient cluster fuck that is modern file managers (OSX Finder!), I probably feel the way you do about "modern web development". Hope your hospital visit goes well. [1] https://en.wikipedia.org/wiki/Volkov_Commander https://en.wikipedia.org/wiki/Volkov_Commander
gens 10y ago
It's not just downloading. Websites come with css (not that big of a problem) and JS (big problem). All that has to be processed by the browser. I found that websites sometimes pull css and js bundles (as in whole ones, even over 20kB ones), even from some other servers. Just the other day i tried a website on my aging smartphone and it sometimes took over 20 sec just to write a character (one) in the search thing. The average website on teh internets, in my opinion/experience, is bloated to hell. And i'm not talking about functionality here.
avn2109 10y ago
I look forward to the day when the whole text-based internet produces output like this: http://bettermotherfuckingwebsite.com/ http://bettermotherfuckingwebsite.com/
- Narishma 10y ago
  I like the original better. The contrast on this one is too low and makes it harder for me to read.
flukus 10y ago
> Finally, I use Nginx's dead-simple proxy cache to make most page loads take < 600 ms 600 ms is appalling. Most site should be able to get under 50 ms easy (ignoring internet latency). A blog should be less than 25-30 ms, even if it has to hit the database.
- vinu76jsr 10y ago
  even the http://bettermotherfuckingwebsite.com/ http://bettermotherfuckingwebsite.com/ is taking 300ms in my 2012 MBP, 190 ms with every extension disabled on wifi, I am behind corporate firewall so that might be adding some time.
  - flukus 10y ago
    It's taking 350ms for me, but most of that is high ping (250ms) and it looks like most of the rest is analytics. It takes 30ms to render when downloaded (which skips the analytics). Take out the script entirely and it's down to 10ms.
- matthewking 10y ago
  I think you're confusing total rendering time, as being discussed here, with server response time. I'm getting 86ms response time from the mentioned blog (from London), and 900ms total rendering time.
  - flukus 10y ago
    I did mention latency, which you can't do much about. For me it's around 100ms from response received to rendering, most of which seems to be google analytics. I don't know where the server is, but I'm in Australia so it's probably crossing the pacific. See my reply to the other person for why I'm blaming analytics.

devwastaken 10y ago

CMS's are designed to be behind a caching layer like Varnish. a CMS takes in user input and renders to html, which should only change in-page on ajax requests. I really wish there were more public configs for Varnish, some things like Mediawiki are impossible to find well-written and documented configs for, and creating one yourself can have a lot of pitfalls. There's four versions of Varnish, so that too makes it a PITA.

cies 10y ago
> CMS's are designed [...] The popular CMSes that are mentioned here (WP, Drupal), are not designed. They where mostly hacked together and became immensely popular before any thorough software design took place. They come from a time where software design was not much applied to "web scripts". > [...] to be behind a caching layer like Varnish. Varnish 1.0 is from 2006. WordPress is from 2003 and Drupal from 2000. These popular CMSes where certainly not made with proxy-caching in mind. You can properly architect and write "your own" CMS in a compiled language (like Go, Rust, C++, OCaml or Haskell) and have <10ms response times (including the db queries). It will just lack the features, plugins/modules, and market pull that WP/Drupal have.
- mobilefriendly 10y ago
  Drupal 8 was re-architected from scratch and builds on the excellent Symfony components.
- devwastaken 10y ago
  >The popular CMSes that are mentioned here (WP, Drupal), are not designed. They where mostly hacked together and became immensely popular before any thorough software design took place. They come from a time where software design was not much applied to "web scripts". Hacked together is still a design. It may not be a Good design, but regardless they are made to be behind a caching layer. Also, Drupal 8 is pretty well designed and thought out. >Varnish 1.0 is from 2006. WordPress is from 2003 and Drupal from 2000. These popular CMSes where certainly not made with proxy-caching in mind. Software changes over time, and regardless of timelines the nature of CMS's is to generate output that stays the same, which is good for caching layers. >You can properly architect and write "your own" CMS in a compiled language (like Go, Rust, C++, OCaml or Haskell) and have <10ms response times (including the db queries). It will just lack the features, plugins/modules, and market pull that WP/Drupal have. This highly, highly depends upon what you're building. Plugins and modules are not the reason for slowdown in CMS's, the reason is that the data is abstracted into understanable constructs that can take in all forms of data. This requires lots of queries and code to standardize things. In many cases, you're not going to build something better that is as functional or friendly to future developers.
  - cies 10y ago
    > Hacked together is still a design. That's degrading the definition of design. WP was not even hacked-together/designed to be a full-fledged CMS in the first place! > Drupal 8 is pretty well designed and thought out. It is certainly more designed then the early versions of popular CMSes. But one thing for sure, Drupal 8 is still not designed to be fast. > the reason is that the data is abstracted into understanable constructs that can take in all forms of data. Not all languages suffer from slowness by abstractions. Rust, OCaml and Haskell come to mind. These languages are "designed". Again I'd argue that PHP is not designed but hacked together without much thought for design -- find some Rasmus quotes and you know what I mean.

movedx 10y ago

With Wordpress you can even produce static content from your blog using the many plugins that are available.

tluyben2 10y ago
That is something by far most WP bog owners should do. It works, in my experience, faster and more reliable than caching does. Because users like the user friendliness of WP editing but I do not like the bugs, security misery etc, I tend to export WP sites to HTML and make things that must be dynamic with some webservices and React.

austinjp 10y ago

Apposite, I'm working on a personal WP theme currently. Got HTML, CSS and JS down to under 20k so far for a reasonably presentable responsive front page, less on the wire gzipped. CSS and JS minified. Experimenting with inlining "critical" CSS, ie "above fold" content. JS is for parallel loading of CSS to prevent delays in rendering, so content displays before styles are applied (may reverse this decision). This means the critical CSS has to focus on layout, font sizes etc to minimise that awful reshuffling that happens when styling is applied. It's turning out to be quite a fun challenge, reminiscent of early web days when I'd muck about trying to shave 2k off a JPEG. Hopefully notions such as "critical" CSS and inlining to reduce requests might encourage the re-emergence of lean yet visually pleasant websites.

laumars 10y ago
I don't understand why 20k is such a challenge for web developers. I don't think I've ever gone even near 20K for HTML, CSS and JS combined. My current blog, which is the most bloated one I've ran yet, is still only around 17K. I do roll all my own code (never touched jQuery et al), mostly because I can and I find it weirdly enjoyable. But threads like these do make me wonder if all these nice tools we have these days are really just a crutch for bad programming practices. I mean I know tech jumps exponentially with each iteration but I swear the performance gained by newer technology is just eaten up straight away by developers writing heavier code to accomplish the same things as before. I know this all sounds hyper-cynical and I do like my compositing display manager with wobbly windows et al so I'm hardly in a position to moan about bloat. But I guess my rant is about how poor web markup is for expressing modern documents (let alone full blown web applications). Well that, and I just needed to rant because I'm stuck in a hospital waiting room at 1 in the morning...
- Radim 10y ago
  Does anyone remember "Volkov Commander"? An old DOS file manager [1], written in assembly. Super fast and responsive, tiny size -- a fraction of Norton Commander &co's, never mind any modern tools. Whenever I have to deal with the insanely inconvenient cluster fuck that is modern file managers (OSX Finder!), I probably feel the way you do about "modern web development". Hope your hospital visit goes well. [1] https://en.wikipedia.org/wiki/Volkov_Commander https://en.wikipedia.org/wiki/Volkov_Commander

gens 10y ago

It's not just downloading. Websites come with css (not that big of a problem) and JS (big problem). All that has to be processed by the browser. I found that websites sometimes pull css and js bundles (as in whole ones, even over 20kB ones), even from some other servers. Just the other day i tried a website on my aging smartphone and it sometimes took over 20 sec just to write a character (one) in the search thing. The average website on teh internets, in my opinion/experience, is bloated to hell. And i'm not talking about functionality here.

avn2109 10y ago

I look forward to the day when the whole text-based internet produces output like this: http://bettermotherfuckingwebsite.com/ http://bettermotherfuckingwebsite.com/

Narishma 10y ago
I like the original better. The contrast on this one is too low and makes it harder for me to read.

flukus 10y ago

> Finally, I use Nginx's dead-simple proxy cache to make most page loads take < 600 ms 600 ms is appalling. Most site should be able to get under 50 ms easy (ignoring internet latency). A blog should be less than 25-30 ms, even if it has to hit the database.

vinu76jsr 10y ago
even the http://bettermotherfuckingwebsite.com/ http://bettermotherfuckingwebsite.com/ is taking 300ms in my 2012 MBP, 190 ms with every extension disabled on wifi, I am behind corporate firewall so that might be adding some time.
- flukus 10y ago
  It's taking 350ms for me, but most of that is high ping (250ms) and it looks like most of the rest is analytics. It takes 30ms to render when downloaded (which skips the analytics). Take out the script entirely and it's down to 10ms.
matthewking 10y ago
I think you're confusing total rendering time, as being discussed here, with server response time. I'm getting 86ms response time from the mentioned blog (from London), and 900ms total rendering time.
- flukus 10y ago
  I did mention latency, which you can't do much about. For me it's around 100ms from response received to rendering, most of which seems to be google analytics. I don't know where the server is, but I'm in Australia so it's probably crossing the pacific. See my reply to the other person for why I'm blaming analytics.