Hacker News Reader

You can get the best of both worlds with Gatsby plus gatsby-plugin-no-javascript. Gatsby inlines critical css and small images and does just about every trick available to minimize page load, then the plugin kills the hydration. The plugin can run on a per page basis, so you can still keep your hydration on your pages that need them. For complex webapps that also have marketing/documentation/landing pages, it's a really nice combo.

Gatsby devs or advocates would argue removing the js removes the preloading of pages that helps make Gatsby faster. Although this is true, in my experience removing hydration is often a better trade off. It of course depends on the site.

Hey! Sure - been there done that https://stackoverflow.com/questions/57556599/how-to-render-n... :) Sapper, however, will not let you do that easily https://stackoverflow.com/questions/64507516/how-to-disable-... . I think with next.js it's somewhere in between - possbile, but not easy. And I totally buy the approach of being able to use and mix both according to the needs. My personal favorite for html+css composition is to develop components with react, deploy them on bit.dev and render with react.renderToStaticMarkup in backend with express.js Turboeshop.com is made exactly that way. BTW, there is identical website to https://turboeshop.com/fastestpageintheworld/ built with next.js(never mind the domain name): https://gatsbyeshop.com . Will update my initial comment as well.

I feel like we're in a transition period where we will eventually get both the nice developer experience and flexibility combined with nice performance. Gatsby gets there largely by accident and in a crude way. I'm hopeful over time all these tools will get there explicitly. It sounds like Remix might also be a nice catalyst in this department.

So glad to hear someone else feeling that way :) Thanks a lot for sharing - feel exactly the same way. We'll surely get there, fingers crossed for that happening sooner! :)

Not 100% comparable but of course the shortest JS/GA are no JS/GA.

Additional benefit: privacy

If you leave out the cookies as well, you don't even need to ask for allowing cookies.

I use this approach for my cryptocurrency portfolio site [1], comments welcome

[1] https://www.cryptoport.net

I personally am 100% that site should work without JS (as well). Some UX might demand dom manipulations, so at least personally of having both. And for excluding GA - that's firstly a topic of specific business and it's philosophy. Technically if you collect server logs - you still have to get user's consent probably.

Kindply please also find a page identical to https://turboeshop.com/fastestpageintheworld/ implemented with next.js(ignore the domain name): https://gatsbyeshop.com . Of course the 'identical' is relative saying, as next.js has to bring on it's bundle.

I would think you want gzip enabled if you're sticking everything in a text payload

Very good point! Thanks - will take care of that! :)

Oh, wow. I loaded those pages on an older mobile device and those pages loaded like they were on a server on my LAN. Just wow.

Holy. Fuck. You weren't kidding. This is blazing fast. Thanks for the tips, definitely bookmarking this as a reference.

But there is little content.

For speed, also check cryptomarketplot.com - essentially the same techniques

Your page is quite fast, but if you want see fast, check this out: https://forum.dlang.org/

It's a bit ugly but I imagine with some proper CSS the could make it nicer looking but still fast.

Thanks a lot for sharing, will look into it for more tricks. Yet gtmetrix.com scores it at 1.0 s. Time-to-first-byte is 0.5 as CF gives 90-130ms TTFB out of box.

Cool stuff. But it already has _too much_ CSS! ;-)

The fonts kill it. On my iPad the page had finished loading but I could not see any text until finally the font had finished loading.

Don’t use external fonts!

It loads noticeable slower for me (~2X), I am getting the same numbers as OP. Btw congrats OP it really loads fast and not "react" fast

All is nice but a lot of the slowness in our bank's site comes from fetching the client's data, I'm sure this can be improved but the requirement for layers of abstraction and security to fetch a customer data is a tougher problem.

Is there a way to securely pre-fetch data from the db? If I have a valid cookie why is my account snapshot not getting fetched when I hit Citibank.com?

If I mark "remember my username", and I hit citibank.com, can't the banking back end start fetching my account snapshot when my browser hits / and then send over that data as soon as I authenticate?

I'm out of the loop so maybe this is already done or too complicated?

Fetching can start only when you are authenticated, by then you already want to see your data.

Obviously you can "cheat" by having a start page with no data or something similar, but that's not what we are trying to achieve

What about encrypting every users account info, and then when a GET comes in the server sends over everyones data that has ever logged on from that IP address? The client would then decrypt their own data. If compressed, then encrypted it could be small enough? Probably too complex tho...

If you're going to send data speculatively by keying on IP address, why not key on long-term user-id cookie instead? That is more accurate and potentially more secure, and for many people the cookie changes less often than their ephemeral IP address anyway.

But if the client data is small enough, that wouldn't actually reduce the latency to speed up the page load, if these assumptions hold:

- Getting the decryption key is subject to an authorisation round trip; current data fetch is subject to the same round trip; and the client data is small so sending it takes about the same time as sending the key.

But the round trip can be brought to a minimum by not requiring a large page full of HTML/CSS/JS to be send on auth - just requiring the client data (or key as you suggested).

All the parts which don't depend on client data can be preloaded asynchronously after the login page is shown, including a template for the page ready to be populated when client data is received.

So:

- Make the login page as fast as possible, using inlined data etc. like any static page. Make the page cacheable, probably validated with an Etag. The remembered "your name" field can be populated, that's fine even if it's cached because the browser cache ("Cache-Control:private") is unique to the user.

- Have the login page preload all non-client-data dependent resources for the next page asynchronously, but ensure these don't start fetching until all resources for the login page itself have finished being fetched.

- When password is entered, perform auth and get client data in a single round trip, combine with the templates just loaded to load the new page.

- Use 0-RTT TLS for everything.

Each interaction will be about as fast as possible while validating with the server, but you can go further if you're ok with relaxing that:

- Make the first page load "instant" by changing the cache policy to validate after a timeout instead of just on Etag.

- Asynchronously preload all the resources for the authenticated next page except the client data.

- Make the authenticated next page "instant" by detecting when the user appears to have paused typing in the password field (or immediately without pause if it's refilled by a password manager or user paste into it), and before they hit enter or click submit, send speculative auth requests which return client data if they succeed, but don't treat the user as properly authorised until they do enter/submit. When they do, use the preloaded client data if it's already arrived (and the password field hasn't changed), and also send an auth-confirm request.

At one company we tried to do better than this. The bank login form version of the feature we shipped would be to send an XHR (well, in current year, a websocket message) per keystroke in the login form and preload the front-page data for all the users with the appropriate prefix once there are few enough of them. When the front-page request comes, the data should at least be in a memcached instance used by the relevant service, rather than in a DB owned by a different service.

The "remember your username" usually means persisting a user ID in the cookie session, and the core banking backend does not know shit about cookies or front-end users, the request needs to be mediated and properly authenticated in a way that is compliant with security regulations.

You could conceivably pre-render the backend results before hand but then on first load the visiting user would not see her latest transactions --which is a very frequent use case.

As a side note, it's amazing how modern banking sites keep being really fancy interfaces to years old COBOL backends.

Not too complicated at all. US banks are pretty fully PSD2'd at the moment, Whether they wish to roll out to you is different.

Thanks a lot for your comment. I think it is important to note that max page speed is not a top priority in most of the cases. Banks, SaaS self service, etc. etc. - it's where it's probably not that much crucial. But - as always - it depends. Having that said - I am planning to develop 'fastest SPA in the world' toy demo with auth0.com, https://github.com/signalnerve/workers-auth0-example edge-side auth0 authentication and faunadb.com instantly-consistent cloud DB. The auth part of SPA sign in is just way too annoying for me. But yeah, hardly bank would ever sign for such stack, or at least a single part of it :)

I get similar timings for my website on a DigitalOcean VPS. It's not that difficult, as long as you can cache your content.

A few other things: GZIP and HTTP2 help a lot

Just a random note: both versions of your website seem as fast (instant) to me ona PC with good LAN connection. I wouldn't know there is a loading time difference unless looking at the numbers. Things might be different on 3G mobile though.

I've have set page load monitoring for employees and clients in grafana. Been asked to add device/locations dimensions. That's OK to know and understand how tech stack influences customer's journey. But that info has no impact on looking for a ways to optimize site even further. On slower device - site will be somewhat proportionally slower, but will remains times/percentage faster than any alternative being crafted without taking care about performance - related aspects. Key to understand that once you put your website under Cloudflare or any other CDN, it'll always be very close to where you live. I do not know for sure but I think I live 1.5km from data center where Cloudflare is hosting their server :) Of course here comes the rendering part. But if you have minimum JS, and sane images, and class-based CSS (they say it's fastest) - what is it what can slow you down? If delivery is fast because of cdn, rendering is fast because of sticking to basics and best practices, I think you have it all covered.

> It's physics, not perception.

I guess both counts. :)

But I agree with you that core problem is that many websites are ACTUALLY slow and bloated.

Hey, can I use your fastestpageintheworld as a template for my own site? Thanks!

Sure! :) But I think it's all just about few principles. Elaborated a bit more on them:

1. Tailwind CSS classes extracted with purge-css, all inlined.

2. Favicon inlined, small images (<4kb) inlined. Not sure what’s the best threshold. Here is all https://turboeshop.com/inlinedimages/ is all page in one requests. Meaning two big images that are https://turboeshop.com/fastestpageintheworld/ were inlined - results are way worse. So larger images - definitely excluded.

3. Gzip stuff(as one commenter below commented, not done in turboeshop.com/fastestpageintheworld/).

4. Everything from same domain and subdomain. If you want cloudinary or friends, I guess they are only allow subdomain. This is totally OKeish exemption. Or maybe there is a way to work around that cloudinary serves, Cloudflare caches.

5. JS - inlined. Cash.js maybe if you need jquery replacement, or just vanilla. Little content on vanilla js nowadays :), https://gomakethings.com/articles/ is something interesting. Don’t want to flame here, am not js expert, maybe someone can elaborate.

6. For compex components - svelte web components (or stencils or lithtml) - I’d prefer svelte but am not sure what’s best.

7. Google analytics a) - there is new google analytics (GA4) with measurement protocol2 and new server side google tag manager. Serve side gtm does two things a) serves gtag.js; b) accepts measurement protocol hits and sends to GA. Take a look how it’s done - https://www.simoahava.com/gtm-tips/build-custom-universal-an... , it’s very similar as cloudflare workers, cool stuff. But it’s hosted on Google App Engine, thus - slow. But you don't need google's server anymore, you control full infra, so why not setup simple cache here.

8. Google analytics b) To owerome latency to Google App engine, so you make async proxy in cloudflare workers - one worker to proxy for gtag.js download, one for serving gtag.js from your own domain. <script src=“http://yourdomain.com/workers/gtag/js?id=G-1234455> . Basicly just serve from js cache and check every once in a while if google hadn’t changed their code. Same for GA hits. It used to be google-analytics.com/collect endpoint, server side gtm allows to host collection yourself. You again make worker-proxy, define it in gtag’s transport_url:'https://turboeshop.com/measure' setting and make sure worker returns non-blockingly, and just then forward the measurement protocol hit from worker async-ly with event.waitUntil().

9. Google analytics c) The gtag.js/analytics.js is a huge file and you have no control, so maybe just use https://github.com/segmentio/analytics.js instead or check out https://www.thyngster.com/app-web-google-analytics-measureme... (search “navigator.sendBeacon”) - craft measurement protocol yourself and send it to gtm. I plan on investigating this but have not yet done that.

10. All the stuff (fb tracking pixel, etc.) you are used to just ‘putting in html’, you instead send as measurement protocol hit dimension and do ETL in google tag manager.

11. All the 3rd party stuff that demands to be executed client-side - you just don’t use that :D (or use, but wisely)

12. HTML - bussiness as usual.

13. So after page reload - double check if all requests are done/received from your own domain. Use curl on each of them to find header CF-cache-status: HIT. They have this ‘varied’ or similar status which means something I can’t remember, but I always fix stuff till ‘Hit’ :)

14. I guess that’s it. Enjoy your own fastest website in the world :)

An additional micro-optimization you can do is strip the excess whitespace from the output HTML. I'm seeing tabulation spaces and useless linebreaks there between tags.