The average website on teh internets, in my opinion/experience, is bloated to hell. And i'm not talking about functionality here.
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.
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 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".
Hope your hospital visit goes well.
I hope your visit went well.
Hope the hospital visit turned out okay.
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.
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.
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).