Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
I have finished a website, and saw that there are white blocks when scrolling - site here. Happens on mobile and on desktop. It happens only on first load. Does it mean the page has not yet fully loaded? If so, I could show longer the loading screen, but need to know, how do I know when the page is loaded. If it's not because of that - what's causing that?
To reproduce: Open it in a browser and after loading screen use the mouse scrollbar to scroll down (using the scrollbar on the screen can't reproduce it).
Open it in a mobile browser, scroll down the page - here we can see it pretty obviously.
Not sure why you cannot reproduce it. Please see attached screenshot from my mobile. This happens when scrolling up and down.
On empty cache, your page makes 34 requests and its total page size is 23.7 MB. Out of which, there are 18 requests for images, and total download size for images is 23.3MB. Are you trying to load this site on user's mobile.
Downsize or web-optimize your images. The white blocks are coming because the container for the images is not completing load as the images are still being downloaded. Also, mobile cache sizes are lesser than computer cache sizes.
Checkout the chrome network tab on first or empty cache load of the site and you can see.
Once images have loaded, and your page is visited again. Its total data transfer is 5.7 KB but there are 34 requests still and stuff is rendered from cache. You can try to add far future expiry to your images if they will remain the same on your site.
Related
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.
I'm building a very small SPA (angular) website, put it has a large number of mid-quality images.
At the moment, when I have more than ~15 on the site, and go through viewing each of them (the site is a sort of image gallery), the page/tab/browser crashes.
How can I effectively manage this, so that more images can be used. Is there a way to unload images from the browser memory?
I have a problem on website where I'm using parallax.js ( matthew.wagerfield.com/parallax/ ). While scrolling page down to section where parallax.js appear it causes huge lags. Firefox doesn't have this problem.
Here is a screen from Chrome timeline:
http://i.stack.imgur.com/J77Tm.jpg
An example here
I'm sure that size of images doesn't matter because it happen even on 5kB images.
Basically I want the iFrame that contains my app to expand and shrink as the content changes.
I know this question has been asked a million times but Facebook has changed their JS API a whole bunch and as a result the previous answers to this question no longer work.
I've tried FB.Canvas.setSize(); as other answers have suggested but to no avail. Does anyone know the method that actually works at this point in time?
My app can be found here for reference: http://www.facebook.com/SandboxAppPage/app_441443775903676
Edit: I can't even get a basic skeleton app to behave and resize properly. My basic HTML skeleton (no html, additional js libraries, images, etc) is still fixed at the default 800px height.
Have you tried FB.Canvas.setAutoGrow? It should fix your problem. This function works only when Canvas Height is set to Fixed at 800px in app settings.
FB.Canvas.setAutoGrow(1000);
Here the function will be called in interval of every 1000 milliseconds and resize the window based upon your contents.
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.