151–160 of 182 posts
A weird complaint if you ask me. Browsers and developers should try to do their best with limited resources. So it most cases that means making predictions about user behavior. Sometimes that means preloading content (e.g. if you're on a landing page, preloading content from the next likely page will make the it feel much more performant) and sometimes lazy loading to not waste resources if a user isn't going to see…
Instead of all the complexity and code and branch predication, how about just send the page and the images? If lazy loading is super important, the browser can lazy load and render off screen. Don't make thousands of solutions for thousands of platforms on the server side.
Before the loading attribute on img, developers did have lots of custom solutions for lazy loading. A major point of lazy loading is to save resources on the server that would be wasted when serving an image that is never seen.
Lazy loading breaks a lot of functionality. For example, I open a webpage and then go offline. Later, I scroll down, but the content is missing. Another time, I open a webpage and save it. But most of the content is not saved, because it has not been loaded. The network activity is actually higher for a page with lazy-loading elements. All-around, it does not make any sense to me, personally.
could hold down the space bar until you are at the end, then save.
Earlier quoted context omitted.
it hurts SEO. In my case the user can live without those images, so it's a sacrifice I'm willing to make. This is one of the big problems with the modern web, It puts you in this doom loop: sacrifice the user to please Google to get users.
The performance metrics in pagespeed/lighthouse etc. are not really assessing performance directly. You can have a slow, bloated website but great metrics, because you’re doing the “right” things. However lazy loading images that are not on screen is generally a good thing. Images are typically the heaviest part of a website and loading them only when needed is good. The article in question acknowledges that, but is…
No. An article should always be loaded in full. I clicked a link to a document, that means i wish to view it. Not half, not the first page, the whole thing. If you have tons of content in a single document, you should probably paginate anyway. Images are usually few, and if not totally unoptimized (which you should do before lazy loading), not a huge drain. By all means, lazy load all the unimportant banners, ads and UI elements. Better still, don't add them at all. Only for infinite scroll would lazy loading make sense, and even then batched by 10-20 ahead (or more), so I don't spend time waiting half a second for each and every image.
The heaviest part is nearly always ads and analytics. Cut those down first.
Earlier quoted context omitted.
If I understand correctly your beef is with the fact that they don’t have an “Apply filters” button and not lazy loading? Also they’re probably not trying to save bandwidth but database servers.
I just don’t get it. There’s nothing that could beat an one-time json download per product category. Not even “apply filters”, which I see less and less often with years. Unless a store has thousands of products and vague categories, ofc (but not in my cases). If there is something beyond Hanlons Razor, I’d like to understand by which metric it works and how. E.g. how fetching 30 rows 10 times through different param…
Earlier quoted context omitted.
If I understand correctly your beef is with the fact that they don’t have an “Apply filters” button and not lazy loading? Also they’re probably not trying to save bandwidth but database servers.
Not OP, but I think the beef is that the act of applying a filter requires a reload of anything at all ("hey, server, please send me the list of only 16GB pairs this time"), when it's perfectly possible to just send the full list of items to the client initially and then have filtering apply instantly, client-side, on that already loaded list. At least that's the beef I have, and was reminded of when reading the pare…
Earlier quoted context omitted.
Why stop bots though. Price comparison sites are amazingly useful.
Competitors use them to ever so slightly undercut your prices, get a higher position on said comparison sites, and run you out of business.
Earlier quoted context omitted.
Not OP, but I think the beef is that the act of applying a filter requires a reload of anything at all ("hey, server, please send me the list of only 16GB pairs this time"), when it's perfectly possible to just send the full list of items to the client initially and then have filtering apply instantly, client-side, on that already loaded list. At least that's the beef I have, and was reminded of when reading the pare…
Then the server send you 2k products every time because you might want one? This is insanity.
> There's no way to disable Lazy Loading on Android Chrome or Android Firefox. I haven’t tested it, but I would expect that Firefox for Android would still support going to about:config and changing… hmm, looks like dom.image-lazy-loading.enabled is no more, so I suppose you can just set dom.image-lazy-loading.root-margin.bottom to an enormous number (probably don’t need to worry about top/left/right, but you can do…