I'm building an app using Vue 2. There's a page that contains a simple image gallery that contains about 20 images and one large page background image.
The background image of the page itself is actually contained in a fixed div element that is position: fixed;, has 100% width and height and uses background-size: cover; to display the image.
All of the ~20 items in the gallery as well are using div elements with background-size: cover; displayed in a 3-column grid and the images are displayed using the dynamically generated background-url CSS property using a Vue computed property. The image paths are never being changed so they aren't being recomputed constantly AFAIK.
The performance of this page in Chrome is abysmal, loading takes forever (those are some high resolution images, though, 4K in width) and once the images are loaded I can somewhat interact with the page but everything is extremely laggy and sometimes the page stops responding completely.
On the other hand, in Firefox and Edge everything is basically buttery smooth, both during the loading of the images and during the scrolling/rendering. The interaction with the app is never blocked.
What I remember trying to fix this is replacing the div elements with regular img tags and loading up images using those. Also, I've tried caching the images, I've tried using static image URLs for testing purposes - the same thing happens every time - other browsers handle it well, Chrome is choking on it.
Here's a screenshot of the performance summary in ~30 seconds, from the moment I click the page URL to the moment that basically everything is loaded and the browser is still struggling to render anything and process any interaction with the page. Obviously the painting phase is an issue here:
Any advice? Thanks!
This question is hard to answer as it is a very specific problem.
You can analyze what is causing this behaviour in chrome by using the developer tools:
Open the developer tools in chrome by pressing "Ctrl+Shift+I".
Go to the tab "Performance".
Hit the record button and do the action which has low performance.
Hit stop and you get a breakdown what happened in the background.
If you don't find the issue with above suggestion, you can post a detailed screenshot of the performance breakdown here, I might be able to help you with it.
Related
I use JS to create an Image() then set the src to be a PNG from a remote location (Amazon S3). When the image has loaded I attach it to the DOM with appendChild().
This works fine in most browsers but in IE11 nothing displays AT FIRST.
If I open the dev tools then the image element is there in the DOM but not visible in the actual display. As soon as I toggle a style (any style) off and on in dev tools it appears though.
It also appears if I resize the page (I'm not listening for resize anywhere) or select some text elsewhere in the build. If I click and drag on the area where it should be displaying then I get the ghost preview of the image and can drag it around but as soon as I drop it it disappears again.
Most weirdly, if I scroll the page so that part of the area where the image should be moves off screen then when I scroll back that part of the image is visible but the rest is still not rendered, as though it has been masked.
I've loaded this same PNG in the past and never seen this issue and I can't see that I'm doing anything different this time round.
Any thoughts? Or do I need to write another email to my boss asking why we even still support that manky old POS.
IE has planting of issues displaying PNGs, perhaps this might help https://perishablepress.com/css-hackz-series-png-fix-for-internet-explorer/
Built a Jekyll website based on a 3-party theme (MASSIVELY).
Code of website available here: https://git.ikrypto.club/FNB_Japan/FNBJapan
When you visit the deployed website, the background image does not remain constant as expected (You can kind of see the expected behavior on the theme demo, https://iwiedenm.github.io/jekyll-theme-massively/ (Edit: This is actually a better example, https://massively.ghost.io/ ). Basically, the background image is expected to remain constant, and the foreground should scroll with the user.).
You can witness the difference in behavior if you go on our website, https://fnb-japan.info .
However, when the code is ran locally and built with
bundle exec jekyll serve
The background image does not move (as expected). What's happening and how can I remedy it?
Note: It appears that this problem only appears on FF Nightly, and not Chrome
Edit: This appears to be a problem with Firefox Nightly, as opposed to the website. This question is technically resolved.
Edit 2: It appears that the problem persists, and is due to a bad implementation of parallax scrolling causing parallax to flicker.
Edit 3: This problem only occurs once the window is of a certain width, and the difference isn'ta ctually between local/deployed but rather different window sizes.
The background div (#bg)
is being transformed by
this code in the bundled parallax plugin (as evident from setting a "break on attribute modification" on the bg element in the Chrome inspector), which in kind seems to be activated by this invocation:
// Background.
$wrapper._parallax(0.925);
Removing those lines should get rid of the parallax effect too.
I am trying to make a website with a minimalist feeling to it, so I put a fullscreen image on the background as background-image of body. I have a transition: background-position 1s set as a CSS rule for body and an easing function, to create a smooth scrolling effect when going to other pages in the same HTML file (I have no actual scrollbar, just navigation elements). The thing I noticed was that once I started scrolling, the memory reserved by the page went from a small 77MB to over 500MB! I tested this in Firefox, but it doesn't seem to happen (either because pages have no separate processes or memory allocation works differently, I imagine). Why does this happen in Google Chrome and not in other browsers? And how can I reduce the enormous amounts of memory reserved by my page?
To give some information on what I am using:
Browser: Google Chrome
RAM: 8GB The page uses javascript with the
following plugins:
jQuery
Bootstrap
Background image dimensions are: 1440 x 540
A few possible causes of the problem:
The image is too big to be rendered with a transition and an easing function.
I should not use background-image for this, but create a new <img/> as a background.
I somehow only checked it with developer tools open in Chrome, increasing the memory allocated.
It's not the image causing the problem, but the web fonts I scroll simultaneously with the background image, also using transition and an easing function.
And I want to add that maybe this is not even a problem after all, it's just that I have never seen a page go over 300MB with memory allocation.
Not sure if this should be posted as a comment instead, however:
Nothing you can do about that. Chrome trades RAM for performance.
For instance each chrome tab runs on its own process for that purpose.
I had cases when a single youtube tab took over 1.5gb memory & virtual memory.
Even a blank tab takes 45mb memory for me.
So there is no issue with your code at all.
I am working on a PhoneGap web app for iOS.
I have an implemented an infinite list, where as you scroll down the page, new elements are loaded from the server and added to the bottom of the page.
Each element added to the page includes images that are loaded asyncronously.
However, the images do not actually appear until after scrolling stops. This makes things appear sluggish, even though they are not - ie until I remove my finger from the device.
Does anyone know of a workaround for this problem?
This funky work around for safari will do the trick for you:
*:not(html) {
-webkit-transform: translate3d(0, 0, 0);
}
This will add the translate property to all elements causing the IOS browser to render your off screen elements and give you a silky smooth native like feel. Remember to check your functionality as it can mess with positioning of some elements. If if does add them to the 'not' list e.g:
*not(html, button, img...
This cannot be avoided. Image rendering on webkit-gradient IOS is executed in a dedicated US thread with real time priority.
https://news.ycombinator.com/item?id=3316383
I've noticed the same problem while building my application. The UI consists of many images and it only appears to render what's currently on the screen and when you go to scroll, everything else won't render until it's finished scrolling.
A solution that worked for me was adding an overflow: auto; property to the containers in your layout. When I add it, everything renders and there are no problems when you scroll.
I've got an issue similar to this one:
iPad/iPhone browser crashing when loading images in Javascript
... but I'd like to clarify that my issue is caused by the same memory issue, and if so, what I can do about it.
I understand the proposed workaround of loading "tiny.gif" images for img elements that aren't in view, but the thing is, I'm not using loads of img elements. I'm using four. Three in a sliding div that slides in the next/prev image, and one that displays the current image while the sliding div is doing its sliding thing. It's a little hard to explain the mechanism, but the point is, there's only four image elements and I'm just continually swapping their src.
So what I don't get is.. if there's only four img elements in memory, how am I running up against the memory issue? If slide_one is an image with a src of one.jpg, and I change its src to two.jpg, surely one.jpg is cleaned out of memory, right?
Just a little background: I'm running a HTML page through a UIWebView as an iPad app. The behaviour I'm seeing is that I can load about 25 of these roughly-250kb-per-image JPEGs, and then it stops loading them (the src attribute is updated but the image stays blatantly unchanged). This sounds suspiciously similar to the 6MB limit I've heard mentioned, but I'm not seeing any warning or crash (at least, not in the iPhone Simulator where I'm debugging this).
Any advice gratefully received... :)
FWIW, I solved this by swapping bg image on the containing div rather than using an img element and swapping its src.
So either it's a bug that memory management doesn't allow more than x MB of images loaded, or it's a bug that bg images don't count towards that total.
Ho-hum.