[ic] Strap template slow

Frank Reitzenstein frank at aussievitamin.com
Tue Dec 29 09:45:00 UTC 2015


EA3KZ Salvador Caballé wrote:
>
>>>
>>> Any idea where can be the bottleneck?
>>
>> I would suggest you review the response times for page elements from
>> your server via something like Firefox's Developer Tools.
>>
>> The Strap template does load CSS and JS from the Bootstrap CDN, as well
>> as jQuery from Google's CDN. These, while fast responses, are probably
>> larger files than the CSS of the original Standard template (and
>> Standard inlined all its JS, as I recall).
>>
>> However, an adept developer would not use Strap out of the box, except
>> as a baseline. You should ideally customize Bootstrap to eliminate bits
>> you don't need (http://getbootstrap.com/customize/), as this will help
>> to reduce the size of the Bootstrap CSS and JS.
>>
>> If you do away with the top navigation dropdown menu, then you can
>> eliminate jQuery as well.
>>
>> Aside from these elements, the images are exactly the same as Standard
>> catalog, and I doubt the custom CSS is much different.
>>
>
> Josh,
>
> Thanks for your answer,
>
> CSS and JS code takes about 0,5 sec on the first call, then are in
> cache and are not  the most important impact in the speed, the html
> code takes more then 1 second, perhaps I need a more powerful server,
> now is running in a EC2 instance C1.medium only for the catalog.
>
> this is the web site: http://www.astroradio.com
>
>
> I will continue looking for  to optimize the performance.
>
>
> Thanks again
>
> Salvador
>


Hello Salvador. I have tried to speed up my strap store not yet released
in recent weeks. I have links comparing yours with mine at GTMetrix.
Note that I have a lot more images than the original and yet it is
giving me a page size of about 270KB but yours is around 400KB.

You never mentioned that?

If you actually do this yourself at GT Metrix (and check out all the
competitors plus google and don't forget google mobile friendly) and
follow all the advice you will see suggestions on how you can speed it
up. I have already followed some of these.

http://203.59.28.211/strap/astroradio/Latest%20Performance%20Report%20for:%20https:_www.astroradio.com_%20|%20GTmetrix.html

http://203.59.28.211/strap/kenyan-curios/Latest%20Performance%20Report%20for:%20https:_www.kenyan-curios.com_%20|%20GTmetrix.html

I don't get 100%, but I spent a long time trying to address all issues.

Note that my image at the top are degraded in quality, compressed and
(this is experimental) hosted on Flickr in place of CDN. However I also
eventually got a free CDN to work.

https://c2.staticflickr.com/6/5679/23495030890_de5200a9eb_m.jpg

Since doing that I signed up at free Swarm CDN. You can see their script
at the top of the source on every page.

<script>
  var swarmcdnkey = "608b1630-6d0d-4977-8458-c282e9a8af28";
  var swarmimagescan = true;
</script>
<script src="//assets.swarmcdn.com/swarmdetect.js"></script>

You have to sign up and get a key. From memory both the flickr pics and
swarm cdn made a large difference.

What else have I done?

I used perl GD::Image to find the dimensions of all my images. I wrote a
perl script to download my products file via ftp, locate the images,
download them and write down the 4 image and thumb dimensions in
products.txt (I have a lot of spare columns).

Now wherever images are displayed anywhere, I make sure that the image
has alt text (the product description) and also the height and width
which speeds browser rendering.

I also have apache2.conf.dynamic and apache2.conf.static.

Now I have a master batch file which processes my data. So the first
thing it does is copies apache2.conf.dynamic to apache2.conf then
service apache2 restart.

Then it creates static pages. So all the arduous routes from the left
hand menu to the groups pages and then the product (bar the flypage) are
static (using LWP::Simple). The same is done for the brands and selected
files like index.html and brands.html.

I plan to do more, but I want to go live on three sites first.

Regards,

Frank Reitzenstein.




More information about the interchange-users mailing list