inian

"Progressive" HN client just ships JS without any server rendering..HN is exactly the kind of application that you would expect to work without any JS.

This is the only research that claims progressive images aren't a good user experience though. I can't confirm with electrodes attached to my brain but personally I like progressive images better than baseline and they are smaller too!

Take a look at this talk on why mobile devices are so much slower than desktop devices ( they are indeed 10x slower in the traces I have looked at too) - https://youtu.be/4bZvq3nodf4

Also look at the speedometer benchmark (http://browserbench.org/Speedometer/) for a more realistic comparison of how slow your mobile device is compared to your desktop when running real world apps. Here are some numbers from the benchmark from some devices - http://benediktmeurer.de/2016/12/16/the-truth-about-traditio...

True that you need to keep your audience in mind but doesn't lend well to your claim of being the fastest site in the world either if it is fast for only a subset of people in the world

That is too big of a breaking change to do on the current web. There is a whole new initiative for that though - https://ipfs.io/

Also, the cache size on mobile devices especially on iOS is ridiculously low. I don't see my cache storage exceed more than 10 MB even though I use my browser a lot. High chance that you are _not_ going to find your common CDN libraries there.

Brotli offers better compression than Gzip, but most CDNs don't support it yet. Most CDNs assume that gzip is the only compression format on the web, making it hard to add support for newer formats like Brotli. This article goes into a way to get past these restrictions and support Brotli on your website.

The testing conditions that are used when developing websites aren't the same as what users experience - especially when they are on a mobile device which has lower bandwidth, power, etc. It is important to ensure that the site is usable from the user's perspective. This kind of testing is usually required for you to see how your site performs when there is higher latency, packet loss, single points of failure (when a domain is unreachable) and so on..

Though these are great tools to help us test, I still strongly recommend using real devices with real network conditions to do tests like these.

CSP is supposed to protect the website when there is a xss in it as a defence in depth solution. So a CSP bypass is when, it fails to do so. #1 - this is true for any site using CSP with javascript. #3 - the site is not giving the ability to inject the script tag. It is just an xss vulnerability which should have been caught by CSP, but in this case it doesnt.

It is not as simple as that. Even if videos are prevented from being auto-playing, people resort to much much worse techniques. For example, GIFs - which are much bigger that the corresponding video, worse for battery life etc. To combat this, Chrome recently enabled autoplaying of videos if the video is muted on mobile browser. Hopefully this gets the number of people using GIFs down.

Or who knows, people might start animating images on canvas or something. Allowing auto play in some conditions seems to be lesser of two evils according to me..

Lol I thought the article was about Hillary

We also realised that tackling web performance takes a lot of effort..so have been building different tools which can automate front end optimization techniques. Our recent tool (https://dexecure.com) tackles image optimization by generating different formats (WebP, JPEG XR), different sizes of images and compressed to different qualities depending on the device and browser the user is using. All of the images are served with a fast HTTP/2 connection.

We have seen people integrate with it in under 5 minutes and cut down their page size by 40%!

The you don't need jQuery website had a concrete use case - you need not include an entire library into your website for some simple tasks which makes your website faster.

Though, this site is cool in showing the power of CSS, I am not sure if there is any specific advantage of using CSS over JS to design tabs, sliders, etc. Just use the best tool for the job!

This article can probably be renamed to "why Javascript is bad"..only patents and dependencies issues were related to react native..the rest of the article was about how Javascript sucks..and I think developers are already equipped to take the call if they want to use js on a large project or not..

The article is from 2014. Though I understand the sentiment, most of the facts are false now

IIRC, Chrome was using the FileSystem API which was supported only in Chrome - hence the partial support for offline functionality in Google docs..Only recently have the specs behind Persistent Storage API and Service workers have matured. I would love to see Google docs to make use of these APIs to make the functionality available across browsers.

Also, PNacl -> Web Assembly which Google has supported.

Of course Android OSes are going to ship with Chrome as a default browser - at least you have the choice of installing a different browser if you want to. Unlike Apple, where all browsers are forced to use the same JS engine provided by Apple.

Google has been pushing web standards for a long time now - instead of platform specific APIs and saying that the internet is going to be only accessible from Chrome is stretching it quite a bit..

Support for this attribute is modern browsers is good but it is never used unless you visit the image directly via its URL or the like..It is going to be of no use when you embed the image in a webpage..Lot of times, I do a right-click -> open image in a new tab and see a differently oriented image and am actually confused by the behaviour..

Of course, if you are distributing the image URL directly, it is useful in that case..

Yup, I have covered this use case in the article

I just looked at JPEG files for this..should look at PNG files too..hopefully things are much better than that image you posted haha

Agreed, in those cases preserving the metadata might be the way to go depending on your use case. You just need to be aware of the trade off you are making..

Yup this information is indeed useful for a lot of cases (for photo editing software, etc.)..But for images delivered on the web it makes sense to preprocess them to strip off the EXIF data since it is mostly not used by browsers.

AFAIK Google doesn't use this data for indexing or SEO purposes..

Yup, just that your fast loading web page won't get the special treatment that AMP pages get on the search results page

One case where proxies are useful is when you do not know the properties of an Object before hand. Object.defineProperty cannot help you there..

Would be interesting to carry out a comparison with the MozJpeg format..

Hey guys,

This is Inian from the Dexecure team. We want to build tools to make it super simple for developers to build a fast performing website across different browsers and devices. New features that can speed up websites are being developed by browser vendors at an astonishing pace (picture tag, service workers, client hints, etc). We are looking at ways to help developers adopt these technologies easily.

As a first step towards that, we are excited to launch a product which optimizes all images on your website with a single line of JS code -- no server configuration needed! We are using Service Workers to route all image requests through our optimizing servers. The images are optimized and served according to the device, browser requesting it (Client Hints FTW) and cached on CloudFront's CDN.

Looking to get feedback from the HN community!

Part of this problem is solved via the Client Hints spec (http://httpwg.org/http-extensions/client-hints.html#save-dat...) When the user turns this on in his preferences, Chrome sends this data to the server as a header and the server can respond accordingly. Your server can decide what images to omit or other optimisations if it sees the header. But this setting is applied at the browser-level and is not per connection.

The NetInfo API can help in this case but the current spec is still not the best way forward. For example, even if the user is on Wifi, he may be on someone's tethered network and might still want to get a light-weight page. Conversely, some cellular connections might have a very high limit and the user might want to get the best possible experience even though he is on a 3G network.

A user-preference per network connection type would be cool to have!

Definitely not. Page load (thats the time the browser spinner stops spinning), first render, etc. are slightly better metrics.

But even page load time and first render times aren't without their own problems. Resources loaded asynchronously also count towards the page load time - however, they are not necessarily detrimental to the user experience. Similarly, some pages flash a white screen before contents actually starts to appear. In these cases, the first render also becomes meaningless since the user doesn't care about the "paint" of a white screen.

Recently, other metrics such as the speed index and [RAIL](https://developers.google.com/web/tools/chrome-devtools/prof...) have come about. (Just the initial page load time does not matter for a good UX)

Mostly there is no one universal metric for all websites. Think about what your user wants to do on your site and optimise for that metric. For example, Twitter optimises for the time for the first tweet to appear on the timeline :)

The DOM Content loaded in this test is 157 ms. WPT uses a confusing terminology when it comes to this (Document complete time != Dom content loaded time)

True it is not the same as the 65ms claimed in the article but its not that far off too.

The location of the test matters too. The time to first byte in your test is 82 ms - so there is no way DOM complete can happen in 65 ms in your case :) Probably try different locations for your test..

Oh thats why the dev build of React was there in the page. Makes sense!

A few points -

1. A direct comparison to Facebook's react Github page may not be fair. Their page is 10 times heavier than the blog page - of course its going to be faster.

2. Actually the Facebook's React page is not that well designed when it comes to performance. I see a lot of scripts included in the FB react page blocking rendering (codemirror.js, etc) even in pages where they are not used. If those are removed, the time to first render should drop down by a lot.

3. I feel a more apt comparison would have be comparing to a purely static page like a blog hosted on Github. Not a page which actually includes a live code editor!

4. No one says the page loads in the DOMContentLoaded time. It is mostly a useless metric when it comes to performance measurement.