I am trying to find the bottle neck in this site here. Granted, there is not much on the page now, but I will be uploading nearly 300 images to this site in the coming week which I expect to take a toll on speed and performance. Therefore, I want to cut down on everything other than image loading as much as possible.
I've attached an image which shows what I'm seeing in SpeedTracer, but the data makes no sense to me. The page loaded in around 4 seconds, yet each of these blue bars is claiming to have taken ~ 3.5 seconds to load. How can this be?
Could someone try to provide me with some explanation as to what I'm looking at here?
Thanks,
Evan
What you're looking at is a waterfall of the page and it's resources loading...
Each row represents an individual resource, and show's when it started loading and how long it took.
Browsers can download resources in parallel - Chrome can download up to six resources from the same hostname e.g. www.nanisolutions.com, at the same time. It can also download up to six resources from every other hostname at the same time (up to maximum of 40 connections)
Quite why you screen grab shows the request for the root HTML document starting after some of the items I'm not sure but I'm wondering if you are on the same network as the webserver?
I'd be tempted to run the same test using webpagetest.org
Related
NB: since the answer to this could involve JavaScript or PHP programming, or general networking, or IT systems, I put it here, but if some mod thinks it's better suited for SuperUser or ServerFault, I won't object to it being moved.
I have a landing page to which I'm driving traffic through PPC. I've set up AWS CloudWatch to get RUM data, and the page is performing terribly — an average load time of 9.9s and max of 21.5!
I've done all of the "standard" optimization I can think of or research. The site is built with WordPress, running on Apache on an EC2 server. I've
Upgraded the EC2 instance to ensure I have enough memory
Written a custom plugin to filter out any other plugins that aren't explicitly used on the landing page in question
Customised my theme code so that it sets proper srcset and creates the correct image sizes on upload
Minified all the JS and CSS that I include through plugins or themes I've written
Put the site itself as a distribution to CloudFront
Installed the WP Super Cache plugin, and created a separate CDN distribution on CloudFront for it
Set appropriate cache control headers on CloudFront and told it to gzip everything
Put a facade in place of any videos
The site is blazing fast for me — "load" is less than 1 second. But my RUM says that's not the case for my users. So, I dug a little deeper. 70.2% of my visitors use Chrome, and 27.7% use other, of which almost 1/3rd are Android Browser — which as I understand it is just some sort of "Chrome Lite" — so nearly 80% of my visitors are using some Chrome variant.
Sure enough — if I load the page on Safari (to ensure nothing has expired on CloudFront), clear my browser cache, and reload the page, the first request shows a waiting time of 21.2ms, TTFB of 22.6ms, and download time of 4.8ms. The whole page shows that it's finished loading in 973ms.
Firefox is slightly slower, with the first request taking 100ms total, and the whole load about 1.75s — not blazing fast, but still within the understood "2 second" limit for good user experience.
On the other hand, for Chrome that same first request takes almost 570ms waiting and 208ms download. So, just the first request (which is 36k in size) takes almost as long to load in Chrome as the whole site takes in Safari. And that repeats for every single request, where both the waiting time and the download time are an order of magnitude slower on Chrome than on Safari (on the same device on the same network):
Whereas on Safari:
I would think "waiting" and "download" times would be primarily network driven, but I can repeat this all day long and the results are the same.
I might just assume that Chrome is not optimized for the Mac on which I'm running it, but, as I said, this all started with RUM data, so it's clearly not that. As much as I might like to, I obviously can't force all of my visitors to swap their Android devices for iPhones. Equally obviously, I can't have an average load time of 10 seconds.
So, why is my site so slow on Chrome? What else can I do to optimize this?
The landing page in question is here: https://www.chrisrichardson.info/lp/prague-b/
Note, a lot of the optimization I've done is for that page in particular, so other pages on the site might perform even worse, but I don't care about that, at least at the moment.
Hahahaha.
OK, just leaving this here for posterity's sake. The 10x latency was because Chrome had preserved in devtools from a previous session throttling to 3G. So, if you stumble upon this problem, check your throttling.
That still doesn't address my RUM issue, however, but I'll open that up as a different question.
I'm trying to find the source of some "idle" time within a certain page I'm accessing on our system. The problem is weird though to me, as I cant tell the reason for the delay. I'm running this in a single instance of chrome, no other tabs or anything.
The initial load time looks like this:
So it takes a while. But if I refresh this page within 7-8 seconds it will come back really quickly.
I initially though it was a system process on our end and ran Yii's profiler which came back with:
So, it seemed to be a non "system" issue, so went to Chrome's dev tools and the profile comes back with this:
I've read the other question What causes Chrome Timeline Frame to have so much empty white space also.
I'm trying to understanding if it's possible to identify the problem at all and why the page is rendered quickly if the page is refreshed after a few seconds of loading and why it takes so long if the refesh is called after 7-8 seconds of the initial load?
nb Some of the times might not match up as I've run the various profilers a few times. So they might apply to different page refreshes. But you can see the general trend :)
I have a website that runs just fine on my local server. It's quick, responsive, and overall runs great.
But when I put it on the server of my domain host, sometimes it takes excessively long to load assets. For example, one 1MB png file took 2.31 seconds to load:
Chrome's Network Developer Tool reveals to me the following:
So is this likely due to poor implementation of my code or is it possibly a crappy server? (The company is subscribing at the lowest tier possible to host their content) My internet connection is quick so I doubt it's that.
I think it is probably a problem with your host. An image is an image :) there aren't a 100 ways to implement one!
Oversized images always take longer to load, so you should keep your images as small as possible.To lower down the content download time, you can optimize/compress the image without degrading it's visual quality.If you are using any graphics software to optimize the images, you should use “Save for Web” option. This will reduce the size of images and hence image load time.
Furthermore, you can use CDN to serve static assets of your website like, images, CSS,JS, videos, etc. A CDN populates your website files to geographically distributed network of servers called POPs. CDN serves the website resources from the nearest geographical location of a visitor, that means your website assets will load more faster.
Use SSD based host. SSD has excellent read/write rates compared to that of traditional HDDs. Hence, solid state drives perform better than hard disk drives and they are almost 100 times faster than traditional HDDs.
Here's a question for you
Is the image you're trying to load in background, or its an image tag?
I'm using the new local storage that html5 offers.
When my mobile app (using phonegap) runs, it first goes to the server to get a list of members. The list doesn't change very often, so I was thinking maybe to keep it in the local storage and just refresh it every week or so.
My question is if it's right to do so, because it's a list of 900 people. Not too big but also not small.
Thanks.
900 people with (I guess) 5-6 fields for each one of them is around (did a test in my db with a text file) 45kb overhead.
Most phones and tablets now can live with that. (Aka, putting a bigger image in the background is going to load your app more).
So go for it.
Adding BackgroundTransferRequest's to the BackgroundTransferService once the app is in the background is successful, but the new requests don't actually run until the app comes back to the foreground. Not so great for my scenario of downloading lots of small files that may take a fair amount of time to complete.
I imagine Microsoft has probably implemented this behavior by design(?), but does anyone know a way around this or an alternative approach?
A bit of background to the problem:
I'm developing a Windows Phone 8 map app that allows sections of maps to be downloaded and cached for offline use. This process can lead to 1,000's of map tiles needing to be downloaded.
I've created a process that spawns the full limit of 25 BackgroundTransferRequest's, then adds more to the BackgroundTransferService as requests complete. This all works fine until the app actually goes in to the background.
I have considered doing some web server side processing to allow tiles to be bundled in to a zip and downloaded as a single request, but this is extra complication and will result in twice the space being required on the phone to complete the download and then extract the files before deleting the original package. But, ideally I'd like to find a way to force new BackgroundTransferRequest's to start running in the background.
It's not clear what your actual question is but I'd definitely recommend bundling them into a zip file and then downloading that. It's almost always easier to work with a single file than thousands.
If disk space is really a genuine issue (not just a theoretical one - I've put thousands of map tiles in under 20mb before, but it will depend on image complexity & quality) then you could make a few zip files. then you'd avoid the BTR issue and not take up as much disk space (even temporarily).