I'm working on this web app for which I'd like to cache some static content to lower loading times on a slow connection. Other parts are being generated through PHP and AJAX and can therefor not be cached.
I'm successfully using the cache.manifest to cache the static content, such as images, but I notice that the dynamic pages aren't using them. Instead they are downloading the images again, even though they have been cached, making the caching useless.
Because my dynamic content is generated based on GET-requests the dynamic pages are in the NETWORK section of the manifest (e.g. "user?*"). Might that have something to do with it? Is there a way to maybe force using cached images?
Note: the exact full reference to the dynamic pages (e.g. "user?id=22") is of course not in the manifest. Does that make the cache unreachable for those pages?
Seems I've come up with my own solution.
Since caching dynamic pages (e.g. "user.php?id=22") broke my application I tried inserting an iframe containing a reference to the manifest instead of referencing it on the page itself. That did not seem to do it for me.
I now include an explicit reference with a wildcard to the dynamic pages in the CACHE section of the manifest. That does seem to work. They are now not getting cached entirely with parameters et al. (so the application remains functional) but are using the cached images. Might not be ideal but seems to be a pretty simple solution.
I have not yet tried removing those iframes but my guess is that they can be removed.
CACHE MANIFEST
./user.php
./user.php?*
etc...
NETWORK:
./db_connect.php
etc...
Related
Is it possible to cache all page, but do not cache a part of it in the browser?
For example, i have a page with date. Only date is changing daily, the rest of page never changes. How i shall cache such a page in the browser?
Could on the browser cached page contain dynamical content?
Actually, i am new to caching, i do not understand how it works with dynamical content and browser caching. Is this right, that from the moment some dynamic page is cached, it is served always as it was after during the caching, and new dynamic content is not displayed?
I do not ask about the server side caching, only about the browser side caching.
There is no specific tool for ignoring caching a part of the page. but you can do some tricks like:
You can cache whole page and change the part you want by iframe!
You can cache whole page and change the part you want by ajax!
You can cache whole page and change the part you want by a javascript
file!
i have not checked iframe solution and not sure if it works.
If the js files has cache, you can add a version in their file name like scripts.v.2.3.js and load them by version name.
You can't really dynamically cache "part" of a file, you can however cache separate assets the more you split your page into separate assets the more you can cache each one of them separately.
Your index.html could have a cache setting of dont-cache (using the Cache-Control header)
Your logo.png could have a long cache set of 10 days
Now if you want to have certain elements changing but the core to stay the same then I believe this would be a better job for JavaScript. What you could do is write a Javascript function to display the date, then you can fully cache the HTML page and the Javascript page and since the raw content never changes (only the manipulation of the DOM does you have very little client->server requests.
My website is incredibly slow, or at least the fonts are, and I am getting massive amounts of FOIT. I have solved this by putting a spinner on the frontpage, which does not display the website until the fonts are loaded. However, when I then visit other pages, I still get FOITs - how come? I thought the font was loaded now, and would not have to be loaded again?
If this is not the case, can i somehow cache it and save it, once its loaded?
I am using normal HTML, PHP, CSS.
See this post which describes how to use a font face loader and monitor to avoid "Flashes Of Invisible Text" (FOIT.)
To answer specifically regarding caching of fonts once loaded: this should happen, so there may be one of the following issues occurring:
Your server is not sending the appropriate cache control headers for the fonts resulting in them being re-requested on subsequent pages.
Subsequent pages are referencing different font files or font files at different URLs than your main page.
I am working on Magento(EE). I found a term "Full page caching". Can any one please tell me what is "full page caching in Magento or in Zend ?
Caching the full page?
As in every thing that is generated from a script is written to HTML and served next time, improving performance (by reducing load and not having to generate the page for every visit).
However this comes as the disadvantage of having occasionally out of date pages.
If you website isn't getting a significant amount of hits, enabling full page caching or caching of all the HTML it going to make little difference
Magento is a shopping website CMS.
It simple means that to boost the performance of the website, it will cache (store in buffer) the HTML output of a particular page. For example, your homepage, everytime user opens your homepage, the PHP behind it, has to fetch the information from database, parse it with related views and then display the final HTML output, LOTSA processing.
Instead, caching will store the HTML output in its buffer and when user comes in, it will show the HTML cached output rather going to the database and stuff. However, life of cache has to be defined although modern cache plugins will check for any changes in the output data and update the cache as is.
Simple?
I have seen on various sites a querystring followed by a numbers for images and css files. When I look at the source code (via Chrome Developer), the cached css files and images do not have the number in the query string in their names. I have also seen on sites where the number changes in the querystrings when I refresh the page.
As example:
myimage.jpg?num=12345
myStyles.css?num=82943
After refresh:
myimage.jpg?num=67948
myStyles.css?num=62972
Can anyone explain to me what could possibly be the purpose of these querystrings short of tracking?
Often times developers use those query strings with random numbers (or version numbers) to force the browser to request a fresh copy and avoid caching of those files since the request is different each time.
So if you have a file /image.png but it is a generated image, like perhaps a captcha or something, you could follow it with a random number querystring /image.png?399532 which the browser would then not pull image.png from its cache, but instead will download a fresh copy from the server.
Prevent caching (the query string can provide a unique URL each time the file is updated causing the browser to download a new copy and not load a stale one from its cache)
Versioning (similar to #1 but with a more specific purpose)
The query string is for version controling it force to the navigator to reload the css and the image instead of use the cache
I am currently developing a web site with PHP + MySQL and jQuery. So far I have been doing it in my local machine. I notice that when I see the page the images on it take some time to load (few time but its visible). All images are small (PNG's with less than 3 KB). Now, when I load the page, there are some database connections happening in order to get some data that I will display.
I am not sure if this loading time issue has something to do with the amount of images, or with the time that the PHP script + the DB connections take to execute. (I have very little data in my database so I wouldn't assume this case.)
My question is: Is it a good approach to preload all the images in the beginning of each page? I tried it with jQuery and it works fine. I'm just not sure which disadvantages I can get with it. For example, to do so, I need to include the jQuery library in the beginning of the page? I thought it was a bad practice.
If these PNGs are stored in the database as BLOBs — not clear from your question — don't do that. Serving images from a DB through PHP is not as efficient as letting the web server serve them straight from the filesystem. If the images are tied to particular records, just name the PNG after the row ID, so you can find it in a directory dedicated to storing those images. The PHP code then just generates the URL that points to the PNG file on disk, so the web server can send them statically.
I don't think preloading the images within the same page is going to buy you anything. If anything, it might slow the apparent overall page load time because the browser can only retrieve a fixed number of resources concurrently, typically 2-4. Loading images at the top of the <body> means there are other things at the top of the page "above the fold" that have to wait for some HTTP connection slots to free up. Better to let the images load in their natural order.
Preloading makes sense in two situations:
The image isn't shown by default, but is expected to be needed as the user interacts with the page. Good examples of this are the hover and click state images for rollovers.
The image isn't used on this page, but will be needed on the next. Good examples of this are any site where there is a clear progression from one page to the next, like in a shopping cart.
Either way, do the preload at the very bottom of the <body>, so everything else loads first.
Having addressed those two issues, run YSlow on your site. It started out as a plugin for Firebug, which in turn is a plugin for Firefox, but it's since been ported to all major browsers except IE.
The beauty of YSlow is that it detects common slowdowns automatically, just by loading the page while the extension is active. It then gives you a clear grade for the page, so you can judge when you're "done" optimizing. If you're below an A, you're not done yet. :) It's not uncommon to see sites rating a D or worse, because the default configuration for web servers is conservative to avoid causing problems. Fixing YSlow warnings is generally pretty easy, but you have to be careful to avoid creating caching and other problems, which is why the default server config doesn't do these things.
Another answer recommended the Google PageSpeed offering. It's available as a plugin for Chrome and Firefox, as a server-side Apache module, and as a Google-hosted service. I have no idea how it compares to YSlow, but it looks interesting.
Also consider using the browser's debugger to get a waterfall graph of resource load times:
In Firebug you get this in the Net tab.
In Safari, you get to it via the Develop menu, which is normally disabled in Preferences. Turn it on if needed, then say Develop > Start Timeline Recording. That puts you into the Network Requests instrument. You can also get to it through Develop > Show Web Inspector.
In Chrome, say View > Developer > Developer Tools, then go to the Network tab.
IE has a very weak form of this, via Tools > Developer Tools > Profiler. It just gives a table of numbers, rather than a waterfall graph, so the information is there, but you can't just visually scan for long bars to find the slowest resources.
You should use page speed plugin from google to check what data takes most of the time to load. It will show separate load times for images as well.
If you're using lots of small pngs I suggest you combining them into one image and manipulating the display via css background property since they are part of styling and not information. In that case - instead of few images only one will be loaded and reused through all elements. In this case even preloading of one image is really easy.
Have you considered using CSS Sprites to combine all of your images into a single download? There are a number of tools online to help you do this, and it will significantly reduce the number of HTTP requests required by your page.
Make sure you have set the correct Expires header on your images to allow them to be cached.
Finally, take a look at YSlow which can provide you with futher optimisation tips.