5 ms·

It's physics, not perception. Just make your website fast. Am currently consulting big ecommerce bussiness on how to improve page load. I made them this 'faste

It's physics, not perception. Just make your website fast. Am currently consulting big ecommerce bussiness on how to improve page load. I made them this 'fastest page in the world' demo: https://turboeshop.com/fastestpageintheworld/ https://turboeshop.com/fastestpageintheworld/ - kindly please check it out. And here is fastest page with Google Analytics: https://turboeshop.com/newstackonly/ https://turboeshop.com/newstackonly/. 325 ms for fully loaded time CSS + images + HTML + JS + GA loaded + Measurement Protocol hits sent. This is what fast website is: a) inline purged css; b) everything loaded from one domain, 100% cached. c)inlined js(vanilla + web component if you need one); d) inlined images up to 4kb; e) larger images loaded from cache from same domain. f) gtag.js and analytics.js -> from cache; g) Measurement protocol hits sent from async proxy on edge. h) 100% cloudflare cache hits; i) Cloudflare workers for dynamic bits; That's all what it takes. Don't read articles- just make it fast, it's really that simple :) And as svelte was mentioned - if you want to improve a website that is bigger than your personal blog, you don't use svelte, react, gatsby or any other of that breed as it's impossible to do serious marketing with a website that's hydrated (svelte's web components is a wonderful thing though and is totally nice addition to marketing stack). I mean no insult to anyone with my strong opinions and would be glad to have discussions in comments. UPD: Added note on Cloudflare & Cloudflare workers.

nattaylor 6y ago
I would think you want gzip enabled if you're sticking everything in a text payload
- toinbis 6y ago
  Very good point! Thanks - will take care of that! :)
oblio 6y ago
Your page is quite fast, but if you want see fast, check this out: https://forum.dlang.org/ 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.
- toinbis 6y ago
  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.
- fuzzy2 6y ago
  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!
- cambalache 6y ago
  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
EvanAnderson 6y ago
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.
XCSme 6y ago
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.
- toinbis 6y ago
  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.
tukinaf 6y ago
For a blogging platform that loads fast, it’s hard to beat https://bearblog.dev https://bearblog.dev as it’s pure html with no js and style sheets all in a single call.
2rsf 6y ago
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.
- rmac 6y ago
  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?
  - 2rsf 6y ago
    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
    - rmac 6y ago
      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...
      - jlokier 6y ago
        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.
city41 6y ago
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.
- toinbis 6y ago
  Hey! Sure - been there done that https://stackoverflow.com/questions/57556599/how-to-render-nearly-empty-page-without-any-overhead-with-gatsby 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-spa-like-navigation-in-sapper 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/ https://turboeshop.com/fastestpageintheworld/ built with next.js(never mind the domain name): https://gatsbyeshop.com https://gatsbyeshop.com . Will update my initial comment as well.
  - city41 6y ago
    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.
    - 6y ago
toinbis 6y ago
Kindply please also find a page identical to https://turboeshop.com/fastestpageintheworld/ https://turboeshop.com/fastestpageintheworld/ implemented with next.js(ignore the domain name): https://gatsbyeshop.com https://gatsbyeshop.com . Of course the 'identical' is relative saying, as next.js has to bring on it's bundle.
dmichulke 6y ago
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 https://www.cryptoport.net
- toinbis 6y ago
  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.
zitterbewegung 6y ago
Hey, can I use your fastestpageintheworld as a template for my own site? Thanks!
- toinbis 6y ago
  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/ https://turboeshop.com/inlinedimages/ is all page in one requests. Meaning two big images that are https://turboeshop.com/fastestpageintheworld/ 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/ 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-analytics-client-server-side-tagging/ 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 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 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 https://github.com/segmentio/analytics.js instead or check out https://www.thyngster.com/app-web-google-analytics-measurement-protocol-version-2 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 :)
hypertele-Xii 6y ago
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.
rathel 6y ago
Holy. Fuck. You weren't kidding. This is blazing fast. Thanks for the tips, definitely bookmarking this as a reference.
- 1996 6y ago
  But there is little content. For speed, also check cryptomarketplot.com - essentially the same techniques
nicbou 6y ago
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
dector 6y ago
> 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.

nattaylor 6y ago

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

toinbis 6y ago
Very good point! Thanks - will take care of that! :)

oblio 6y ago

Your page is quite fast, but if you want see fast, check this out: https://forum.dlang.org/ 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.

toinbis 6y ago
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.
fuzzy2 6y ago
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!
cambalache 6y ago
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

EvanAnderson 6y ago

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.

XCSme 6y ago

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.

toinbis 6y ago
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.

tukinaf 6y ago

For a blogging platform that loads fast, it’s hard to beat https://bearblog.dev https://bearblog.dev as it’s pure html with no js and style sheets all in a single call.

2rsf 6y ago

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.

rmac 6y ago
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?
- 2rsf 6y ago
  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
  - rmac 6y ago
    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...
    - jlokier 6y ago
      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.

city41 6y ago

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.

toinbis 6y ago
Hey! Sure - been there done that https://stackoverflow.com/questions/57556599/how-to-render-nearly-empty-page-without-any-overhead-with-gatsby 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-spa-like-navigation-in-sapper 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/ https://turboeshop.com/fastestpageintheworld/ built with next.js(never mind the domain name): https://gatsbyeshop.com https://gatsbyeshop.com . Will update my initial comment as well.
- city41 6y ago
  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.
  - 6y ago

toinbis 6y ago

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

dmichulke 6y ago

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 https://www.cryptoport.net

toinbis 6y ago
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.

zitterbewegung 6y ago

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

toinbis 6y ago
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/ https://turboeshop.com/inlinedimages/ is all page in one requests. Meaning two big images that are https://turboeshop.com/fastestpageintheworld/ 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/ 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-analytics-client-server-side-tagging/ 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 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 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 https://github.com/segmentio/analytics.js instead or check out https://www.thyngster.com/app-web-google-analytics-measurement-protocol-version-2 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 :)

hypertele-Xii 6y ago

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.

rathel 6y ago

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

1996 6y ago
But there is little content. For speed, also check cryptomarketplot.com - essentially the same techniques

nicbou 6y ago

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

dector 6y ago

> 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.