Hi Mari,
it's the pale blue shadow below the headers in the Login and Navigation blocks,
regards,
dave
David Scotson
David Scotson による投稿
Good tip!
I think the inline images are actually stored for 60 days rather than reloaded each time, but ideally that would be longer. I think the theme images served via the CSS are cached for 1 year.
I think the inline images are actually stored for 60 days rather than reloaded each time, but ideally that would be longer. I think the theme images served via the CSS are cached for 1 year.
Hi Mari,
a few general image size suggestions:
1. don't write the text in the image. Use standard HTML/CSS for the written banner at the top of each image. Not only will this be smaller, it will look better, and be more accessible.
2. For the images that are icons, rather than photos, use PNG format. I assume they started off in that format, don't convert back to PNG from a JPEG if you can help it. Then when you've got your PNG ready for use, run it through this website to see if they can make it smaller: https://tinypng.com/
3. For actual photographs, take a high-quality version and run them through this service, it's a fairly simple way to get the smallest size without compromising quality: http://www.jpegmini.com/ You can either resize it first and upload it, or use the free trial version of their download app which lets you set an output size.
Also, running the Google Pagespeed tool suggest that the shadow on your header is the place where you could most save some space with compression, I've attached a smaller version of the image to this post,
hope that helps.
a few general image size suggestions:
1. don't write the text in the image. Use standard HTML/CSS for the written banner at the top of each image. Not only will this be smaller, it will look better, and be more accessible.
2. For the images that are icons, rather than photos, use PNG format. I assume they started off in that format, don't convert back to PNG from a JPEG if you can help it. Then when you've got your PNG ready for use, run it through this website to see if they can make it smaller: https://tinypng.com/
3. For actual photographs, take a high-quality version and run them through this service, it's a fairly simple way to get the smallest size without compromising quality: http://www.jpegmini.com/ You can either resize it first and upload it, or use the free trial version of their download app which lets you set an output size.
Also, running the Google Pagespeed tool suggest that the shadow on your header is the place where you could most save some space with compression, I've attached a smaller version of the image to this post,
hope that helps.
With the adoption of HTTP2 concatenating CSS for a project like Moodle starts to make less sense.
There's a nice intro here:
http://daniel.haxx.se/blog/2014/04/02/presentation-what-is-http2/
As it says though, there will probably be a whole new bunch of optimisation techniques required to get the best out of HTTP2, which people will discover as it goes into wider use. And what we do now to work around old HTTP deficiencies (spriting, concatenation, sharding) may be actively harmful.
There's a nice intro here:
http://daniel.haxx.se/blog/2014/04/02/presentation-what-is-http2/
As it says though, there will probably be a whole new bunch of optimisation techniques required to get the best out of HTTP2, which people will discover as it goes into wider use. And what we do now to work around old HTTP deficiencies (spriting, concatenation, sharding) may be actively harmful.
On the topic of dialogue boxes, the Chrome team is trying to standardise the < dialog > element for this use case, and has a polyfill library for backwards compatability:
http://demo.agektmr.com/dialog/
The dialog element is in the early stages of standardisation but generally, taking advantage of things provided by modern browsers and using polyfill libraries to fill in the gaps for older browsers makes a lot of sense when it is possible.
Particularly when dealing with multiple device formats e.g. small touchscreen phones, a date picker or whatever widget provided by the platform itself is basically always going to beat something built from scratch in JS.
http://demo.agektmr.com/dialog/
The dialog element is in the early stages of standardisation but generally, taking advantage of things provided by modern browsers and using polyfill libraries to fill in the gaps for older browsers makes a lot of sense when it is possible.
Particularly when dealing with multiple device formats e.g. small touchscreen phones, a date picker or whatever widget provided by the platform itself is basically always going to beat something built from scratch in JS.