I`m trying to optimze and convert images using mod_pagespeed and it works very good for all tags in html files. But how could it process images that loaded with js? For example images in slideshows and etc.
Thanks!
mod_pagespeed normally optimizes images and other resources by detecting their URL in the HTML and then replacing the URL with a link to the optimized version. As of mod_pagespeed 1.4.26.1 however, mod_pagespeed includes a feature called In-Place Resource Optimization, which allows resources requested with their original URL to be optimized. This can be used in cases like yours where images are being requested through AJAX. It can be enabled by setting ModPagespeedInPlaceResourceOptimization on in your config file, and have a look at the documentation linked above for more details.
Google's mod_pagespeed module only parses HTML files for images, and then optimizes them. You would have to have the images loaded via the HTML file, and then referenced/shown to the client via javascript. (Have the images hidden by default).
Related
I'm generating dynamic CSS URLs for cache-busting. I.e. they're in the format styles-thisisthecontenthash123.css.
I also want to use HTTP Link headers to load the files slightly faster. I.e. have the header Link: <styles-thisisthecontenthash123.css>; rel=stylesheet
I'm pretty sure it's possible to do this in Fastly using VCL, but I'm not familiar enough with the ecosystem to figure it out. The CSS URL is in index.html, which is cached. I'm thinking I can open index.html and maybe use regex to parse out the CSS URL. How would I do this?
If I'm understanding your question correctly, you want to include a link header for all requests for index.html. You can do that with Fastly, but if the URL for the CSS file is changing you're not going to be able to pull that info out with VCL (you can't inspect the response body).
You could use edge dictionaries and whenever your CSS filename changes, update the reference via the API.
Thing is, if you're going to make an API call whenever the file changes, might as well just keep the filename consistent (styles.css) and whenever you publish a new version send a cache invalidation (purge). Fastly will clear the cache in ~150ms, so you then all you have to do is add the header which is can be done in the Fastly web portal with a condition.
I am planning on using ImageResizer to dynamically resize images. The images will be stored on Azure blobs and accessed via CDN.
At the moment files paths are inline and in css:
<img src="/images/someimage.jpg" />
.backgroundImage { url('/images/somebgimage.jpg')
1) What is a recommended way to redirect image paths to use CDN? I've seen people use Html Helpers (in asp.mvc #Html.CdnImage('/images/something.jpg')) but this doesn't work for images in css.
2) There is also url-rewriting in the web.config
Given that ImageResizer uses querystring to manipulate the images, how would you go about cache busting images after an update and how would you point images to use the CDN?
Client-side redirects massively increase latency, and should be avoided. You can't use URL-rewriting between different hosts.
Most CSS pre-processors support helper methods. If you can't use helpers everywhere, manually insert the CDN addresses.
Cache-busting is CDN-specific. Changing the URL works everywhere (unless you disable querystring-specific caching on your CDN). Some CDNs also offer an invalidation API. Either way, I would open a question about the specific CDN you are using as this isn't an ImageResizer question.
I use Nginx and I have installed Google PageSpeedModule on one of my domain. This module is really usefull, and easy to use. All CSS and JS are minified, my images are compressed... it has reduced the weight of 500 kb of my pages.
My question is, can I use this module to deliver only ressources ? I create a kind of CDN, containing all my CSS, images, JS... But, I installed Nginx + pagespeedmodule and the module is not working for one image only for example. But it works with an HTML page and compress the images in this page, but can it work with a direct access image ? Thanks.
Yes, you can use InPlaceResourceOptimization to optimize images even if they are not optimized in HTML (Note: That doc says that this is an Apache-only feature, but that's out of date, it works in the latest Nginx as well.). Add this command to your config:
pagespeed InPlaceResourceOptimization on;
Note that the default way that ngx_pagespeed works is by rewriting resources found in HTML. That is the most efficient way to run it. If you only use InPlaceResourceOptimization you will not get some advantages like cache extension and image resizing. However this is a convenient feature if you cannot optimize resources in HTML.
I've seen a lot of dynamic website through the internet that their pages are in html or htm format . I don't get it why is that ? And how they do that ?
Just look at this website : http://www.realmadrid.com/cs/Satellite/en/Home.htm
What you see in the URL can be set at will by the people running the web site. The technique is called URL rewriting.
How
On Apache, the most popular solution to that is the mod_rewrite module.
Seeing as you've tagged ASP.NET: As far as I know, ASP.NET has only limited rewriting support out of the box. This blog entry promises a complete URL rewriting solution in ASP 2.0
Why
As for the why, there is no compelling technical reason to do this.
It's just that htm and html are the recognized standard extensions for HTML content, and many (including myself) think they simply look nicer than .php, .php5, .asp, .aspx and so on.
Also, as Adam Pope points out in his answer, this makes it less obvious which server side technology/language is used.
The .html/.htm extension has the additional effect that if you save it to disk, it is usually automatically connected with your installed browser.
Maybe (a very big maybe) there are very stupid simple client programs around that recognize that they have to parse HTML by looking at the extension. But that would be a blatant violation of rules and was hopefully last seen in 1994. Anyway, I don't think this is the case any more.
There are a number of potential reasons, these may include:
They could be trying to hide the technology they built the site with
They could be serving a cached version of a page which was written out to HTML.
They could simply perceive it to look friendlier to the user
They might be using a server-side scripting language like PHP or ASP. You can configure what file extensions get parsed by the language by editing the web server configuration files.
For example in PHP the default extension is .php but you could configure the server to use .html, that would mean any files with the .html extension could contain PHP code they would get parsed before the page is sent to the clients web browser.
This is generally not recommend as it adds an overhead and .html pages that don't have any PHP would be parsed by the PHP engine anyway which is slower then serving pages direct to the browser.
The other way would be to use some form of URL rewriting. See URL Rewriting in ASP.NET
Another reason is SEO(Search engine optimization). Many search engines like html pages and many guys（I mean some SEO specialists) think the html can improve the rank of their content in search engine.
One possibility is just historical reasons. Pages that started static, now are generated dynamically, but sites don't want to break old customer's favorites.
They keep some pages as html because their content is not supposed to change frequently or not at all.
But you should also keep in mind the fact that some sites are dynamic but they change the page extention to html but original page remains same eg php or aspx, etc using htaccess or some frameworks like codeigniter etc.
What are some of the disadvantages of using an external JS file over including the JS as a part of the ASPX page?
I need to make an architectural decision and heard from coworkers that external JS does not play nice sometimes.
The only downside that I am aware of is the extra HTTP request needed. That downside goes away as soon as the Javascript is used by two pages or the page is reloaded by the same user.
One con is that the browser can't cache the JS if it's in the page. If you reference it externally the browser will cache that file and not re-download it every time you hit a page. With it embedded it'll just add to the file-size of every page.
Also maintainability is something to keep in mind. If it's common JS it'll be a bit more of a pain to make a change when you need to update X number of HTML files' script blocks instead of one JS file.
Personally I've never run into an issue with external files vs embedded. The only time I have JS in the HTML itself is when I have something to bind on document load specifically for that page.
Caching is both a pro and potentially a con, if you are not handling it properly.
The pro is obvious, as it will improve page loading on every page load past the first one.
The con is that when you release new code, it may still be cached by the user's browser, so they may not get the update. This can easily be solved by changing the name on your js file. We automatically version our js with the file's timestamp, and then make sure that points to the create file in the web request through configuration on our web server (mod_rewrite, Apache).
Ask them to define "play nice". Aside from better logical organization, external js files don't have to be transmitted when already cached.
We use YUI compressor to automatically minify and combine external scripts into one when doing production/staging builds.
The only disadvantage I know is that another request must be made to the server in order to retrieve the external JS file. As was said before me you can use tools like YUI compressor to minimize the effects of this.
The advantage however would be that you can keep all of your JS code in a separate more maintainable format.
Another huge advantage to external javascript is the ability to check your syntax with Jslint. That, added to the ability to minify, combine and cache external scripts, makes internal javascript seem like a poor choice.