8 thoughts on “A quick way to speed up your website Leave a comment

  1. Pretty nice idea that, but yeah perhaps security might be an issue, using especially if uses can post code to your website e.g. comments.

    The other thing is is using another PHP file to open files rather than the browser including them as the page loads actually quicker? For larger sites I would imagine it in. Also, I was told the other day how ‘slow’ foreach statements where compared to using while and for loops, and I looked this up and tested it and it doesnt turn out to be true. If you look http://www.phpbench.com/ here, about the third test from the bottom (this is what I tested it with), a for loop is almost 10 times as fast as a foreach, so if you’re looking to speed things up this may be something to look at πŸ™‚

    Another possible way to speed up a site I just tried: CSS Sprites (http://sixrevisions.com/web-development/10-ways-to-improve-your-web-page-performance/ number 5). and basically placing all small background images in one larger image and adjusting the background-position accordingly. Great for icons and rollovers, but at the same time on a slow connection it may actually make no difference. 1 large image vs 10 small ones? Also the bandwidth situation with one image being loaded 10 times in this case would be interesting. Don’t my limited knowledge of that side of things suffices here!

    Bit of an essay, sorry haha, but this post got me thinking πŸ™‚

  2. I would be interested to know if this script makes a noticeable difference on lower speed broadband and dial-up connections. Have you had a chance to test out this script on actual low speed connections?

    It’s a nice idea.

  3. Ben I tested your script over at my site. I setup two pages, one using your script to load the CSS and JavaScript files. The second page was the control group that called all the CSS and JavaScript files individually. Both pages included working example of a jQuery function. I used five javascript files including the jQuery library, and three CSS files. I recorded two numbers from each page load: #1 was the actual amount of time for the page to load, and #2 was the actual amount of time the server took to generate the page. Since the server has to generate the file I felt it appropriate to include the amount of time spent generating the full page. I ran 24 tests of each page. The results follow:

    Average Load Time:
    Page 1 – Ben’s Load Script: 1.80 seconds
    Page 2 – Normal Load Method: 1.87 second
    Percent of time saved by using the script: 3.84%

    Server Page Generation Time:
    Page 1 – Ben’s Load Script: 1.215069 seconds
    Page 2 – Normal Load Method: 1.188876 seconds
    Percent of time saved by using the script: (-2.20%)

    The above results are from a 1.5Mbps DSL connection.

    As soon as I get access to a 56k dial-up modem I will test your script again. I don’t want to use a proxy bandwidth limiter for this test, as that isn’t an actual test of a 56k modem. I want to make sure all the factors are there including interference as it travels down the line.

  4. Stephen – wow – that’s some pretty full on testing you’ve done. I must admit I haven’t actually done any testing myself but I am not sure why my system is so slow. a 3.84% speed up doesn’t seem worthwhile. I would expect it to be slower on the first load but future loads should be faster as the content should be cached – did you tests take this into account?

  5. My test was of the cached files. I didn’t factor in the first load, but it was a tad bit longer. Thinking back to the network theory stuff, since everything gets broken down into small packets for transmission over the physical medium, the only real savings may be in the form of less file requests, but the actual data sent may be very similar in size, and thus the number of packets sent would be similar in quantity. So on a broadband connection it appears to be relatively close in timing. I may run some tests to verify the number of packets, but right now I am busy finishing up a new flash project, so I wouldn’t be able to get around to if for a few weeks.

    I still haven’t been able to find a landline to use a dial-up connection to test the load script on. I hope someone out there can take the time to run the numbers if they have access to a landline and dial-up connection.

  6. Hi

    I may have read your code wrong and please correct me if I have, but…

    What I gather is that it GETS from the URL the scripts (CSS and Javascript) that need to be included for the page to work? To me that sounds tricky to maintain, as you would need to mess around with links whenever you want to link to a newly created page or even more annoying if you added another script (then you would need to change all your URLs). I think it would be easier to have a well structured single CSS file for example and organize it that way.

    I can understand you trying to speed things up by reducing the number of connections to the web server but I can’t see it being practical given the drawbacks mentioned above.

    Incidentally a site I created worked something like this below and I never noticed load up differences from much smaller sites. I never tried on 56k though.

    Every page had: Include master.php – a single file which included all my other php functions required. This meant that whenever I wanted to add a new function all I had to do was add it into one file and every page would take it onboard as required. Some of the functions were real functions (they just carried out an operation and returned a value), while others actually were for display. For example I wanted to show a particular welcome part on more than one page so I created a function which did this and just included in my master.php – which meant that I could then add this function into any of my web pages and it would understand and oblige normally.

    I think the same idea for CSS could be implemented by including a PHP function that includes all your CSS files?

    Anyway just another idea for the pot! πŸ™‚


Leave a Reply

Your email address will not be published.