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).
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).
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.
> 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.
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.
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.
even the 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.
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.
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.
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...
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".
I'm with you. I have the same feeling about web, desktop and smartphone - each iteration of software does the same or less than previous one, while eating up any resource surplus created by advancements in hardware and optimizations of software stack.
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.
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.
>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.
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.
Its not. Bad designs are still designs, design is not a word about quality, it is a word about intentions and implimentation of them.
>WP was not even hacked-together/designed to be a full-fledged CMS in the first place!
Original intentions have no bearing on how the software is now. WP definitely does have issues, but it is designed to be a full fledged CMS now.
>Not all languages suffer from slowness by abstractions.
In this case, they do, because you have to get your data from a database, we're not even talking about programming languages, but constructs of data and how they're sorted. Drupal 8 has a very interesting methodology to categorize data that is well done enough the Views module can take that and is capable of building most data-centric sites. You can build a pure catalog like digi-key with normal drupal 8, no plugins or modifications, just setting the control panel and a theme.
>But one thing for sure, Drupal 8 is still not designed to be fast.
It is, actually. But it being 'fast' is behind its ability to work with data and make it actually configurable to define your own editing workflow and how that gets represented on your editors dashboard, connected directly to how its viewed on your website. Your CMS does not need to be 2fast, since it should be behind caching layers.
>Not all languages suffer from slowness by abstractions. Rust, OCaml and Haskell
All languages suffer from the abstraction higher level languages like PHP, Python or JS provide, namely that they're not typed or compiled and can work with very dynamic data.
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.
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-... (~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).