Delivering WordPress in 7kb • Hacker News Board

Re: Delivering WordPress in 7kb

#21

Post by ryanworl » Thu, Jul 12, 2018, 12:40 PM UTC

nattaylor wrote: post #11

Minimizing requests, using system fonts and using vector images are what makes this great because it makes the page loads so fast. Does 7kb really make much of a difference?

7kb specifically is not of major importance. If you're loading all content from one origin, fitting the content needed to load the page into the initial TCP congestion window does matter. 7kb of content will probably fit depending on how much non-content is in the packets.

This is not noticeable on a low-latency connection, but on a bad mobile connection it makes a massive difference.

Re: Delivering WordPress in 7kb

#22

Post by ryanf323 » Thu, Jul 12, 2018, 12:47 PM UTC

theandrewbailey wrote: post #16

dvfjsdhgfv wrote: post #9

Earlier quoted context omitted.

Not only you can, but in many (if not most) cases you should - because of performance and security benefits. The drawback is your site will no longer use the built-in WP search functions, but there are ways around that.

Couldn't you put WP behind a reverse proxy and cache the hell out of it?

We cache the hell out of our WP marketing site. Cloudfront > Varnish > Apache > OPCache > MySQL Query Cache. It feels fast to visitors. People in the admin area still suffer.

Re: Delivering WordPress in 7kb

#23

Post by jazoom » Thu, Jul 12, 2018, 12:50 PM UTC

Jarwain wrote: post #19

jazoom wrote: post #12

Earlier quoted context omitted.

I just opened and closed it a few times to try it out. Then I pressed the back button several times to get back here, cycling the menu open and closed again. I'm gonna go with "it's a bad idea".

If one really wanted to, couldn't they eliminate menu access from the user's history?

Yes. You can use replace() instead of push().

But there are other issues like bookmarking or sharing the page with the menu open. People won't expect the result.

It's really not difficult to create an on-page menu so this seems more trouble than it's worth.

Re: Delivering WordPress in 7kb

#24

Post by nicbou » Thu, Jul 12, 2018, 1:07 PM UTC

slig wrote: post #8

misterkola wrote: post #3

Why use wordpress at all? Just create a static webpage at this point.

WordPress themes are notoriously bloated and 1/4 of the web is powered by WP.

I've always made my own themes, and even those can be fairly slow without the standard caching plugins. Optimizing Craft CMS sites was a breeze by comparison.

Re: Delivering WordPress in 7kb

#25

Post by apeschar » Thu, Jul 12, 2018, 1:08 PM UTC

Reducing the amount of requests and roundtrips required to render the page, and reducing the latency on those requests is key.

For example, you use Google Fonts. For that you need to load CSS. So that's three roundtrips for rendering your page: 1) your page, 2) the Google Fonts CSS, 3) the font files.

We've build a WordPress plugin called PhastPress (fast press) that helps you reduce the request count and those roundtrips without building your own theme. https://wordpress.org/plugins/phastpress/

Among other things, it inlines the critical CSS needed for rendering the page, defers all script loads, and optimizes images. Cuts page size by ½ on the stock theme, and the amount of additional roundtrips to 0.

Re: Delivering WordPress in 7kb

#26

Post by apeschar » Thu, Jul 12, 2018, 1:12 PM UTC

firasd wrote: post #13

Interesting work. I wrote a bit about optimizing WP here: https://hackernoon.com/dont-brake-for-fonts-3-web-performanc... The most interesting thing I learned is that the number of HTTP requests (not just the total file size) really affected page load times. So for example, WordPress has profile pictures called 'Gravatars' that can be shown alongside comments. By default, your browser will make HTTP requests to fetch…

If you're interested in trying the same approach that Cloudflare took with Rocket Loader as a WordPress plugin, check out PhastPress. https://wordpress.org/plugins/phastpress/

This plugin also defers all scripts and tries to simulate all the events that occur during a normal pageload so that the scripts still run as they normally do.

Re: Delivering WordPress in 7kb

#27

Post by nattaylor » Thu, Jul 12, 2018, 1:15 PM UTC

ryanworl wrote: post #21

nattaylor wrote: post #11

Minimizing requests, using system fonts and using vector images are what makes this great because it makes the page loads so fast. Does 7kb really make much of a difference?

7kb specifically is not of major importance. If you're loading all content from one origin, fitting the content needed to load the page into the initial TCP congestion window does matter. 7kb of content will probably fit depending on how much non-content is in the packets. This is not noticeable on a low-latency connection, but on a bad mobile connection it makes a massive difference.

(Just got back from Googling.) So basically, if the content can be sent within the window then you save a roundtrip?

Re: Delivering WordPress in 7kb

#28

Post by have_faith » Thu, Jul 12, 2018, 1:16 PM UTC

Valiant effort. Slightly arbitrary in the finer details but the underlining message is good.

Removing the main menu (which is very small) while also having twitter meta info in the head and other unnecessary tags is an odd choice.

One slightly amusing thing is that in the web 1.0 era we had menu's as separate pages as our pages were built out of 'frames' and the menu frame simply targeted the main frame. So no we've come full circle again. The more screen real estate I have the more designers intend to put less information in it I've noticed.

Re: Delivering WordPress in 7kb

#29

Post by 5partan » Thu, Jul 12, 2018, 1:18 PM UTC

To put things into perspective, nweb is a webserver written in C which can serve static webpages, and its smallest executable is just 12kb in size:

https://github.com/ankushagarwal/nweb

Re: Delivering WordPress in 7kb

#30

Post by ryanworl » Thu, Jul 12, 2018, 1:23 PM UTC

nattaylor wrote: post #27

ryanworl wrote: post #21

Earlier quoted context omitted.

7kb specifically is not of major importance. If you're loading all content from one origin, fitting the content needed to load the page into the initial TCP congestion window does matter. 7kb of content will probably fit depending on how much non-content is in the packets. This is not noticeable on a low-latency connection, but on a bad mobile connection it makes a massive difference.

(Just got back from Googling.) So basically, if the content can be sent within the window then you save a roundtrip?

It depends on if you're loading from multiple origins (multiple TCP connections), HTTP 1.1 vs 2 (multiplexing, push, HOL blocking), but generally speaking: yes. If you can fit the content needed to render the page in the initial TCP congestion window, the page will be noticeably faster on high-latency connections.

This unfortunately means, for most websites, some amount of CSS in a style tag in the head to get a basic structure of the page together to start rendering. Then you also include a full stylesheet with the high-fidelity version.

I'm leaving out a lot of details here :)